Re: shim6-proto-07 review

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 08 January 2007 15:34 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Mon, 08 Jan 2007 15:36:46 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <3C2B5C6C-39B0-49C7-9CF7-C97F3EE941CD@muada.com>
Cc: Brian Carpenter <brc@zurich.ibm.com>, shim6-wg <shim6@psg.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: shim6-proto-07 review
Date: Mon, 08 Jan 2007 16:34:10 +0100
To: weddy@grc.nasa.gov

On 3-jan-2007, at 17:20, Wesley Eddy wrote:

> 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 someone cares to suggest something different...

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

Let me explain why I make a big deal about the speed difference  
between the primary and the backup interface. When designing a  
multihomed network, the speed differences between the different  
possible configurations after different kinds of outages is an  
important concern. What I've seen in practice is that a backup that  
is 10% or less of the bandwidth of the original bandwidth used before  
the failure, is completely useless because congestion is immediate,  
persistent and fatal. I always recommend a minimum of 25% backup  
capacity. So far so good for multihomed _sites_ where these decisions  
are made explicitly. But shim6 can also easily work on a single host  
where the speed difference between the fastest interface (100 - 1000  
Mbps) and the slowest (9.6 - 56 kbps) is easily four orders of  
magnitude. Ignoring this will create problems.

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