Re: shim6-proto-07 review

[Wesley Eddy <weddy@grc.nasa.gov>]

On Mon, Jan 08, 2007 at 04:34:10PM +0100, Iljitsch van Beijnum wrote:
> 
> >We have actually discussed and worked on a solution to this in TCPM  
> >that
> >is intended to work with shim6, among other protocols (including at
> >least mip4, mip6, and hip):
> >http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt
> 
> Good, let's put in a reference.
> 
> >I think this type of general solution is far preferable  
> >architecturally
> >than asking shim6 to differentiate between path/interface  
> >properties and
> >transport protocols and take special actions.
> 
> If the information is available, it doesn't make sense to ignore it.  
> I think it's entirely reasonable for TCP or other transport protocols  
> to have different behaviors for path changes where the speed  
> difference is 1:2 vs where the speed difference is 1:1000.

Well, even though the speed of the links may be known, the amount of
their capacity that is currently available at the time of a failover is
probably much less well known to the shims.  This knowledge also says
nothing about the paths after those links.  For these reasons, TCP has
to slow-start from an initial window anyways, so I do not see how
specific knowledge about the links can be easily used.

One other point is that setting the congestion window to some percentage
of its previous value based on the ratio of failover link capacity to
primary link capacity is fairly naive, and ignores the significant
amount of other relevent TCP state.  This is why I posted the link to
the TCP-RLCI internet-draft that also updates the ssthresh, the rtt
estimation, and the PMTUD state.  TCP is too complex for the shim6
protocol to tell it _specifically_ what to do, but TCP can easily be
smart enough to do the right thing if shim6 just lets it know that
there's been a failover.  The same goes for SCTP and DCCP.  This is why
I'd advise that asking the shim to publish a generic failover
advertisement within the local stack is the extent of what is specified.

-- 
Wesley M. Eddy
Verizon Federal Network Systems