370 likes | 753 Views
Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP. Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu. Announcements. Read Sections 6.1 - 6.4, Skip 6.5 Programming Assignment #1 emailed back by tonight HW #4 on Web by Friday evening
E N D
Chapter 6SACK-TCP, TCP Extensions, Wireless TCP Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu
Announcements • Read Sections 6.1 - 6.4, Skip 6.5 • Programming Assignment #1 emailed back by tonight • HW #4 on Web by Friday evening • Programming Assignment #2 due April 2 • Midterm • Still grading, hand back April 2 • Next, finishing up TCP Prof. Rick Han, University of Colorado at Boulder
Recap of Previous Lecture • TCP Adaptive Retransmission • Initially, • Compute exponentially weighted moving average (EWMA) of RTT • RTO = 2* (EWMA of RTT) • Revision • Compute EWMA of RTT and absolute deviation • RTO = (EWMA of RTT) + 4*(EWMA of abs dev) • Retransmission Ambiguity Revision • If no retransmission, recompute RTO and EWMA’s • If retransmission, back off RTO = RTO * 2, don’t recompute EWMA’s Prof. Rick Han, University of Colorado at Boulder
Recap of Previous Lecture (2) • TCP Congestion Control • W = min (FW, CW) • “Slow” Start grows CW exponentially from CW=1 • If timeout, • Reset CW to 1, ssthresh = CW/2 • Slow Start again, up to ssthresh • Additive Increase after ssthresh • TCP Tahoe • If 3 duplicate ACK’s • Retransmit immediately before timeout = Fast Retransmit • Drop CW = CW/2 (don’t slow start to CW=1) = Fast Recovery • TCP Reno Prof. Rick Han, University of Colorado at Boulder
Timer Granularity • Many TCP implementations set RTO in multiples of 200,500,1000ms • Avoid spurious timeouts – RTTs can vary quickly due to cross traffic • Make timers interrupts synchronized and therefore efficient • At startup: • Pick a very conservative value for RTO on order of seconds Prof. Rick Han, University of Colorado at Boulder
Delayed ACKS • Problem: • In interactive programs like telnet, you could send a TCP packet for each character you type • Overhead becomes high: • You send 1st character, get an ACK from remote host • Remote host sends echo of character for you to draw on screen, gets an ACK from you for echoed data • 4 segments exchanged • Solution: • Wait 200ms before ACK’ing • Can piggyback echo of data with ACK of 1st character => only 3 segments exchanged • Must ACK every other segment • Must not delay duplicate ACKs Prof. Rick Han, University of Colorado at Boulder
TCP ACK Generation[RFC 1122, RFC 2581] TCP Receiver action Delayed ACK. Wait max 500ms for next segment (usually 200ms timer). If no next segment, send ACK Immediately send single cumulative ACK Send duplicate ACK, indicating seq. # of next expected byte Immediate ACK if segment starts at lower end of gap Event In-order segment arrival, No gaps, Everything else already ACKed In-order segment arrival, No gaps, One delayed ACK pending Out-of-order segment arrival Higher-than-expect seq. # Gap detected Arrival of segment that Partially or completely fills gap Courtesy: Srini Seshan Prof. Rick Han, University of Colorado at Boulder
SACK-TCP, RFC 2018 & 1072 • Problem: Cumulative ACK’s can’t identify whether there are multiple losses in a window • If retransmit only lowest segment, then too slow (retransmit serially) if there are multiple losses • If retransmit entire window, then could retransmit unnecessarily if only one loss • Solution: use Selective ACK’s • SACK-TCP (proposed 1988, modified 1996) ACKs only identify up to 3 non-contiguous blocks of received data • Not quite SRP • Higher throughput than TCP Reno when multiple segments are lost in a window of data Prof. Rick Han, University of Colorado at Boulder
SACK-TCP (2) • During connection setup, a SACK-TCP sender sets “SACK-permitted” bit in SYN packet • Informs receiver that sender is SACK-enabled • If receiver supports SACK-TCP • receiver responds to data packets from sender by extending TCP header with a TCP option called a “SACK option” • SACK option identifies non-contiguous blocks of correctly received data (not the gaps) • up to 3 such blocks – limited by size of TCP options header, assumes that TCP timestamp extension is also used • 3 is enough for “substantial benefit” over TCP Reno • If more TCP extensions are used, then only enough space to identify 1 or 2 SACK blocks Prof. Rick Han, University of Colorado at Boulder
SACK-TCP (3) • At sender, • Each selectively ACK’ed segment has a bit set • Only segments with bits not set are selectively retransmitted • Since receiver may choose to discard out-of-order segments, then when sender times out, sender resets all SACK bits to zero • Try to preserve prior congestion control strategies Prof. Rick Han, University of Colorado at Boulder
Interaction of TCP Flavors • In addition to TCP Reno, Tahoe, and SACK • also have NewReno and Vegas • SACK-TCP implemented in Linux 2.1.90 and later, Microsoft Windows 98/2000, Sun Solaris 2.6 and later • How do Reno and SACK interact? • If SACK sender and Reno receiver, then Reno receiver ignores “SACK-permitted” and just sends cumulative ACKs • If Reno sender and SACK receiver, then receiver just sends cumulative ACKs without SACK options Prof. Rick Han, University of Colorado at Boulder
TCP Extensions/Options • Examples: Timestamp, Large windows, SACK-TCP • Implemented by extending TCP header > 20 bytes: • Hdr len/data offset field in TCP header specifies hdr size in 4-byte words (>5 if option present) • After 1st 20 bytes, the 1st byte of options field specifies the “kind” of option • 2 = “Maximum Segment Size” • 3 = “Window Scale” • 4 = “SACK-permitted” • 5 = “SACK-option” • 8 = “Time stamp extension” • Following bytes contain length (optional) and option data Prof. Rick Han, University of Colorado at Boulder
TCP Timestamp Extension, RFC 1323 • Used to improve timeout mechanism by more accurate measurement of RTT • When sending a packet, insert current timestamp as an option • 4 bytes for seconds, 4 bytes for microseconds • Receiver echoes timestamp in ACK • Actually will echo whatever is in timestamp • Advantages: sequence #’s are qualified by time and hence unique: • Removes retransmission ambiguity • Protects against wraparound • Accurate RTT Prof. Rick Han, University of Colorado at Boulder
TCP Large Windows Option, RFC 1072, 1323 • Delay-bandwidth product for Long Fat Network (LFN – elephant!) => 16-bit window (65536 bytes) is too small • Scaling factor on advertised window • Specifies how much to scale (multiply by left shift) a window size • Scaling factor exchanged during SYN connection setup Prof. Rick Han, University of Colorado at Boulder
TCP Problems Over Wireless Links • Wireless links are inherently error-prone • Fades, interference, attenuation • Errors often happen in bursts • TCP reacts to corruption-based packet loss by slowing down retransmission and constricting congestion window • This is wrong reaction, because there’s no congestion on wireless link, only bit corruption • Performance degradation • Should continue to retransmit and send new data, rather than slow down and constrict CW Prof. Rick Han, University of Colorado at Boulder
TCP Problems Over Wireless Links (2) • Assume following topology: A <-> G <-> B • Gateway G separates the wired and wireless worlds • Node A in wired Internet wants to send to node B in wireless world through gateway G • Aggregate the effects of wired Internet into one connection between A and G • Aggregate the effects of wireless world into one link between G and B Prof. Rick Han, University of Colorado at Boulder
0 3 2 1 2 2 2 Loss Congestion Congestion vs. Wireless Bit Corruption Router Computer 1 Computer 2 Loss Congestion Wireless Prof. Rick Han, University of Colorado at Boulder
Proposed Solutions • End-to-end protocols • Selective ACKs, Explicit loss notification • Split-connection protocols • Separate connections for wired path and wireless hop • Reliable link-layer protocols • Error-correcting codes • Local retransmission Prof. Rick Han, University of Colorado at Boulder
End-to-End Solutions • Improve implementations ofTCP at endpoints • Help sender distinguish between congestion and corruption via flags • Network routers could set Explicit Congestion Notification Bit (ECN) in IP header • And/or Wireless endpoint could signal Explicit Loss Notification (ELN) to indicate wireless loss/low SNR • ACKs include flag indicating either congestion or corruption loss Wired link Wireless link Prof. Rick Han, University of Colorado at Boulder
4 6 5 1 End-to-End: Selective Acks Wireless loss X 3 2 Mobile Host Correspondent Host Base Station Can set ECN Cumative ACK 1 CACK 1, SACK 3 CACK1, SACK 3-5 CACK 1, SACK 3-6 CACK1, SACK 3-4 Since ECN is not set in ACKs, then Sender infers corruption caused loss of packet 2, not congestion Drawbacks: have to modify IP to allow ECN, have to modify TCP to put ECN feedback in ACK
Split Connection Solutions • Split connections • Run TCP over wired link, Run TCP or another protocol over wireless link • Let TCP tailored for wireless handle wireless corruption, let wired TCP handle wired congestion Wired link Wireless link Prof. Rick Han, University of Colorado at Boulder
3 2 A Split Connection A-D belong to packet 1 X X 1 B D C Mobile Host Correspondent Host Base Station ack 0 ack 0 cack A cack B cack B, sack D
Split Connection Drawbacks • Consistent wireless losses will back up and overflow the intermediate node, backing up to sender, causing congestion backoff though there’s no congestion • Violates end-to-end semantics • When sender receives an ACK, sender believes ACK’ed data was correctly delivered to destination • No longer true: intermediate node could fail Wired link Wireless link Prof. Rick Han, University of Colorado at Boulder
Link Layer Solutions • More aggressive local rexmit than TCP • Bandwidth not wasted on wired links • Drawbacks: Adverse interactions with transport layer • Timer interactions • Interactions with fast retransmissions • Large end-to-end round-trip time variation • FEC does not work well with burst losses Wired link Wireless link ARQ/FEC Prof. Rick Han, University of Colorado at Boulder
Hybrid Solution: TCP Snoop • Transport-aware link protocol • Modify base station: • To cache unACKnowledged TCP packets • To suppress duplicate ACKs back to sender while performing local retransmissions • Key advantages: • No transport termination or TCP code in base station • Preserves end-to-end semantics • Only soft state in basestation: easy to migrate, loss of soft state merely returns TCP to its bad wired-over-wireless performance • Fixed and mobile endpoints don’t require any modifications Prof. Rick Han, University of Colorado at Boulder
4 6 5 1 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Snoop agent: active interposition agent • Snoops on TCP segments and ACKs • Detects losses by duplicate ACKs and timers • Suppresses duplicate ACKs from FH sender Mobile Host Correspondent Host Base Station Example Courtesy of Srini Seshan
1 Snoop Protocol: CH to MH 6 3 Snoop Agent 5 2 4 • Transfer of file from CH to MH • Current window = 6 packets Mobile Host Correspondent Host Base Station
1 Snoop Protocol: CH to MH 6 5 Snoop Agent • Transfer begins 4 3 2 Mobile Host Correspondent Host Base Station
4 6 5 1 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Snoop agent caches (black) segments that pass by • Difference #1 from pure link-layer – does not add a new header uses existing TCP header to identify losses Mobile Host Correspondent Host Base Station
4 6 5 1 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Packet 1 is Lost 3 2 Mobile Host Correspondent Host Base Station 1 Lost Packets
4 4 6 5 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Packet 1 is Lost • Duplicate ACKs generated • Note: technically for TCP, “cack0” should be “cack 1”, since TCP lists in its cumulative ACK the *next* byte it expects. I’ve kept “cack 0”, i.e. all packets up to 0 have been received correctly. 3 2 cack 0 Mobile Host Correspondent Host Base Station 1 Lost Packets
4 4 6 6 5 5 1 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Packet 1 is Lost • Duplicate ACKs generated • Packet 1 retransmitted from cache at higher priority 3 2 cack 0 Mobile Host Correspondent Host Base Station cack 0 1 Lost Packets
4 4 6 6 5 5 1 Snoop Protocol: CH to MH Snoop Agent 3 2 1 • Duplicate ACKs suppressed • Difference #2 from pure link-layer – tries to prevent sender from noticing loss • Sender may still timeout though – fortunately timeouts are typically long (500ms+) 3 2 cack 4 Mobile Host Correspondent Host Base Station X cack 0
4 6 6 5 5 1 Snoop Protocol: CH to MH Snoop Agent • Clean cache on new ACK 3 2 cack 5 Mobile Host Correspondent Host Base Station cack 4
4 6 6 5 1 Snoop Protocol: CH to MH Snoop Agent • Clean cache on new ACK 3 2 cack 4 cack 6 Mobile Host Correspondent Host Base Station cack 5
4 7 9 6 8 5 1 Snoop Protocol: CH to MH Snoop Agent • Active soft state agent at base station • Transport-aware reliable link protocol • Preserves end-to-end semantics 3 2 Mobile Host Correspondent Host Base Station cack 5 cack 6
TCP Snoop Drawbacks • Base station vendors must modify their firmware to add TCP snoop agent • Additional cost and complexity, may eventually be worth it if wireless data usage becomes commonplace and TCP performance is still an issue • Return path for ACKs may not traverse same basestation as forward data path • Snoop agent that has soft state for unACKed data doesn’t see ACKs • Another snoop agent that doesn’t have the soft state sees ACK’s but can’t suppress duplicates Prof. Rick Han, University of Colorado at Boulder