[e2e] tcp connection timeout

[Saikat Guha]

On Sat, 2006-03-04 at 11:37 -0500, Ethan Blanton wrote:
> there's no reason HTTP *couldn't* be implemented at the transport
> layer, or SMTP, or ssh, so clearly keepalives (or whatever feature)
> could be done at the transport layer -- it just wouldn't be a good
> idea to do so.

What makes it a "good idea" to implement something at the transport
level or application level? Clearly all of TCP itself could be app.
level, but I suspect the reason to put it in transport has more to do
with:

a) How complex a particular feature is
b) How many applications require it

Congestion control, reliability etc. are complex enough and widely used
enough to warrant their inclusion into the transport. HTTP, while
complex, isn't used nearly as widely and is kept out (although there are
calls for a bulk-transfer service in the transport layer by Dave
Andersen et al.)

The case for Keep-alives isn't clear. It is trivially simple. Long ago,
it was rarely used (connectivity mattered only when data needed to be
sent). Now with NATs and firewalls, establishing connectivity has a
significant overhead, idle time matters (both as state on middle-boxes,
and as the subsequent high-overhead connection setup later).

Yes, long ago, there was no reason to put keep-alives into the transport
layer because applications rarely used it. But with more applications
trying to evolve into the NAT/firewalled world, today the situation may
have changed.

cheers,
-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060304/bc4d826f/attachment.bin