Week 9, Oct 24 TCP state diagram WUMP assignment CIDR ================================================================================ TCP state diagram Functional Specification +---------+ ---------\ 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 ========================================== WUMP State view of BUMP: differences between UNLATCHED, LATCHED, and DALLY Assignment: build a wump client. Note the *client* does the timeouts. How the server would look: TFTP/WUMP: basic strategy dallying RRQ/REQ port change Class 8: 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. HUMP/CHUMP: two scenarios where we get something other than requested: 1. Lost REQ: REQ "foo" (received but response delayed) REQ "bar" (lost, but now delayed DATA1-foo arrives) 6. 2. Malicious flood of DATA[1].bad from port, so BAD guy opens port 6666 <---- 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 =============================================================== 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? ====================================================== 4.3.2 CIDR table explosion basic strategy [still not discussed threaded TCP server demo] new problem: address comes in, but masks only exist in the table; packets don't carry masks with them. How does lookup work? Answer: Theoretical algorithm: given a dest A, and table entries , search for i such that A & M[i] = D[i] Or, in terms of # of bits, where D[i] has N[i] network bits, A == D[i] to first N[i] bits Problem: possible multiple matches, and responsibility for avoiding this is *much* too distributed to be feasible. longest-match rule policy v mechanism: cidr is an address-block-allocation *mechanism* how provider-based routing might work review longest-match *mechanism* What *policies* do we want to implement with it? Application 1: CIDR allows providers to allocate blocks of Class C Application 2: CIDR allows huge provider blocks, suballocation by provider Providers P0(A,B,C), P1(D,E), P2(F,G) each with customers shown routing tables assuming each customer gets an address from its provider's block how longest-match allows customers to move without renumbering hidden cost of such moves Providers P0(B,C), P1(A,D,E), P2(F,G) each with customers shown (A has moved from P0 to P1) but now we have addrs unrelated to provider, and so A needs to be entered in every table! /------\ Consider P0---P1---P2 versus P0___P1___P2 router pseudo-hierarchy v. addr-alloc true hierarchy Don't have to agree, but there is a cost for disagreement What if B adds a link to P1, in addition to link to A? How CIDR allows provider-based and geography-based routing provider-based addresses Problems: route asymmetries inefficient routes (send to closest link to dest provider?) BGP "MED" value (not defined) allows server providers to carry the server's *outbound* traffic! renumbering: threat or menace? [DHCP, NAT] Locators v. EID changing IP addrs midstream geographical addresses Problems: inefficient paths between close sites. large sites Real issue with geographical routing: who carries the traffic? Provider-based: *business* model jibes with routing model!! New routing picture: destinations are networks, still, but some are organizations and some are major providers, with intermediate nets in between. Sometimes we might CHOOSE whether to view a large net as one unit, or to view it as separate medium-sized subunits (for the sake of visualization, assume the subunits have some geographical nature, or other attribute so that we can treat them as separate destinations. Tradeoff: consolidation => more compact routing table individual subentries => more optimal route selection ================================================================================ 6.2.5: TCP timeout & retransmission original adaptive retransmission: TimeOut = 2*EstRTT, EstRTT = \alpha*EstRTT + (1-\alpha)*SampleRTT RTT measurement ambiguity Karn/Partridge algorithm: Double Timeout Stop recording SampleRTT Use doubled Timeout as EstRTT when things resume Jacobson/Karels algorithm EstRTT = \alpha*EstRTT + (1-\alpha)*SampleRTT EstDev = \alpha*EstDev + (1-\alpha)*SampleDev TimeOut = EstRTT + 4*EstDev TCP timers: TimeOut 2*MSL Timewait persist: sender polls receiver when windowsize = 0 keepalive