[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim-aware transports

Pasi Sarolahti wrote:

Hi,

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
Mobile IP).

Yes, exactly. Even layer-two mobility events can change path characteristics.

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
path capacity.

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 slow-starting, either.

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 own statistics. 


(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 :-)

Spencer