[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!