Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
Bernard Aboba <aboba@internaut.com> Fri, 23 November 2007 14:05 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZAG-0003e5-VN; Fri, 23 Nov 2007 09:05:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZAE-0003dn-U0 for ietf@ietf.org; Fri, 23 Nov 2007 09:05:51 -0500
Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvZAB-00017J-0q for ietf@ietf.org; Fri, 23 Nov 2007 09:05:50 -0500
Received: from c-71-197-208-131.hsd1.or.comcast.net ([71.197.208.131] helo=internaut.com) by mho-01-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from <aboba@internaut.com>) id 1IvZAA-000Cbg-BB; Fri, 23 Nov 2007 14:05:46 +0000
Received: by internaut.com (Postfix, from userid 1000) id 00EBB82BD6; Fri, 23 Nov 2007 06:05:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id E509282BD1; Fri, 23 Nov 2007 06:05:44 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 71.197.208.131
X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX187WK06KLEEb+3NCyGwx0+L
Date: Fri, 23 Nov 2007 06:05:44 -0800
From: Bernard Aboba <aboba@internaut.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <EB1F32B1-DB04-43E3-9DD9-00208427BCA9@muada.com>
Message-ID: <Pine.LNX.4.64.0711230544001.4649@internaut.com>
References: <Pine.LNX.4.64.0711220729540.28605@internaut.com> <Pine.LNX.4.64.0711220951440.29663@internaut.com> <EB1F32B1-DB04-43E3-9DD9-00208427BCA9@muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: shim6-wg <shim6@psg.com>, ietf@ietf.org
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
> Note that we explicitly say that this applies to local knowledge that an > address doesn't work, although then the issue is confused by mentioning > deprecation, which leaves the address involved still reachable. Yes. > The issue is also different from regular operation, because if I pull out my > ethernet cable when I'm not running shim6, the only two options are keeping > the session open until it times out or giving up immediately. The latter is > suboptimal because I could put the cable back in before the session times out. > But with shim6, it's possible to rehome the connection to a different > interface so it keeps running whether or not the cable is plugged in again. My concern is about wireless media which can experience large variations in signal/noise ratio, in the process generating transient "link down" indications. This could cause those connections to migrate to other media/interfaces. If the host has implemented the strong host model, then when the transient "link down" is resolved, the connection won't resume using the prior outbound interface. This could lead to applications experiencing sub-optimal conditions long-term based on a transient event. There are a few approaches that come to mind: a. Continue to make decisions based on timers, perhaps using the "link down" indication as a hint to lower the timer values (e.g. requiring only two retransmissions instead of three) 2. Suggest the weak host model to be used along with SHIM6, so that if the "link down" proves to be transient, the connection will migrate back to its former outgoing interface. > It would be possible to adjust the keepalive interval based on RTT estimates, > though. If the information is available, this might be the best approach. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- TSV-DIR Review of draft-ietf-shim6-protocol-09.txt Bernard Aboba
- Re: TSV-DIR Review of draft-ietf-shim6-protocol-0… Iljitsch van Beijnum
- Re: TSV-DIR Review of draft-ietf-shim6-protocol-0… Bernard Aboba
- Re: [tsv-dir] Re: TSV-DIR Review of draft-ietf-sh… Bernard_Aboba
- Re: TSV-DIR Review of draft-ietf-shim6-protocol-0… Bernard Aboba
- Re: TSV-DIR Review of draft-ietf-shim6-protocol-0… Iljitsch van Beijnum
- Re: TSV-DIR Review of draft-ietf-shim6-protocol-0… Bernard Aboba