Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

From: Geoff Huston <[email-masked]>
Date: Sun, 25 Nov 2007 19:42:58 +1100

Fowarded....

 From [email-masked] Fri Nov 23 14:05:57 2007
Date: Fri, 23 Nov 2007 06:05:44 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>, [email-masked]
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 Nov 2007 11:20:21 +0100

> Fowarded....

Please note that the various reviews and last calls are currently  
generating shim6-related discussions on the IETF discussion list,  
which aren't all copied to the draft authors or the shim6 list.