Networks Week 10

Comp 343/443

Fall 2011, LT 412, Tuesday 4:15-6:45
Week 10, Nov 15

Read:

Ch 3, sections 1, 2, 3
Ch 5, sections 1 (UDP) and 2 (TCP)

Example of read-with-timeout in TCP
new stalks.java, together with tcp_stalkc.py (run with python3)

Why were there no DNS failures in last week's demo?
Because thugs have taken over the internet, that's why.
More precisely, many DNS resolvers return the IP address of an error-handling (and advertising) website, on lookup failure. This makes some modicum of sense when you're restricting attention to web searches, but is annoying if you are not.

Wireshark demo

Files:

TFTP/WUMP

TFTP is the standard Trivial File Transfer Protocol; WUMP is a windowing variant due to me.

basic strategy
dallying
RRQ/REQ
port change
State view: differences between UNLATCHED, LATCHED, and DALLY

Client sends REQ to port 69
Server chooses new data port, eg 2000; sends DATA[1] from it
Client latches on to new port, sends ACK[1] to new port
Server sends DATA[2]
...
Server sends final DATA[N], of size < 512 data bytes (may be zero)
Client sends ACK[N]
Client enters Dally state

Comments:

Note how dallying acts like TCP TIMEWAIT for handling lost final ACKs, though here it is handled entirely at the application evel
Note the port change.

TFTP/WUMP scenarios:

1.    duplicate REQ

If the first REQ is sent twice (perhaps due to a client timeout), two child processes start on the server. The one that the client receives DATA[1] from first is the one the client will "latch on" to; the other should be sent an ERROR packet.

2. lost final ACK

This is addressed with the DALLY state

3.    old late duplicates

This is addressed by having EITHER side (preferably both) choose a new port number for each "connection" (ie transfer).

4.    Sequence number wrap: not allowed (but do we check?)

5.    Two scenarios where we get something other than requested:
        1. Lost REQ:     REQ "foo" (received but response delayed)
                <abort>
                REQ "bar" (lost, but now delayed DATA1-foo arrives)

6.    2. Malicious flood of DATA[1].bad from port, so

                             BAD guy opens port 666
                       <---- DATA[1].bad from 666
                       <---- DATA[1].bad from 666
                       <---- DATA[1].bad from 666
                       <---- DATA[1].bad from 666

                REQ "good" --> server
                        server creates good

                       <---- DATA[1].bad from 666    LATCH!


                    <---- server sends DATA[1].good

                       <---- DATA[1].bad from 666
                       <---- DATA[1].bad from 666
                       <---- DATA[1].bad from 666

WUMP programming project

here

TCP timers:

TimeOut
2*MSL Timewait
persist: sender polls receiver when windowsize = 0
keepalive

Path MTU Discovery
    Covered Week 8; uses some ICMP features
    Routinely part of TCP implementations now
    Uses IP DONT_FRAG bit, and ICMP Frag Needed / DF Set response

Routing

LinkState

(reliable flooding done Week 9)

Linkstate routing is an alternative to distance-vector. In distance-vector, each node keeps a minimum of network topology. In linkstate, each node keeps a maximum: a full map of all nodes and all links.

4.2.3: Link-state routing and SPF

Whenever either side of a link notices it has died (or if a node notices that a new link has become available), it sends out LSP packets (Link State Protocol) that "flood" the network. This is called reliable flooding; note that in general broadcast protocols work poorly with networks that have even small amounts of topological looping (redundant paths).

Flooding algorithm: new messages are sent on over all links except the arriving interface. Each node maintains a database of all messages received. LSPs have sequence numbers, and a message is new if its sequence number is larger than any seen so far.

It is important that LSP sequence numbers not wrap around. lollipop sequence-numbering

SPF algorithm example, with path weights:

                            B
                        5/ | \11
                  A    3| D
                       10\ | /2
                            C
The shortest path from A to D is A-B-C-D, which has cost 5+3+2=10. Note that if we use hopcounts as cost, and do a breadthfirst search for any route to D, then the first route found must be the shortest. But with other cost measures, this fails.

Build routes from A to D: (P&D do example from D to A). We maintain two sets of paths, Confirmed (known shortest paths) and Tentative (shortest so far).

Initialization: both sets are empty.

At each step,
(a) take ALL nodes reachable in one hop from the newest member of Confirmed, and see if they improve any existing routes. If so, add the new route to Tentative.

(b) Then take the shortest path in Tentative, & move to Confirmed

Step	Confirmed	Tentative
0	(A,0,-)
1a	(A,0,-)	(B,5,B), (C,10,C)
1b	(A,0,-), (B,5,B)	(C,10,C)
2a	(A,0,-),(B,5,B)	(C,8,B) (better), (D,16,B) (new)
2b	(A,0,-), (B,5,B), (C,8,B)	(D,16,B)
3a	(A,0,-), (B,5,B), (C,8,B)	(D,10,B) (better)
3b	(A,0,-), (B,5,B), (C,8,B), (D,10,B)

           Another example:

               A---3---B
               |       |
               12      2
               |       |
               D---4---C

Link-state allows precise or TOS-based metrics (TOS=Type of Service).
It also allows multiple paths to the same destination.
time to compute routes: O(N log N) for SPF, O(N^2) for VD

link-state still requires precise universal link-cost measurements!