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

From: [email-masked]
Date: Wed, 28 Apr 2004 17:50:10 -0500

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

Yogesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Lars Eggert
> Sent: Wednesday, April 28, 2004 2:16 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [tcpm] WG consensus sought (deadline 5 May): 
> abort timeout
> negotiation
> 
> 
> Henderson, Thomas R wrote:
> >>The short form is that
> >>mobile or intermittently connected hosts may want to request that
> >>endpoints wait a long time before tearing down an idle TCP 
> connection,
> >>and that there's currently no way to do that.
> > 
> > It is not an idle connection that is the problem-- it is a 
> connection
> > with outstanding data.
> 
> Or when keepalives are used, esp. with servers that use more 
> aggressive 
> keepalives than the default 2 hours. (But in a sense, that 
> falls under 
> "outstanding data.")
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 28 Apr 2004 22:15:40 -0400

> 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

I think this is not for active mobility sorts of cases --- which, I
agree, generally survive such transients.

But, think of this scenario .... I use my laptop on my office network
and have a bunch of connections up and running (say long-lived ssh
connections .... which I usually have a few of).  Now, I take my laptop
off the network all together for whatever reason (say, because I throw
it in my backpack to go to a meeting or whatever).  I don't put the
laptop on the network until I return to my office.  When I plug back in,
it might be nice to have my connections still alive and kicking (say,
after a bit of a transient startup).

Lars- is that a plausible scenario that you intend to cover?

So, the question Ted is asking - just to re-play - is whether this is a
worthy goal for TCP and whether this WG should tackle some scheme for
doing it (not necessarily precisely what is in Lars' ATO i-d).

Thanks!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

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

> Lars- is that a plausible scenario that you intend to cover?

Exactly.

We actually also play with a slightly different scenario, where the TCP 
session runs over HIP. This lets you plug in anywhere - your connections 
are bound to the host identities and thus survive the address changes at 
the new location. The issue then is that by the time you plug back in, 
the retransmission abort timer has on the peers may have fired and the 
connections have been reset.

-- 
Lars Eggert                                     NEC Network Laboratories