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.
- Re: shim6-proto-07 review Brian E Carpenter
- Re: shim6-proto-07 review marcelo bagnulo braun
- shim6-proto-07 review Iljitsch van Beijnum
- Re: shim6-proto-07 review Wesley Eddy
- Re: shim6-proto-07 review Brian E Carpenter
- Re: shim6-proto-07 review Iljitsch van Beijnum
- Re: shim6-proto-07 review Wesley Eddy
- Re: shim6-proto-07 review Iljitsch van Beijnum
- Re: shim6-proto-07 review Wesley Eddy
- Re: shim6-proto-07 review Iljitsch van Beijnum
- Re: shim6-proto-07 review Brian E Carpenter
- Re: shim6-proto-07 review Iljitsch van Beijnum