An EndtoEnd Transport Protocol for Extreme Wireless Network Environments

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

• Vijay Subramanian, Shiv Kalyanaraman
• (Rensselaer Polytechnic Institute)
• K. K. Ramakrishnan (ATT 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 gt 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
Reed-Solomon FEC RS(N,K)
8
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 with RFEC packets are
  used to recover the original data.

/Rexmit
9
LT-TCP Big Picture
10
Adaptive Segmentation and PFEC Efficiency
Addition of PFEC. Total data PFEC
transmission window
Segmentation
Wasted FEC Reduces goodput
Recovered DATA Bytes
11
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
Loss(Congestion Windows)

• 5 TCP-SACK and 5 LT-TCP flows At t50s, 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 t50 secs
  shows
• Following a timeout, TCP-SACK recovers quickly.
• It does not get beaten down by LT-TCPs behavior
  during this vulnerable period.
• LT-TCP but does not suffer a timeout during the
  loss period

18
Latency Results
Shortened RS Codes Allows us to use RS codes
when the amount of data bytes we have is small
relative to the natural block size of RS codes
(e.g.255,223). Effectively, we can zero-pad the
set of data bytes when encoding. These zero pads
are not transmitted. The receiver can use signals
in packet header to determine amount of padding
and decodes only the original data bytes. No
additional latency is incurred.

• Comparison of File Transfer Latency for TCP-SACK
  and LT-TCP.
• When the amount of application data to be sent is
  small relative to the window/block
• We use shortened RS codes (pad 0s to compute FEC
  during encoding process) up to the block size
  (e.g., block size is 10 (6 data, 4 FEC). But 3
  data packets only. Then pad 3 0 packets, and
  compute the 4 FEC). Send only the 3 data and 4
  FEC. Do NOT send the 0 packets no extra data
  is sent
• The decoder will account for the 3 0 packets.
• No additional latency is incurred.

19
Contribution/Value of LT-TCP Components
20
Window Evolution and MSS Stats for PER 10
Minimum Window Granulation of congestion window
is 10 packets.
21
Evolution of MSS w.r.t. Time
22
MSS Distribution for PER of 10
MSS Stats Average MSS 1060 bytes Average MSS is
pretty high leading to low wastage Min Mss 200
bytes Max Mss 1500 bytes
23
Link-Layer Interactions and Interference

• 802.11b WLANs operate in unlicensed ISM band
• 2.412 - 2.480 GHz
• Can operate at 11 , 5.5 , 2 or 1 Mb/s raw data
  rate with rate adaptation algorithms that are
  typically proprietary.
• Smaller Cells without fine-grained adaptive
  power-control Higher probability of
  interference.
• Rate adaptation counter-productive with CSMA/CA
  MAC.
• Cross-system Interference and Co-channel
  interference are two important causes of packet
  loss.
• Sustained packet loss leads to capture effects.
• Residual loss rate on these wireless links can be
  non-trivial.
• PHY/MAC protocols can confuse interference with
  noise and perform rate-adaptation (a.k.a.
  adaptive modulation/coding).
• With rate-adaptation, packets can be on air
  longer (we experiment with it turned off)
• End-End residual loss and long variable delays
  lead to
• timeouts at TCP-SACK, low throughput/goodput and
  poor utilization on an end-end basis.
• Loss-Tolerant TCP (LT-TCP) is designed to be
  robust under high end-end loss rates
• avoids timeouts and can provide high goodput even
  under extreme scenarios (50 average PER).
• Can it help improve performance?

24
Co-Channel Interference in 802.11

• Disruption is manifested as capture in 802.11 and
  is caused due to interference.
• Other WLAN systems using the same frequency in
  close proximity.
• Hidden Nodes in Remote Cells
• Node 1 is uploading data through BS-1
• Node 2 is downloading a large file from BS-2
• Capturing the channel
• Node 1 is effectively experiencing capture for
  250 ms every 2 seconds.

25
Results for Co-Channel Interference

• When RTT gt 100 ms, the residual loss of even one
  WLAN hop
• (subject to capture effects) can lead to low
  TCP-SACK throughput
• LT-TCP modest parameter changes at the link/MAC
  restores performance.

26
Preview of Results Transport Link Protocol
27
Summary

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

28
Thanks!
Thanks also for the support from AFOSR ESC
Hanscom and MIT Lincoln Laboratory, Letter No.
14-S-06-0206

• Researchers
• Vijay Subramanian
• subrav_at_rpi.edu (Rensselaer Polytechnic Institute)
  
• Shivkumar Kalyanaraman
• shivkuma_at_ecse.rpi.edu (Rensselaer Polytechnic
  Institute)
• K.K. Ramakrishnan,
• kkrama_at_research.att.com (ATT Labs Research)

29
Extra Slide