Re: Comments on draft-ietf-multi6-v4-multihoming-02

On 14-nov-04, at 4:29, Joe Touch wrote:

>> But how do you know a session is completely idle vs there is still a 
>> delayed ack coming? (Without looking too deep into TCP, that is.)

> Delayed ACKs come within 200ms of the other end going idle, AFAIR.

Ok. But then we have to account for normal packet loss and normal RTT 
variations.

>> (Note that is makes little difference whether you use persistent 
>> connections: we work at the IP layer.)

> Persistent connections are the kind of TCP connections that might go 
> idle for extended periods;

Actually I believe they are closed after a relatively short time when 
they aren't used. And very few sessions use persistent connections last 
time I checked.

> most other TCP connections tend to either be sending data or be closed 
> quickly.

A better example of sessions that remain open long even if they're idle 
are SSH sessions.

>> The trick is detecting legitimate idleness because in that state no 
>> action is necessary. For TCP this shouldn't be too hard, for other 
>> protocols we have to find good timeout values. I think these need to 
>> be higher than just a few RTTs.

> Such as? I was thinking 300ms-500ms as a ballpark.

I was thinking along the lines of 10 - 15 seconds for non-TCP stuff. I 
heaven't really looked in detail, but I'm pretty sure transports for AV 
streaming don't generate ACKs every 500 ms.

Alternatively, this could be made to auto-tune.

Note though that if you select value X for this and ACKs are sent every 
1.1*X interval, you'll be sending test packets every X. With a larger X 
this is less likely to happen, but also results in less unnecessary 
traffic if it does.

>> Hm, my assumption was that after a successful test, there wouldn't be 
>> any more tests until something changes.

> That presumes async notification from the lower layer. I wasn't, since 
> I don't believe that's feasible.

> I.e., I would expect:
> 	- seeing packets exchanged is an in-band test that can be
> 	  observed and serves as a keep-alive itself
> 	- send keepalives for the first 500ms after idle
> 	- stop sending keepalives after that

I think we're in agreement exept for the interval and the fact that you 
use plural while I'd think a single successful exchange would be 
enough.  :-)

>> Since we don't do anything when the session is active in both 
>> directions or completely idle, reachability tests only happen after a 
>> suspicious active->idle transition. After the test, the multihoming 
>> layer would be satisfied that this transition wasn't because of a 
>> failure, and wouldn't have to do anything until there is a new 
>> active->idle transition.

> I'd like it to do something - to keep verifying that reachability is 
> still possible for exactly the period that an idle TCP 'expects' there 
> not to be a substantial change in the channel.

Wouldn't an outage happening right after a session goes idle and a 
keepalive has been exchanged be such a corner case that we can safely 
ignore it as a special case?