An End To End Transport Protocol For Extreme Wireless Network Environments
Upcoming SlideShare
Loading in...5

An End To End Transport Protocol For Extreme Wireless Network Environments






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

An End To End Transport Protocol For Extreme Wireless Network Environments An End To End Transport Protocol For Extreme Wireless Network Environments Presentation Transcript

  • 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
  • Overall Motivation
    • 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%.
    • 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.
  • Performance of TCP-SACK
    • TCP-SACK Performance degrades beyond an error rate of 5% PER.
    • Performance is also sensitive to RTT .
  • Goals
    • We pose the following questions..
    • 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?
  • 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
  • Approach
    • Tools available to us:
      • Method of getting congestion indication that is separate from packet loss due to errors: Explicit Congestion Notification (ECN)
      • Use error recovery methods beyond retransmission and timeouts to overcome packet loss, so that TCP’s performance is retained.
      • Use FEC on an end-end basis:
        • Dynamic knowledge of the loss information can be exploited by the end-system.
        • Track short term loss rates.
        • Protect data by using FEC proactively and reactively.
      • 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).
  • 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 adaptive EWMA approach to estimating loss is used.
  • 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.
  • Proactive and Reactive FEC in Action..
    • Data + PFEC are sent in the initial transmission.
    • Feed back from the receiver is used to determine strength of RFEC protection.
    • SACK retransmissions along with RFEC packets are used to recover the original data.
  • 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!
  • LT-TCP Big Picture
  • Simulation Setup
  • LT-TCP Performance
    • Performance of LT-TCP is much better compared to that of TCP-SACK
    • LT-TCP degrades gracefully (linear fall)
    • Relative insensitivity to RTT variation.
  • LT-TCP and TCP-SACK Performance
    • LT-TCP performance is good both with Uniform with Gilbert Loss Process.
    • Gilbert Loss Process
      • Error Rate toggles between 0.5p and 1.5p for an average PER of p .
      • Sojourn time is randomized around a mean period.
  • LT-TCP Component Contributions (Goodput)
    • Individual component contributions are shown.
    • Proactive FEC has the most significant impact.
  • LT-TCP Component Contributions (Timeout)
    • Contributions of components in reducing the incidences of timeouts is shown.
    • RFEC and PFEC are needed to reduce timeouts.
    • With just TCP-SACK and ECN schemes, timeouts are repeated and large though few in number.
  • LT-TCP Component Contributions (Cumulative Goodput)
    • Cumulative goodput for a representative pair of flows (1 TCP-SACK and 1 LT-TCP) are shown out of 10 flows total.
  • 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.
  • Comparison of Congestion Windows
    • 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%.
    • Congestion Window for TCP-SACK is as shown
    • Following a timeout, TCP-SACK recovers quickly and regains its fair share of the bandwidth.
    • It does not get beaten down by LT-TCP’s behavior.
  • LT-TCP Congestion Window
    • Congestion Window for LT-TCP is as shown
    • LT-TCP suffers a loss event during the loss period but does not suffer a timeout.
  • 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.
  • Thanks!
    • Researchers :
    • Vijay Subramanian:
      • [email_address] (Rensselaer Polytechnic Institute)
    • Shivkumar Kalyanaraman:
      • [email_address] (Rensselaer Polytechnic Institute)
    • K.K. Ramakrishnan ,
      • [email_address] (AT&T Labs Research)