Chapter 6 SACKTCP TCP Extensions Wireless TCP Professor

  • Slides: 37
Download presentation
Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP Professor Rick Han University of Colorado at

Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP Professor Rick Han University of Colorado at Boulder rhan@cs. colorado. edu Prof. Rick Han, University of Colorado at Boulder

Announcements • Read Sections 6. 1 - 6. 4, Skip 6. 5 • Programming

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, • •

Recap of Previous Lecture • TCP Adaptive Retransmission • • • Initially, • • Compute exponentially weighted moving average (EWMA) of RTT RTO = 2* (EWMA of RTT) • • Compute EWMA of RTT and absolute deviation RTO = (EWMA of RTT) + 4*(EWMA of abs dev) • • If no retransmission, recompute RTO and EWMA’s If retransmission, back off RTO = RTO * 2, don’t recompute EWMA’s Revision Retransmission Ambiguity Revision Prof. Rick Han, University of Colorado at Boulder

Recap of Previous Lecture (2) • TCP Congestion Control • • W = min

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 Prof. Rick Han, University of • TCP Reno Colorado at Boulder

Timer Granularity • Many TCP implementations set RTO in multiples of 200, 500, 1000

Timer Granularity • Many TCP implementations set RTO in multiples of 200, 500, 1000 ms – 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

Delayed ACKS • Problem: – In interactive programs like telnet, you could send a TCP packet for each character you type – Overhead becomes high: • You send 1 st 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 200 ms before ACK’ing • Can piggyback echo of data with ACK of 1 st 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] Event TCP Receiver action In-order segment arrival,

TCP ACK Generation [RFC 1122, RFC 2581] Event TCP Receiver action In-order segment arrival, No gaps, Everything else already ACKed Delayed ACK. Wait max 500 ms for next segment (usually 200 ms timer). If no next segment, send ACK In-order segment arrival, No gaps, One delayed ACK pending Immediately send single cumulative ACK Out-of-order segment arrival Higher-than-expect seq. # Gap detected Send duplicate ACK, indicating seq. # of next expected byte Arrival of segment that Partially or completely fills gap Immediate ACK if segment starts at lower end of gap Prof. Rick Han, University of Colorado at Boulder Courtesy: Srini Seshan

SACK-TCP, RFC 2018 & 1072 • Problem: Cumulative ACK’s can’t identify whethere are multiple

SACK-TCP, RFC 2018 & 1072 • Problem: Cumulative ACK’s can’t identify whethere 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

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

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-oforder 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 –

Interaction of TCP Flavors • In addition to TCP Reno, Tahoe, and SACK – also have New. Reno 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

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 1 st 20 bytes, the 1 st 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

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 Rick Han, University of – Accurate RTTProf. Colorado at Boulder

TCP Large Windows Option, RFC 1072, 1323 • Delay-bandwidth product for Long Fat Network

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,

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 <->

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

Congestion vs. Wireless Bit Corruption Router Computer 1 Computer 2 Loss Congestion 3 2

Congestion vs. Wireless Bit Corruption Router Computer 1 Computer 2 Loss Congestion 3 2 22 1 0 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

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 of. TCP at endpoints – Help sender distinguish between

End-to-End Solutions • Improve implementations of. TCP 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

End-to-End: Selective Acks 4 3 6 5 Correspondent Host Cumative ACK 1 Wireless loss

End-to-End: Selective Acks 4 3 6 5 Correspondent Host Cumative ACK 1 Wireless loss X 2 Base Station Can set ECN CACK 1, SACK 3 -4 CACK 1, SACK 3 -5 1 Mobile Host CACK 1, SACK 3 -6 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

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

Split Connection 3 2 X X 1 Correspondent Host ack 0 A-D belong to

Split Connection 3 2 X X 1 Correspondent Host ack 0 A-D belong to packet 1 D C B Mobile Host Base Station ack 0 cack A A cack B, sack D

Split Connection Drawbacks • Consistent wireless losses will back up and overflow the intermediate

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

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

Hybrid Solution: TCP Snoop • Transport-aware link protocol • Modify base station: – To cache un. ACKnowledged 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-overwireless performance – Fixed and mobile endpoints don’t require any modifications Prof. Rick Han, University of Colorado at Boulder

Snoop Protocol: CH to MH 6 5 Correspondent Host 4 3 2 1 Snoop

Snoop Protocol: CH to MH 6 5 Correspondent Host 4 3 2 1 Snoop Agent 1 Base Station Mobile Host Example Courtesy of Srini Seshan • Snoop agent: active interposition agent – Snoops on TCP segments and ACKs – Detects losses by duplicate ACKs and timers – Suppresses duplicate ACKs from FH sender

Snoop Protocol: CH to MH Snoop Agent 65 3 2 4 1 Correspondent Host

Snoop Protocol: CH to MH Snoop Agent 65 3 2 4 1 Correspondent Host Base Station • Transfer of file from CH to MH • Current window = 6 packets Mobile Host

Snoop Protocol: CH to MH 6 5 Snoop Agent 4 3 2 Correspondent Host

Snoop Protocol: CH to MH 6 5 Snoop Agent 4 3 2 Correspondent Host • Transfer begins 1 Base Station Mobile Host

Snoop Protocol: CH to MH 6 5 Correspondent Host 4 3 2 1 Snoop

Snoop Protocol: CH to MH 6 5 Correspondent Host 4 3 2 1 Snoop Agent 1 Base Station Mobile Host • 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

Snoop Protocol: CH to MH 6 5 Correspondent Host • Packet 1 is Lost

Snoop Protocol: CH to MH 6 5 Correspondent Host • Packet 1 is Lost 4 3 2 1 Snoop Agent 3 2 1 Base Station Mobile Host 1 Lost Packets

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 4

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 4 3 2 cack 0 Correspondent Host Base Station Mobile Host 1 Lost Packets • Packet 1 is Lost – Duplicate ACKs generated – Note: technically for TCP, “cack 0” 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.

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 6

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 6 5 1 4 3 2 cack 0 Correspondent Host Base Station cack 0 Mobile Host 1 Lost Packets • Packet 1 is Lost – Duplicate ACKs generated • Packet 1 retransmitted from cache at higher priority

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 6

Snoop Protocol: CH to MH 6 5 4 3 2 1 Snoop Agent 6 5 1 4 3 2 cack 4 Correspondent Host Base Station cack 0 Mobile Host X • 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 (500 ms+)

Snoop Protocol: CH to MH 6 5 Snoop Agent 6 5 1 4 3

Snoop Protocol: CH to MH 6 5 Snoop Agent 6 5 1 4 3 2 cack 5 Correspondent Host Base Station cack 4 • Clean cache on new ACK Mobile Host

Snoop Protocol: CH to MH 6 cack 4 Correspondent Host Snoop Agent 6 51

Snoop Protocol: CH to MH 6 cack 4 Correspondent Host Snoop Agent 6 51 4 3 2 cack 6 Base Station cack 5 • Clean cache on new ACK Mobile Host

Snoop Protocol: CH to MH 9 Snoop Agent 8 Correspondent Host cack 5 7

Snoop Protocol: CH to MH 9 Snoop Agent 8 Correspondent Host cack 5 7 Base Station cack 6 6 51 4 3 2 Mobile Host • Active soft state agent at base station • Transport-aware reliable link protocol • Preserves end-to-end semantics

TCP Snoop Drawbacks • Base station vendors must modify their firmware to add TCP

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 un. ACKed 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