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

Re: shim-aware transports



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

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.

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

This seems a pretty significant change to TCP. Alternatively, if the
path changes are not expected to be very frequent, it might be
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.

- Pasi

Attachment: signature.asc
Description: This is a digitally signed message part