Networks week 7

Computer Networks Week 7 Mar 4 Corboy Law 522

Read:
Chapter 3:
    3.1
    3.2.1 (Learning Bridges)
Chapter 4:
    4.1.1-4.1.6
    4.2.1
    4.2.2 (Distance-Vector)
Chapter 5:
    5.1: UDP
    5.2.1: End-to-End
    5.2.2: Segment format
    5.2.3: connection establishment and termination

Midterm: March 18

Today (March 1, 2010) I averaged 11.2 MB/s on a 100mbps fast-Ethernet link. That works out to a throughput of 89.6%. Given the ACKs and Ethernet/IP/TCP header overhead, that's pretty darn good.

Routing-table algorithms (§4.2)

4.2.2: distance vector routing (Routing Information Protocol, RIP)

Routers identify their router neighbors, and add a third cost (or distance) column to their tables. The simplest case is when we assign a cost of 1 to each link (the "hopcount" metric); it is also possible to assign more complex numbers. Neighbors exchange the (destination,cost) portions of their tables. When a neighbor's (dest,cost) pair arrives, the router updates its own table in three cases:

new node reported
decreased distance to existing node reported . NOTE: these are the "no-bad-news" cases for which convergence happens because the distances are monotonically decreasing (or the same). If all hopcounts are 1, shortest path is the first discovered.
increased distance reported by NextHop for that node

Distance-Vector slow-convergence problem

A and B have table entries for destination D as shown underneath.

             D-------A----------B
                 <D,dir,1>   <D,A,2>        ;; "dir": directly connected

Now the D--A link breaks:

            D---x---A----------B
                 <D,dir,∞>   <D,A,2>        ;; "dir": directly connected

If A immediately notifies B that D is no longer reachable (distance = ∞), then all is well. However, it is possible that, just before A begins to do this, B notifies A first that it has a route to D, with cost 2. This will lead to "slow convergence to infinity" (demo).

slow-convergence fixes

The simplest is using a small value for infinity (done week 6)
            RIP: infinity=16, updates every 30 sec
            Cisco IGRP: infinity <= 256; default = 100


split horizon:

Don't report reachability to your own NextHop for a node; in the example above, B would never report D-reachability to A because A is B's NextHop to D.

This is very effective, but can fail to prevent some routing loops, if the hosts in question are arranged in a loop. Classic example: hosts A, B, and C are connected in a loop, and D (the destination to which connectivity is lost) connects to A.

poison reverse:
claim a node to be at distance infinity, when reporting to your own NextHop for that node
Poison reverse is best viewed as a stronger form of split horizon.

triggered updates: send report immediately on any change for the worse. This is generally intuitive, except that it can lead to notification storms, and there is still the possibility that the other end will send first.

hold down: sort of a receiver-side version of triggered updates: the receiver doesn't use new alternate routes for ~60 sec following discovery of unreachability. This gives time for bad news to arrive.

route poisoning: hold down only for changes that increase hop count

Chapter 5: transport

TCP - P&D 5.2

more semantic issues:
        connected v connectionless
        connection is between two sockets: a socketpair
        one socket on host A can be part of multiple distinct socketpairs
        reliable v unreliable
        stream v packets

        what TCP does; header fields

TCP Header Format


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

connection establishment

Logical issue of what is a "connection"
connection state on top of stateless lower layer

Basic strategy of 3-way handshake

Sequence number value is the number of the first byte of the packet, or what the number would be if there were a first byte.

Ack is the number of the next byte we are expecting

SYNs count as 1 byte (so do FINs)


In the following diagram, we are using relative sequence numbers, assumed to begin at 0 on each side.

A	B
send SYN, seq=0
	send SYN+ACK, seq=0, ack=1 (expecting)
send ACK, seq=1, ack=1 (ACK of syn
send "abc", seq=1, ack=1
	send ACK, seq=1, ack=4
send "defg", seq=4, ack=1
	send seq=1, ack=8
send "foobar", seq=8, ack=1
	send seq=1, ack=14, "hello"
send seq=14,ack=6, "goodbye"
send seq=21, ack=6, FIN	send seq=6, ack=21 ;; crossing
	send seq=6, ack=22 ;; ACk of FIN
	send seq=6, ack=22, FIN
send seq=22, ack=7

If side X sends ACK=n, then after that is received the other side Y will reply with SEQ=n (this assumes no data is lost in transit.) Logically, however, side Y's concept that SEQ=n took effect as soon as Y sent the data for which X sent the ACK=n.

ISN issue : we do not in fact transport relative sequence numbers. Each side chooses its Initial Sequence Number, and sends that instead. All further sequence numbers sent are the relative sequence number plus the ISN.

              outline
              versus one 2-way handshake

              Adding 1000 to ISN_A: this affects SEQ on A's side, ACK on B's side

TCP sliding windows: mostly the same as "normal" sliding windows, done earlier

basic outline
examples, window-size flow control

fast sender, slow receiver

fast receiver, slow sender

long path

Keeping the pipe full: bandwidth×delay! p. 301

Introduction to TCP state diagram, as far as connection establishment

    SYN, ACK, FIN, RST packets

Final-ACK problem: what if the final ACK is lost? The other side will resend its final FIN, but there will be no one left to answer! This is solved with the TIMEWAIT state.

Old late duplicates problem: Suppose a connection between the same pair of ports is closed and promptly reopened. Sometime during the first connection, a packet is delayed (and retransmitted). It finally arrives during the second connection, at just the right moment that its sequence number fits into the receive window of the receiver. (Example: ISN1 = 0, delayed packet seq number = 8000, ISN2 = 5000, receiver is expecting relative sequence number of 3000 when the old packet arrives.)

TIMEWAIT to the rescue again!

What a connection is: machine state at each endpoint
TCP should handle:

lost packets
damaged packets
reordered packets
duplicated packets
widely varying delay

ISN rationale 1: old late duplicates

ISN rationale 2: distinguishing new SYN from dup SYN

From Dalal & Sunshine's original paper on the TCP 3-way handshake:

2-way handshake: can't confirm both ISNs

4-way handshake:
            1    --SYN->
            2    <-ACK--
            3    <-SYN--
            4    --ACK->
This FAILS if first SYN is very very old ! The ack at line 2 is ignored by its receiver. LHS thinks the SYN on line 3 is a new request, and so it acks it. It would then send its own SYN (on what would be line 5), but it would be ignored. At this point A and B have different notions of ISN_A.

3-way handshake

TCP state diagram

Functional Specification

TCP State Diagram

                              +---------+ ---------\      active OPEN
                              | CLOSED |            \    -----------
                              +---------+<---------\   \   create TCB
                                |     ^              \   \ snd SYN
                   passive OPEN |     |   CLOSE        \   \
                   ------------ |     | ----------       \   \
                    create TCB |     | delete TCB         \   \
                                V     |                      \   \
                              +---------+            CLOSE    |    \
                              | LISTEN |          ---------- |     |
                              +---------+          delete TCB |     |
                   rcv SYN      |     |     SEND              |     |
                  -----------   |     |    -------            |     V
+---------+      snd SYN,ACK /       \   snd SYN          +---------+
|         |<-----------------           ------------------>|         |
|   SYN   |                    rcv SYN                     |   SYN   |
|   RCVD |<-----------------------------------------------|   SENT |
|         |                    snd ACK                     |         |
|         |------------------           -------------------|         |
+---------+   rcv ACK of SYN \       / rcv SYN,ACK       +---------+
   |           --------------   |     |   -----------
   |                  x         |     |     snd ACK
   |                            V     V
   | CLOSE                   +---------+
   | -------                  | ESTAB |
   | snd FIN                  +---------+
   |                   CLOSE    |     |    rcv FIN
   V                  -------   |     |    -------
+---------+          snd FIN /       \   snd ACK          +---------+
| FIN    |<-----------------           ------------------>| CLOSE |
| WAIT-1 |------------------                              |   WAIT |
+---------+          rcv FIN \                            +---------+
   | rcv ACK of FIN   -------   |                            CLOSE |
   | --------------   snd ACK   |                           ------- |
   V        x                   V                           snd FIN V
+---------+                  +---------+                   +---------+
|FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
+---------+                  +---------+                   +---------+
   |                rcv ACK of FIN |                 rcv ACK of FIN |
   | rcv FIN       -------------- |    Timeout=2MSL -------------- |
   | -------              x       V    ------------        x       V
    \ snd ACK                 +---------+delete TCB         +---------+
     ------------------------>|TIME WAIT|------------------>| CLOSED |
                              +---------+                   +---------+

                      TCP Connection State Diagram
                               Figure 6.

    half open
    simultaneous open

Anomalous TCP scenarios

Duplicate SYN           (cf Duplicate RRQ in the TFTP protocol)
                recognized because of same ISN

Loss of final ACK       (cf TFTP)
                any resent FIN will receive a RST in response

Old segments arriving for new connection
                solved by TIMEWAIT

Sequence number wraparound (WRAPTIME < MSL)
                Note WRAPTIME = time to send 4 GB
                WRAPTIME = 100 sec => 40 mbytes/sec => >300 Mbits/sec

Client reboots (application restart isn`t an issue)
                Could an old connection be accepted as new?

Demo of tcp_stalk

1. Note ServerSocket v Socket

2. accept() loop

3. connection semantics: what if one client is connected, and a second one tries to connect and send?

4. Python version of the client

5. Note the DNS-failure handling. My home ISP never has DNS lookup failures; all failed lookups resolve to the IP address of a host that has a search engine as a web page. Alas, this is not helpful if we're not looking for web pages.