Re: shim6-proto-07 review
Wesley Eddy <weddy@grc.nasa.gov> Mon, 08 January 2007 16:11 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Mon, 08 Jan 2007 16:15:01 +0000
Date: Mon, 08 Jan 2007 11:11:12 -0500
From: Wesley Eddy <weddy@grc.nasa.gov>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: Brian Carpenter <brc@zurich.ibm.com>, shim6-wg <shim6@psg.com>, lars.eggert@nokia.com, simon.schuetz@netlab.nec.de
Subject: Re: shim6-proto-07 review
Message-ID: <20070108161112.GB30296@grc.nasa.gov>
Reply-To: weddy@grc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1i
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
- 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