[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim-aware transports
Pasi Sarolahti wrote:
I think it is good that the TCP (and other transport protocols)
interworking was brought up, and it would be good to write the issues
down in some document. The question is whether it should be part of some
existing document, or a separate document. To me the latter seems good
choice, because many of the issues would be common also to other
mechanisms than shim6 (HIP came to my mind first, and why not even
Yes, exactly. Even layer-two mobility events can change path
I have some comments about the TCP interworking, below..
On Sun, 2005-08-14 at 14:54 +0200, ext Iljitsch van Beijnum wrote:
This would allow for the following succession in TCP/shim developments:
- Initially, TCP would be unmodified, so the shim would use the
adaption layer to do address magic whenever the basic shim sublayer
determines reachability has changed.
- Next step: TCP is modified slightly to provide reachability hints
to the shim layer. The basic shim sublayer can optimize some of its
failure/reachability detection mechanism based on this.
I think it would be good also to have some kind of signal from shim to
TCP to indicate when path (address) has changed from quite early on
(somewhere between "initially" and "next step"). In response TCP should
re-initialize its congestion control and RTT parameters, and probe the
new path capacity in slow-start. The new path likely has different
properties, so slow-start is the correct way of re-probing the current
I'm not saying that the TRIGTRAN BoF was the canonical answer, but when
we were discussing TCP in TRIGTRAN, we pretty quickly converged on NOT
notifying transports when bandwidth available changed, because TCPs have
to respond to losses, and adding additional hints just adds stack
complexity beyond the complexity that is unavoidable.
Yeah, in a perfect world, we might slow-start, but in a perfect world,
users wouldn't hit "reload" on their browsers while we were
So, the TRIGTRAN answer was
- ignore apparent path changes.
- if you lose something, respond the same way you would have responded
to loss in the absence of a path change - even congestion avoidance
drops your congestion window in half, so if you have enough packets in
flight, you are already responding dramatically in something like one RTT.
Since ("how to lie with statistics") you have a 50-50 chance of landing
on a BETTER path, and you will have to respond to any losses using
existing mechanisms anyway, forcing slow start without encountering a
loss seemed like overkill, and even forcing congestion avoidance just
added state machine complexity without a lot of obvious benefit.
If people want to pursue this, let's pursue it in TSVWG, OK?
- Finally: TCP becomes aware of multiple addresses, and starts
keeping per-address pair RTT statistics. TCP moves to another address
pair either when the shim tells it to (because the shim detected a
problem) or when it determines another pair is "better" based on its
(TCP would need to maintain also per address-path cwnd and ssthresh, and
possibly other internal congestion control-related parameters, in
addition to RTT and friends)
Joe Touch can speak more definitively on this than I can, but my
understanding is that proposals that touch this much of TCP haven't been
widely deployed (for example,
ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt) - at least, that was the
case a couple of years ago, when I was still doing TSV stuff.
This seems a pretty significant change to TCP. Alternatively, if the
path changes are not expected to be very frequent, it might be
We're in one of two situations here - either path changes are rare
enough for TCP to be able to appropriately adjust to bandwidth changes
using only end-to-end (multiple-RTT) mechanisms, or they are common
enough that TCP is going to have horrible throughput, anyway.
My suggestion is to make the first assumption.
sufficient just to simply reset the congestion control and RTT
parameters upon path change, and proceed in slow-start. TCP should
anyway apply congestion window validation [RFC2861] for each of the per
path cwnd and ssthresh parameters, so after an idle period of few RTOs
(generally less than one minute) the effect would not be much different
for those paths that have not been used for a while.
Yeah, congestion window validation would be a good thing to do, and
modern TCPs actually do handle this correctly (older TCPs reset their
timers when they received a packet, and THEN checked the timer to see if
they needed to validate the congestion window. Amazingly, they never
needed to :-)