[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-van-beijnum-shim6-reach-detect-00.txt

On 4-jul-2006, at 8:45, Brian E Carpenter wrote:


1. The base timing unit for this mechanism is named ShimKeepT.
   Until a negotiation mechanism to negotiate different values for
   ShimKeepT becomes available, a value of 10 seconds MUST be
   used.

Having just seen claims that IPv6 will increase battery lifetime  
because

it avoids NAT keepalives, this "until" bothers me a bit.

Is it essential that the two ends agree on the value of ShimKeepT?

Yes, because the receiver must time out when it doesn't see traffic  
for that period of time, so if the sender uses a larger value the  
receiver will time out when it shouldn't.

It is of course not that hard to add an option to the context  
establishment mechanism to convey the keepalive period used.

Couldn't we devise an algorithm for progressively increasing it, or  
for
tuning it according to the rate of data packets? Presumably a  
session that

generates one packet every five minutes would not be damaged by a much
larger ShimKeepT.

Nothing is impossible, but this would be quite difficult, as there  
could be missed messages and so on.

But don't forget that keepalives are only sent when one side sends  
data but the other side doesn't send anything. So in case where there  
is traffic in both directions and also in the case where the session  
is idle, no keepalives are sent. If we build in special case handling  
of TCP ACKs, TCP communication will NEVER generate keepalives if  
there is no packet loss, and if we don't, only when the session moves  
from active to idle.

So I don't think this is a huge issue.


Also note that increasing the timeout value means that detecting  
failures will take more time.

(All of this is the same in draft-ietf-shim6-failure-detection.)


When a host suspects that there is a failure for a context, it  
gathers
the set of possible source addresses and the set of possible  
destination

addresses.

"Suspect" can't form part of an algorithm. Can you define what this  
means
algorithmically? Does it mean "When full reachability exploration  
is started"?

:-)  Ok...


A host suspects that there is a failure when it has sent traffic and  
not seen any return traffic (regular traffic or keepalives) for  
ShimKeepT seconds plus 2 - 5 seconds.

Note it's unlikely that this document will continue to exist, after  
last week's discussion I'm going to take parts of it and incorporate  
them into the failure detection draft, and maybe other parts will  
find their way into the locator selection draft. The discussion about  
reusing the protocol for more than one client protocol that needs  
reachability detection is now obsolete because I've come to the  
conclusion that this isn't worth the trouble.

But thanks for reviewing!