Transcript An End-to-End Transport Protocol for Extreme Wireless Network Environments TCP Sender TCP Receiver Vijay Subramanian, Shiv Kalyanaraman (Rensselaer Polytechnic Institute) K.

An End-to-End Transport Protocol for
Extreme Wireless Network Environments
TCP Sender
TCP Receiver
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
1
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
2
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%.
3
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?
4
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 ECNcapable.
– 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.
5
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.
6
Reed-Solomon FEC: RS(N,K)
>= K of N
received
RS(N,K)
Recover K
data packets!
FEC (N-K)
Block
Size
(N)
Lossy Network
Data = K
Recovery possible if we receive at
least K packets out of N
7
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
PROACTIVE
FEC (PFEC)
Pfec= f(,)
along with RFEC
packets are used
to recover the
original data.
REACTIVE
FEC (RFEC)
Y = g(p,,X)
8
LT-TCP Big Picture
≤ Window
9
Adaptive Segmentation and PFEC Efficiency
Incoming DATA Bytes
Segmentation
Addition of PFEC.
Total data + PFEC
= transmission window
Wasted FEC:
Reduces goodput
Recovered DATA Bytes
10
Adaptive Segmentation, PFEC and RFEC Efficiency
Incoming DATA Bytes
Segmentation
Addition of PFEC
DATA Bytes Partially Recovered
Send RFEC
Recovered DATA Bytes
Wasted FEC:
Reduces goodput
11
Simulation Setup
12
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 TCPSACK 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.
13
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)
14
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 TCPSACK and 1 LT-TCP)
are shown out of 10
flows total.
• We see that LT-TCP
(starting later)
achieves fair allocation
15
Fairness Comparisons
• Instantaneous Goodput
for a representative
pair of flows (1 TCPSACK and 1 LT-TCP)
are shown out of 10
flows total.
• The Goodput was
measured in intervals
of 100ms.
16
Co-existence of LT-TCP and SACK: Reaction to Loss
Congestion 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 TCPSACK is as shown
• Recovery of cwnd for TCPSACK after t=50 secs shows
– Following a timeout, TCPSACK 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
17
Latency Results
• Comparison of File Transfer Latency for TCP-SACK
and LT-TCP.
18
Preview of Results: Transport + Link Protocol
Results
19
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.
20
Thanks!
Thanks also for the support from AFOSR ESC Hanscom and MIT Lincoln Laboratory,
Letter No. 14-S-06-0206
Researchers:
•Vijay Subramanian:
•[email protected] (Rensselaer Polytechnic Institute)
•Shivkumar Kalyanaraman:
•[email protected] (Rensselaer Polytechnic Institute)
•K.K. Ramakrishnan,
•[email protected] (AT&T Labs Research)
21