Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 28 Apr 2004 16:42:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, April 28, 2004 3:50 PM
> To: [email-masked]; Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [tcpm] WG consensus sought (deadline 5 May): 
> abort timeout negotiation
> 
> 
> While I am still to form an opinion on this, I would like to know in
> what cases such connection aborts take place. From my understanding,
> host mobility almost always gets completed within 8 round 
> trips (in the
> wired network) at the very worst (please correct me if I am wrong) and
> it should not typically take more than 10-20 seconds to completely
> establish a new working route within this time period.
> 
> The only case where such aborts can take place is when a user 
> moves into
> a poor wireless coverage area (e.g., a tunnel) during an 
> active session
> and comes out after a few minutes. 

It seems to me that it would be difficult to establish reliable 
bounds on the time that a mobility or link fade event is completed.  
Everyone's mileage may vary.

The various desktop OSes will typically retransmit 10-15 times 
before aborting a connection.  This leads to aborts in some cases 
within two minutes of outage.  

> But in these cases, I am not clear
> what is the algorithm to select the timeout value. If poor 
> coverage area
> is the only case, then it might be better to let the application solve
> the problem rather than using a TCP option. Some applications/servers
> might not want to keep the connection hanging beyond certain delay
> anyway.
> 

I think that we should separate mechanism from policy in this 
discussion.  To me, this is analogous to window scale, from an
application perspective.  TCP provides a mechanism whereby, if
applications do a setsockopt() for more buffer space, more 
window scale is negotiated.  But 1323 doesn't address how an 
implementation selects its maximum buffer size.  Likewise, it 
may be that applications or hosts want a more persistent TCP 
connection if possible.  The converse may also be true--
an application may not want to sit around in a lengthy backed 
off state, not able to transfer data even though connectivity
was restored (this was discussed in the link-up notification 
debate).  The peer server can make its own decisions on the 
value that it is willing to support.

Tom 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Thu, 29 Apr 2004 08:41:18 +0200

> value that it is willing to support.

Exactly. Section 2.2 discusses some aspects of using ATOs of various 
lengths. I should probably preface it with the rationale for not 
restricting ATO values, which is pretty much what Tom outlined above. 
This is trying to be a general mechanism and the ID discusses some 
potential uses. It does not try to restrict the applicability of the 
option to only those uses by introducing limits.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories