[ih] lack of service guarantees in the internet meaning that it cannot ever "fail"

[Ted Faber]

On Tue, Oct 27, 2009 at 07:12:38AM -0700, Dave CROCKER wrote:
> Timeouts for TCP are implementation artifacts, not protocol features.

To a first approximation and in context, I agree with you.

It's worth noting that the TCP specification (I'm speaking of the RFC793
interface, not the myriad socket interfaces, because I hope the standard
more clearly refelects the protocol design) does allow a user to set an
optional timeout on each data buffer passed to TCP for transmission.  It
seems clear that the protocol was designed to allow developers access to
the TCP timeout and retransmission information in this limited way when
it was helpful to them in implementing their application.  The base
protocol has few extraneous knobs, so I assume this was carefully
thought out.

I agree completely with your implication that TCP designers went out of
their way to avoid requirements that implementations must break
connections after a certain time had passed unless specifically
requested to do so by a user.

Robustness seems to be more important than service guarantees, though
they were not neglected.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20091027/9283eb78/attachment.sig>