Download Split-TCP: State of the Union Address

Split-TCP: State of the Union
Address
Dan Berger
03/03/03
Adgenda
Proxied or “Split” TCP Conceptual Overview
Previous Investigation
Current Work
Results and Analysis
Conclusion
Conceptual Overview
The Problem(s)
TCP can’t distinguish link failure from
congestion.
Results in lowered throughput
Effect is magnified on longer (hop-count)
connections
Concepts (Cont.)
The Proposal
Designate nodes along the path to be packet-level
proxies.
These proxies buffer segments until they’ve been
received (and acknowledged) by the next proxy
(or destination)
If the packet isn’t ack’d in “reasonable” time –
they resend.
Details, Details…
Proxy selection must be distributed and
dynamic, to accommodate mobility in the
network.
The proxies should be as stateless as possible
– specifically, keeping per-flow state is bad.
Previous Investigation
In a simple string topology “Split-TCP is able
to provide a better overall throughput than
TCP, up to about 15%”
In a complex topology with mobility, “the
total throughput improves with the use of
proxies by about 5% to about 30%”
Current Work
The initial goal was to implement a linux
kernel implementation.
This work was stymied by a lack of detailed
understanding of the desired behavior of the
protocol.
Work done last quarter found issues with the
current simulation model which suggested it
needed to be revisited.
Forward, march!
We decided to turn our attention to building a
more accurate and usable simulation model in
ns.
The specific issues in the existing model we
wanted to address were:
Lack of end-to-end window management
Lack of dynamic proxy selection
Proxy-To-Proxy Window Mgmt.
The initial simulation model literally
decomposed a long TCP connection into
multiple shorter connections.
This had undesired (and unforeseen)
consequences.
s
t
Static Proxy Selection
Additionally, this decomposition was done
using global routing knowledge.
To accommodate mobility, the proxy selection
code was re-run periodically.
This meant that new TCP connections were
established, and the old ones allowed to “drain.”
The New Model
The new simulation model consists of three
components:
SplitTCPSource
SplitTCPWedge
SplitTCPSink
The Source and Sink are simply
specializations of TCPSource and TCPSink,
respectively.
SplitTCPWedge
In order to perform dynamic proxy selection,
one needed to be able to inspect each packet
received by a node.
Then the decision to proxy can be based on
whatever criteria seem appropriate.
All “Split-TCP enabled” nodes run the wedge
code.
An Anonymous NS Node
Better, Stronger, Faster
SplitTCPWedge
Model Summary
This new simulation model uses a TCP
session established between the source and
target, and dynamic proxy selection is
performed along the path.
s
t
End-To-End Window Mgmt.
The TCP session performs window
management “as usual” – but control can be
tweaked both manually as well as by the
Wedge.
For instance, end-to-end ACKs can be skipped,
the congestion window can be managed based on
inter-proxy ACKs, etc.
Proxy Selection
Each node decides, independently, (currently
based on hops since last proxy and their
current backlog) if they should proxy a
packet.
Proxying does not keep per-flow state.
Retransmissions are scheduled based on the
current inter-proxy round trip time estimate.
Results
Current simulations show a  10%
degradation in throughput vs. Standard TCP.
With parameter tweaking, this degradation
varies, but Split TCP never equals standard
TCP.
Analysis
One identified cause of the dramatically
different behavior of the old and new
simulation models relates to out-of-order
packet delivery.
In the old model, the packet stream was
“reassembled” at each proxy – and bytes were
only forwarded once they arrived in order.
Per-flow state at each proxy.
In the new model, this is not the case.
Parameterization
By tuning various parameters – including
initial congestion window, window growth
factors, etc – the throughput of Split TCP
can be improved.
There are over 150 tuning parameters in the
“stock” NS TCP code. If they were all just
binary parameters that’s still 2150 possible
configurations!
Conclusion
We’re trying to determine rational next steps:
Do we continue the search for the “magic” set of
parameters?
Do we examine the behavior of the new model
in scenarios with mobility?
Few answers, many more questions.