Hui Zhang, Fall Computer Networking TCP Enhancements

Hui Zhang, Fall Overview  TCP is a general purpose transport protocol  Design decisions are made based on a set of assumptions  TCP performance suffers when one or more assumptions do not hold in some application scenario’s  We want to understand -Common scenario’s when standard TCP does not perform well -What assumptions are broken in each scenario? -What different design decisions can be made to improve TCP performance in each scenario? -

Hui Zhang, Fall Scenario 1: Network With Large Delay Bandwidth Product  Example: a supercomputer in UIUC communicating with another supercomputer in CERN of Switzerland over a 10Gbps network  Assume round trip time (RTT) is 200 ms  What is the maximum throughput with standard TCP?

Hui Zhang, Fall The Key Formula and The Answer  MaxThroughput <= MaxWindowSize/RTT  Reasons: -MaxWindowSize is the maximum of outstanding bytes a sender can send before receiving the first acknowledgement packet - RTT is the minimum period between the time the first byte sent by the sender and the first ack (with respect to the first bye) is received by the sender  What is the maximum window size in TCP? -64 KB as limited by the 16 bits window size in TCP header  Therefore, the answer is 2.56 Mbps (64 KB/200ms) for one TCP connection

Hui Zhang, Fall TCP Large Window Option  TCP option allows additional 14 bits window size  The total window size up to 30 bits (1GB)  Question: what is the minimum additional number of bits for the window that the supercomputers need to use to fully utilize the 10Gbps link?  Answer -Window size in number of bytes: 250 GB (10Gbps * 200ms/8) -# of bits needed to encode the window: 28 bits -# of additional bits: 12

Hui Zhang, Fall Large Delay Bandwidth Network  In the previous example, when the link is fully utilized, how many packets (TCP segments) are in transit before the 1 st ack is received by the sender?  For simplicity assume each segment has 1KB payload  The answer is 250,000 (250MB/1KB)

Hui Zhang, Fall Flow Control vs. Congestion Control in Large Delay Bandwidth Networks  TCP’s sender window is limited by both awnd (for flow control purpose) and cwnd (for congestion purpose)  The previous example considers only the limitation imposed by flow control  Now let’s consider the effect of congestion control -Assuming NO packet loss, how much time does it take for the sender cwnd to grow to 1GB? You should try to work this work yourself -What happens if there are multiple packet losses in one window?

Hui Zhang, Fall Implication of Decision of Using Cumulative Ack in TCP  Standard TCP uses cumulative ack -Plus: robust with respect to lost acks -Minus: not robust with respect to lost packets  The drawback of cumulative ack is more serious in networks with networks with large delay bandwidth product -Large number of packets per RTT -The sender learns only one packet loss per RTT -A small number of packet losses can result in Retransmission Timeout (RTO) -With a RTO, the sender will retransmit all packets starting from the packet that causes the timeout -many of these packets may have been received by the receiver, however, the sender won’t be able to know --- the cumulative ack does not provide this information!

Hui Zhang, Fall TCP Selective Ack Option  Receivers informs the sender about each of packets that has been received successfully  Sender transmits only the packet that have not been acked

Hui Zhang, Fall Scenario 2: Performance Degradation in Wireless Networks Time (s) Sequence number (bytes) TCP Reno (280 Kbps) Expected TCP performance (1.30 Mbps) 2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN

Hui Zhang, Fall Wireless Bit-Errors Router Computer 2Computer Loss  Congestion Burst losses lead to coarse-grained timeouts Result: Low throughput Loss  Congestion Wireless

Hui Zhang, Fall TCP Problems Over Noisy Links  Wireless links are inherently error-prone -Fades, interference, attenuation -Errors often happen in bursts  TCP cannot distinguish between corruption and congestion -TCP unnecessarily reduces window, resulting in low throughput and high latency  Burst losses often result in timeouts  Sender retransmission is the only option -Inefficient use of bandwidth

Hui Zhang, Fall Proposed Solutions  Incremental deployment -Solution should not require modifications to fixed hosts -If possible, avoid modifying mobile hosts  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

Hui Zhang, Fall Approach Styles (End-to-End)  Improve TCP implementations -Not incrementally deployable -Improve loss recovery (SACK, NewReno) -Help it identify congestion (ELN, ECN) ACKs include flag indicating wireless loss -Trick TCP into doing right thing  E.g. send extra dupacks Wired linkWireless link

Hui Zhang, Fall Approach Styles (Link Layer)  More aggressive local rexmit than TCP -Bandwidth not wasted on wired links  Possible adverse interactions with transport layer -Interactions with TCP retransmission -Large end-to-end round-trip time variation  FEC does not work well with burst losses Wired linkWireless link ARQ/FEC

Hui Zhang, Fall Scenario 3: Asymmetric TCP  Example of Asymmetric networks -Cable modems: 10 Mbps down, 512 kbps up -ADSL: 8 Mbps down, 1 Mbps up -May also due to congested condition on reverse path  Forward path throughout may be smaller than forward path link capacity, why?  Slower bandwidth on reverse path stretches out ACKs (ACK dilation)

Hui Zhang, Fall Scenario 4: Small File and Transaction Applications  Most files are smaller than 1 KB -One TCP segment  No chance for fast recovery/fast retransmission (why?)  Packet loss results in RTO

Hui Zhang, Fall Summary: TCP Key Design Decisions & Assumptions  Application: large number of bytes & average throughput -What about small file and transaction applications?  Packet drop is congestion signal -Wireless network?  Cumulative ack -Single packet loss with large RTT*BW environment  16 bits win size -Large RTT*BW environment  Ack clocking -Asymmetric path

Hui Zhang, Fall Tradeoffs Between General-Purpose Protocol vs. Special Purpose Protocol  TCP is general purpose protocol -One size hard to fit for all  Why not developing special purpose protocol? -Metcalf’s law of network utility -There is huge value just to be able to communicate with anyone  TCP option strikes the balance -Backward compatible with hosts not implementing the options (still be able to communicate, may not be high performance) -Two hosts both implementing the same option can take advantage of the benefit of the option  TCP option does incur additional complexity and overhead