On 12-nov-04, at 16:17, Joe Touch wrote:
Hm, wouldn't just one or two RTTs be a bit short? You may still get a delayed ACK after 2 RTTs.
The delayed ACK should itself refresh things; I'm thinking of an otherwise completely idle interaction.
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.
The key here is that TCP expects things not to change for a few RTTs (pick a number). Designing things so that is not the case is likely to cause unintended impact on TCP, esp. in some very typical cases (web surfing over persistent connections).
(Note that is makes little difference whether you use persistent connections: we work at the IP layer.)
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'm suggesting that the above be tempered after a few RTTs. I.e., if the only traffic has been the reachability tests for more than X RTTs (pick X), then it might be OK to stop testing.
Hm, my assumption was that after a successful test, there wouldn't be any more tests until something changes.
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
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.
Attachment:
signature.asc
Description: OpenPGP digital signature