1. 15-441 Computer Networking TCP Enhancements

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

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

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

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

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

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

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

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

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

11. 0 3 2 1 2 2 2 Loss  Congestion Wireless Bit-Errors Router Computer 1 Computer 2 Loss  Congestion Wireless Burst losses lead to coarse-grained timeouts Result: Low throughput

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

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

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

15. 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 link Wireless link ARQ/FEC

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

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

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

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