[e2e] TCP in outer space

[Alex Cannara]

Ted,

My remarks didn't and don't suggest: "the designers were ignorant of the
issues or incompetent".  Knowledge was available.  Decisions were made. 
No disrespect for the many, many people who worked and now work on
various aspects of the Internet suite of protocols is intended.  As many
of us know, Bob Kahn was the real hero of the Internet -- keeping things
going with DARPA, even when they were losing interest.

Given that, it remains true that some decisions came to haunt us all and
are still being addressed in surprisingly limited ways.  There are a
number of examples, whether in addressing or transport.  In essence,
some of the most significant issues now being addressed on security, QoS
and performance were very much available for intellectual and engineered
attack many years ago.  My fault finding is more with attitude than
intellect.

As far as what's ad hoc and what's not, we all know much of the Internet
indeed has been addressed in ad hoc fashion over the years.  Given the
number of people involved worldwide, the great resources made available
over the years, and the 'fixes' now being made, there's every reason to
suggest a more broadly evaluative approach than parroting things like
"Changes must be TCP-friendly", etc.  As an example, even in low RTT
environments (vastly easier than spacecomm), TCP has large performance
penalties for its users when loss is not purely congestive.  And, we
won't even bring up the IP addressing debacle, saved only by NAT boxes,
which themselves sacrifice network security for addressibility.

As far as design goals, one would be to eliminate the discussion title:
"TCP in Outer Space".  Unless it means leaving there to float while a
Space Transport Protocol is being designed -- some of which, of course,
have already been in use for years.

Alex


Ted Faber wrote:
> 
> 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.
> 
>