Chapter 6 SACK-TCP, TCP Extensions, Wireless TCP Professor Rick Han University of Colorado at Boulder

Prof. Rick Han, University of Colorado at Boulder Announcements Read Sections , Skip 6.5 Programming Assignment #1 ed 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 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 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 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 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 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 1 st 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 Congestion vs. Wireless Bit Corruption Router Computer 2Computer 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 linkWireless link

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

Prof. Rick Han, University of Colorado at Boulder 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 linkWireless link

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

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

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station 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 Agent Example Courtesy of Srini Seshan

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station Transfer of file from CH to MH Current window = 6 packets Snoop Agent

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station Transfer begins Snoop Agent

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station 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 Agent

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station Packet 1 is Lost Snoop Agent 23 1 Lost Packets 1

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station 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. Snoop Agent 2 3 Lost Packets 1 4 cack 0

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

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station 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+) Snoop Agent cack cack 0 X

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station 56 Clean cache on new ACK Snoop Agent cack cack 4

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

Snoop Protocol: CH to MH Correspondent Host Mobile Host Base Station Active soft state agent at base station Transport-aware reliable link protocol Preserves end-to-end semantics Snoop Agent cack cack 5

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