An End To End Transport Protocol For Extreme Wireless Network Environments


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • An End To End Transport Protocol For Extreme Wireless Network Environments

    1. 1. An End-to-End Transport Protocol for Extreme Wireless Network Environments Vijay Subramanian, Shiv Kalyanaraman (Rensselaer Polytechnic Institute) K. K. Ramakrishnan (AT&T) Status Reports Packets, FEC Repairs TCP Sender TCP Receiver
    2. 2. Overall Motivation <ul><li>TCP response to errors and congestion is the same: </li></ul><ul><ul><li>drop the window, and thus reduce load on the network </li></ul></ul><ul><ul><li>In the worst case, timeout when particular sequence of packets get lost (retransmits, entire window) </li></ul></ul><ul><li>TCP was designed for congestion, loss rate in the 1-2% max. range. </li></ul><ul><ul><li>TCP suffers significant timeout penalties with erasure rates > 5%. </li></ul></ul><ul><li>Wireless channels becoming more pervasive </li></ul><ul><ul><li>With mesh networks (infrastructure or community) it is likely that more than the last hop will be wireless. </li></ul></ul><ul><li>Wireless links: </li></ul><ul><ul><li>individual links can experience loss that can be high (even 10-15%) in transient situations, until power and link rate adjustments kick in </li></ul></ul><ul><ul><li>interference can also result in high loss rates. </li></ul></ul><ul><ul><li>E.g., ad-hoc networks, Mesh network, WiLAN. </li></ul></ul>
    3. 3. Performance of TCP-SACK <ul><li>TCP-SACK Performance degrades beyond an error rate of 5% PER. </li></ul><ul><li>Performance is also sensitive to RTT . </li></ul>
    4. 4. Goals <ul><li>We pose the following questions.. </li></ul><ul><li>Dynamic Range: </li></ul><ul><ul><li>Can we extend the dynamic range of TCP into high loss regimes? </li></ul></ul><ul><ul><li>Can TCP perform close to the theoretical capacity achievable under high loss rates? </li></ul></ul><ul><li>Congestion Response: </li></ul><ul><ul><li>How should TCP respond to notifications due to congestion.. </li></ul></ul><ul><ul><li>… but not respond to packet erasures that do not signal congestion? </li></ul></ul><ul><li>Mix of Reliability Mechanisms: </li></ul><ul><ul><li>What mechanisms should be used to extend the operating point of TCP into loss rates from 0% - 50 % packet loss rate? </li></ul></ul><ul><ul><li>How can Forward Error Correction (FEC) help? </li></ul></ul><ul><ul><li>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)? </li></ul></ul><ul><li>Timeout Avoidance: </li></ul><ul><ul><li>Timeouts: Useful as a fall-back mechanism but wasteful otherwise especially under high loss rates. </li></ul></ul><ul><ul><li>How can we add mechanisms to minimize timeouts? </li></ul></ul>
    5. 5. SENDER RECEIVER Available Capacity Loss Feedback Through Acknowledgements X X X – Packet Erasure Capacity Used TCP uses Loss Feedback to Estimate Available Capacity Capacity Used Erasure Recovery/ Loss Estimation Adaptive MSS/ Proactive and Reactive FEC LT-TCP: Adaptive Mechanisms to Reinstate Performance
    6. 6. Approach <ul><li>Tools available to us: </li></ul><ul><ul><li>Method of getting congestion indication that is separate from packet loss due to errors: Explicit Congestion Notification (ECN) </li></ul></ul><ul><ul><li>Use error recovery methods beyond retransmission and timeouts to overcome packet loss, so that TCP’s performance is retained. </li></ul></ul><ul><ul><li>Use FEC on an end-end basis: </li></ul></ul><ul><ul><ul><li>Dynamic knowledge of the loss information can be exploited by the end-system. </li></ul></ul></ul><ul><ul><ul><li>Track short term loss rates. </li></ul></ul></ul><ul><ul><ul><li>Protect data by using FEC proactively and reactively. </li></ul></ul></ul><ul><ul><li>FEC can work in a coordinated fashion with TCP’s window mechanisms to optimize the usage of FEC within a window (which is not available at the link level). </li></ul></ul>
    7. 7. Building Blocks … <ul><li>ECN-Only : We infer congestion solely from ECN markings. Window is cut in response to </li></ul><ul><ul><li>ECN signals: which means that hosts/routers have to be ECN-capable. </li></ul></ul><ul><ul><li>Timeouts: The response to a timeout is the same as before. </li></ul></ul><ul><li>Window Granulation and Adaptive MSS : We ensure that the window always has at least G segments at all times. </li></ul><ul><ul><li>Window size in bytes initially is the same as normal SACK TCP. </li></ul></ul><ul><ul><li>Initial segment size is small to accommodate G segments. </li></ul></ul><ul><ul><li>Packet size is continually changed so that we have at least G segments. Once we have G segments, packet size increases with window size. </li></ul></ul><ul><li>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 adaptive EWMA approach to estimating loss is used. </li></ul>
    8. 8. Building Blocks … <ul><li>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. </li></ul><ul><ul><li>Proactive FEC based upon estimate of per-window loss rate (Adaptive) </li></ul></ul><ul><li>Reactive FEC : Reactive FEC to complement retransmissions. </li></ul><ul><ul><li>Upon receipt of 1 or 2 dupacks , Reactive FEC packets are sent based on the following criteria. </li></ul></ul><ul><ul><ul><li>Number of Proactive FEC packets already sent. </li></ul></ul></ul><ul><ul><ul><li>Number of holes still left in the decoding block. </li></ul></ul></ul><ul><ul><ul><li>Loss rate currently estimated. </li></ul></ul></ul>
    9. 9. Proactive and Reactive FEC in Action.. <ul><li>Data + PFEC are sent in the initial transmission. </li></ul><ul><li>Feed back from the receiver is used to determine strength of RFEC protection. </li></ul><ul><li>SACK retransmissions along with RFEC packets are used to recover the original data. </li></ul>
    10. 10. Reed-Solomon FEC: RS(N,K) Recovery possible if we receive at least K packets out of N Data = K FEC (N-K) Block Size (N) RS(N,K) >= K of N received Lossy Network Recover K data packets!
    11. 11. LT-TCP Big Picture
    12. 12. Simulation Setup
    13. 13. LT-TCP Performance <ul><li>Performance of LT-TCP is much better compared to that of TCP-SACK </li></ul><ul><li>LT-TCP degrades gracefully (linear fall) </li></ul><ul><li>Relative insensitivity to RTT variation. </li></ul>
    14. 14. LT-TCP and TCP-SACK Performance <ul><li>LT-TCP performance is good both with Uniform with Gilbert Loss Process. </li></ul><ul><li>Gilbert Loss Process </li></ul><ul><ul><li>Error Rate toggles between 0.5p and 1.5p for an average PER of p . </li></ul></ul><ul><ul><li>Sojourn time is randomized around a mean period. </li></ul></ul>
    15. 15. LT-TCP Component Contributions (Goodput) <ul><li>Individual component contributions are shown. </li></ul><ul><li>Proactive FEC has the most significant impact. </li></ul>
    16. 16. LT-TCP Component Contributions (Timeout) <ul><li>Contributions of components in reducing the incidences of timeouts is shown. </li></ul><ul><li>RFEC and PFEC are needed to reduce timeouts. </li></ul><ul><li>With just TCP-SACK and ECN schemes, timeouts are repeated and large though few in number. </li></ul>
    17. 17. LT-TCP Component Contributions (Cumulative Goodput) <ul><li>Cumulative goodput for a representative pair of flows (1 TCP-SACK and 1 LT-TCP) are shown out of 10 flows total. </li></ul>
    18. 18. Fairness Comparisons <ul><li>Instantaneous goodput for a representative pair of flows (1 TCP-SACK and 1 LT-TCP) are shown out of 10 flows total. </li></ul><ul><li>The goodput was measured in intervals of 100ms. </li></ul>
    19. 19. Comparison of Congestion Windows <ul><li>Error free simulation with 5 TCP-SACK and 5 LT-TCP flows except for a 100ms period at t=50s with PER set to 50%. </li></ul><ul><li>Congestion Window for TCP-SACK is as shown </li></ul><ul><li>Following a timeout, TCP-SACK recovers quickly and regains its fair share of the bandwidth. </li></ul><ul><li>It does not get beaten down by LT-TCP’s behavior. </li></ul>
    20. 20. LT-TCP Congestion Window <ul><li>Congestion Window for LT-TCP is as shown </li></ul><ul><li>LT-TCP suffers a loss event during the loss period but does not suffer a timeout. </li></ul>
    21. 21. Summary <ul><li>LT-TCP provides robustness even under conditions of large and bursty loss rates. </li></ul><ul><ul><li>Avoids timeouts </li></ul></ul><ul><ul><li>High Goodput </li></ul></ul><ul><ul><li>Increased Dynamic Range </li></ul></ul><ul><li>Current and future work includes link-level enhancements that provide bounded delay, low residual loss rate and high goodput even under disruption scenarios. </li></ul>
    22. 22. Thanks! <ul><li>Researchers : </li></ul><ul><li>Vijay Subramanian: </li></ul><ul><ul><li>[email_address] (Rensselaer Polytechnic Institute) </li></ul></ul><ul><li>Shivkumar Kalyanaraman: </li></ul><ul><ul><li>[email_address] (Rensselaer Polytechnic Institute) </li></ul></ul><ul><li>K.K. Ramakrishnan , </li></ul><ul><ul><li>[email_address] (AT&T Labs Research) </li></ul></ul>