Presentation on theme: "Hui Zhang, Fall 2012 1 15-441 Computer Networking TCP Enhancements."— Presentation transcript:
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