[e2e] TCP in outer space

Ted Faber faber at ISI.EDU
Thu Apr 12 14:57:37 PDT 2001


On Thu, Apr 12, 2001 at 10:35:40AM -0700, Alex Cannara wrote:
> Bob,
> 
> My comment is simply intended to reflect the plain fact that since 1978,
> there has been no mystery that, for instance, TCP's retransmission
> algorithm has been given no means to distinguish among even the two most
> important causes of loss -- physical or queue drop.  

True enough, but not only is there no mystery that the designers of
TCP/IP made that decision, but there is no mystery why.  Mechanisms
based on internal network state were considered and discarded because
they conflicted with the well-defined and well-prioritized list of
design goals for the nascent Internet.  Specifically, depending on
such internal information made the net less robust to gateway failures
and prevented the architecture from embracing a wide variety of
networks.  Both of those goals were considered more important than
performance or cost effectiveness, so such mechanisms weren't
included.

In case you think I'm making this up, it's made abundantly clear in
Dave Clark's 1988 "The Design Philosophy of the DARPA Internet
Protocols" published in SIGCOMM 1988.

This informed design decision hardly merits charges the designers were
ignorant of the issues or incompetent designers.  Such a structured
list of goals and published discussion of the trade-offs also argues
against rampant ad hockery.  They simply designed for different
requirements than the ones you wish they had.

> 
> I'll repeat the point:  nothing in 2001 is new with respect to Internet
> design criteria, that was not evident to network engineers in and out of
> the Internet community over a decade ago, yet the discussions of what to
> do play the same old tunes.  If the old tunes were spur-of-the-moment
> (ad hoc), as we know some significant ones were, then why be so
> resistant to new ideas for a new networking realm?  Bureaucracies are
> resistant.  Productive, competent research cannot be.

Redefining the problem leads to different design choices.  I think in
terms of the criteria stated by Clark in the above paper most of the
design decisions remain sound.  I also think that the design goals are
useful.

If you'd like to change those goals, I'm all ears.  Convince me the
priority is wrong or that a new goal needs to be on the list.  Then
we'll talk mechanism.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20010412/3670392a/attachment.bin


More information about the end2end-interest mailing list