1 / 37

Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP

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

jock
Download Presentation

Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related