Re: shim6-proto-07 review

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

On Wed, Jan 03, 2007 at 04:55:24PM +0100, Iljitsch van Beijnum wrote:
> On 3-jan-2007, at 16:33, Brian E Carpenter wrote:
> 
> >Explain why TCP will react any differently to a sudden path
> >change due to shim6, compared to a sudden path change for
> >any other reason. I don't understand what is specific
> >to shim6.
> 
> The difference is that with shim6, we get to avoid massive congestion  
> when failing over from a very fast to a very slow path.
> 
> If there is no consensus for a general recommendation for slow start  
> when failing over, maybe we can make this specific to the situation  
> where a host fails over from a fast to a slow interface:
> 
> "When the shim protocol triggers the selection of a new path, and  
> this path utilizes a lower-bandwidth interface than the interface of  
> the prior path, it is recommended that the TCP window for any  
> affected TCP sessions are reduced relative to the reduction in  
> interface bandwidth. Alternatively, TCP slow start can be initiated.  
> For non-TCP protocols, similar measures are recommended where  
> available."

I'm all in favor of helping TCP to "do the right thing", but I think
this proposal (and specifically that suggested text) misses the mark.

If this direction were to be pursued, I'd recommend not making any
distinction between fast and slow interfaces, but rather specifying
one behavior that is followed in all cases.

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

In my opinion, all that we need to ask of shim6 is that implementations
provide some way for higher layers to recognize when a failover has
occurred -- that failovers not be totally transparent.  The details of
how higher layers (including TCP) respond is up to them.

-- 
Wesley M. Eddy
Verizon Federal Network Systems