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

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?