An End-to-End Transport Protocol for Extreme Wireless Network Environments

1. TCP Receiver TCP Sender Packets, FEC Status Reports Repairs An End-to-End Transport Protocol for Extreme Wireless Network Environments Vijay Subramanian, Shiv Kalyanaraman (Rensselaer Polytechnic Institute) K. K. Ramakrishnan(AT&T Labs Research) We gratefully acknowledge support from AFOSR ESC Hanscom and MIT Lincoln Laboratory, Letter No. 14-S-06-0206

2. TCP-SACK Performance under Lossy Conditions • Exponential falloff in performance with PER (degrades beyond an error rate of 5% PER) • Performance quite bad for the combination: • 5%+ PER • 100 ms+ RTT

3. Overall Motivation • Wireless channels becoming more pervasive • With mesh networks (infrastructure or community) it is likely that more than the last hop will be wireless. • Wireless links: • individual links can experience loss that can be high (even 10-15%) in transient situations, until power and link rate adjustments kick in • interference can also result in high loss rates. • E.g., ad-hoc networks, Mesh network, WiLAN. • TCP response to errors and congestion is the same: • drop the window, and thus reduce load on the network • In the worst case, timeout when particular sequence of packets get lost (retransmits, entire window) • TCP was designed for congestion, loss rate in the 1-2% max. range. • TCP suffers significant timeout penalties with erasure rates > 5%.

4. Goals • Dynamic Range: • Can we extend the dynamic range of TCP into high loss regimes? • Can TCP perform close to the theoretical capacity achievable under high loss rates? • Congestion Response: • How should TCP respond to notifications due to congestion.. • … but not respond to packet erasures that do not signal congestion? • Mix of Reliability Mechanisms: • What mechanisms should be used to extend the operating point of TCP into loss rates from 0% - 50 % packet loss rate? • How can Forward Error Correction (FEC) help? • How should the FEC be split between sending it proactively (insuring the data in anticipation of loss) and reactively (sending FEC in response to a loss)? • Timeout Avoidance: • Timeouts: Useful as a fall-back mechanism but wasteful otherwise especially under high loss rates. • How can we add mechanisms to minimize timeouts?

5. Building Blocks … • ECN-Only:We infer congestion solely from ECN markings. Window is cut in response to • ECN signals: which means that hosts/routers have to be ECN-capable. • Timeouts: The response to a timeout is the same as before. • Window Granulation and Adaptive MSS: We ensure that the window always has at least G segments at all times. • Window size in bytes initially is the same as normal SACK TCP. • Initial segment size is small to accommodate G segments. • Packet size is continually changed so that we have at least G segments. Once we have G segments, packet size increases with window size. • Loss Estimation: The receiver continually tracks the loss rate and provides a running estimate of perceived loss back to the TCP sender through ACKs. An EWMA approach to estimating loss is used.

6. Building Blocks … • Proactive FEC: TCP sender sends data in blocks where the block contains K data segments and R FEC packets. The amount of FEC protection (K) is determined by the current loss estimate. • Proactive FEC based upon estimate of per-window loss rate (Adaptive) • Reactive FEC: Reactive FEC to complement retransmissions. • Upon receipt of 1 or 2 dupacks, Reactive FEC packets are sent based on the following criteria. • Number of Proactive FEC packets already sent. • Number of holes still left in the decoding block. • Loss rate currently estimated.

7. Recover K data packets! >= K of N received RS(N,K) FEC (N-K) Block Size (N) Lossy Network Data = K Recovery possible if we receive at least K packets out of N Reed-Solomon FEC: RS(N,K)

8. PROACTIVE FEC (PFEC) Pfec=f(,) REACTIVE FEC (RFEC) Y =g(p,,X) Hybrid ARQ/FEC Scheme Structure • Data + PFEC are sent in the initial transmission. • Feed back from the receiver is used to determine strength of RFEC protection. • SACK retransmissions along withRFEC packets are used to recover the original data. /Rexmit

9. ≤ Window LT-TCP Big Picture

10. Incoming DATA Bytes Adaptive Segmentation and PFEC Efficiency Addition of PFEC. Total data + PFEC = transmission window Segmentation Wasted FEC: Reduces goodput Recovered DATA Bytes

11. Incoming DATA Bytes Adaptive Segmentation, PFEC and RFEC Efficiency Segmentation Addition of PFEC DATA Bytes Partially Recovered Wasted FEC: Reduces goodput Send RFEC Recovered DATA Bytes

12. Simulation Setup

13. LT-TCP Performance • Performance of LT-TCP is much better compared to that of TCP-SACK • LT-TCP degrades gracefully (nearly linear degradation with loss rate) • Relatively insensitive to RTT variation compared to TCP-SACK because the finer granulation of window (smaller MSS) allows a flow of acks that enables the window to grow at a rate not as dependent on RTT.

14. Comparison of Performance with Bursty Losses • “Gilbert” Loss Process • Error Rate switchesggles between 0.5p and 1.5p for an average PER of p. • Sojourn time is randomized around a mean period of 10 ms (+- 1ms). • LT-TCP performance is still good with both Uniform with “Gilbert” Loss Process because of its ability to deal with variation in the loss process with use of RFEC (which is over-provisioned slightly to minimize timeouts and handle variability in loss)

15. Co-existence of TCP SACK and LT-TCP Cumulative Goodput • We test fairness under a lossless scenario. • Cumulative goodput for a representative pair of flows (1 TCP-SACK and 1 LT-TCP) are shown out of 10 flows total. • We see that LT-TCP (starting later) achieves fair allocation

16. Fairness Comparisons • Instantaneous Goodput for a representative pair of flows (1 TCP-SACK and 1 LT-TCP) are shown out of 10 flows total. • The Goodput was measured in intervals of 100ms.

17. Co-existence of LT-TCP and SACK: Reaction to LossCongestion Windows • 5 TCP-SACK and 5 LT-TCP flows At t=50s, a burst error event occurs for a 100ms period at with PER set to 50%. • Congestion Window for TCP-SACK is as shown • Recovery of cwnd for TCP-SACK after t=50 secs shows • Following a timeout, TCP-SACK recovers quickly. • It does not get beaten down by LT-TCP’s behavior during this vulnerable period. • LT-TCP but does not suffer a timeout during the loss period

18. Latency Results • Comparison of File Transfer Latency for TCP-SACK and LT-TCP.

19. Preview of Results: Transport + Link Protocol Results

20. Summary • LT-TCP provides robustness even under conditions of large and bursty loss rates. • Avoids timeouts • High Goodput • Increased Dynamic Range • Current and future work includes link-level enhancements that provide bounded delay, low residual loss rate and high goodput even under disruption scenarios.

21. Thanks! Thanks also for the support from AFOSR ESC Hanscom and MIT Lincoln Laboratory, Letter No. 14-S-06-0206 • Researchers: • Vijay Subramanian: • subrav@rpi.edu(Rensselaer Polytechnic Institute) • Shivkumar Kalyanaraman: • shivkuma@ecse.rpi.edu(Rensselaer Polytechnic Institute) • K.K. Ramakrishnan, • kkrama@research.att.com(AT&T Labs Research)