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