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

[Joe Touch <touch@ISI.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Iljitsch van Beijnum wrote:
| 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.

Agreed,

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

TCP connections are not closed just because they are idle, and idle
means no packets exchanged at all.

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

Anything that doesn't generate ACKs every couple-hundred ms when the
stream is active is asking for trouble ;-)

| Alternatively, this could be made to auto-tune.

Sure.

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

Yes.

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

I don't like ignoring corner cases, esp. where TCP is concerned.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBnPh6E5f5cImnZrsRAstRAJ9apCJHgtI8X4W9gpEPWkHYqJkZjgCg/ku6
NNLvA6qxNltFyt9sMYA2W54=
=ybHa
-----END PGP SIGNATURE-----