[e2e] Is a non-TCP solution dead?

[Cannara]

Michael, as pointed out by Spencer, an engineered approach to anything should
"Begin with the end in mind" to be successful.  TCP's mythical "control loop",
is just that, mythical.  A feedback control system is no better than, and
usually worse than, its inputs.  If our cars' cruise controls don't have a
good idea of wheel speed (better still, car speed), then we can get in lots of
trouble.  This is why the speed sensor is behind the transmission and not in
front of it (not just because of gearing changes, but because, if automatic,
the torque convertor slips.

So, TCP was modified to reduce end-sourced flows when an input to the source
end was observed.  What inputs were available?  Not much of reliability in
terms of true path congestion.  Yet, the panic in the '80s on Internet
collapse led some to make decisions to change TCP in spite of the clear and
present lack of proper congestion-feedback info.  This is not a "control
loop".  This is not engineering with the end in mind of a good transport, but
simply with the end in mind of avoiding embarrassment and things like
Metcalfe's prediction being right at a lower layer.

So, my sole purpose in the discussion that is described in the title of all
these emails is simply to encourage younger/newer folks, not enmeshed in the
Internet/IETF bureaucracy, to think on what really needs doing to move from
the current Internet to something more engineered and less simply an existence
proof.  I don't see a disconnect as much as an odd willingness in some to view
what we have in TCP/IP today as bigger than life, as more than an existence
proof, as anointed in some way.  This despite the fact that it was never
subject to competitive design and use, yet subsidized in design and delivery. 
Anything of such ilk presented to an engineer is normally examined with a
critical eye.  Somehow, perhaps because it's good academic business, we
mislead our new networking students unnecessarily, and inappropriately, into
thinking that there are no real alternatives.

There are, fortunately, some studying the future needs of "an Internet" and
examining alternatives that range from more communication from Network to
Transport layers to more direct network congestion management by the Network
Layer all along a path.  Of course, transport or datagram packet access to an
internetwork, whose links may or may not be reliable, remains the goal.

So what are the ways the goal can be approached?  Someone could do a thesis on
"My TCP" and do what can be done to improve its algorithms and inputs -- some
of these suggestions are a few years old at least, and in the archives for
this list.  Some folks have been working this approach.  One could, for
instance, simply identify, in every Ack, which received packet the Ack is for
-- not by seq #, but by IP ID.  There's actually room in the TCP header to do
this and it would prevent the sender from being tricked into thinking a
previous retransmission was actually necessary.  Dumping the Delayed Ack trick
would also be good.  These may seem minor effects, but there are quite a
number of ways TCP gets fooled in real traffic and removing even a few issues
reaps tangible benefit.  Of course, in the wisdom of the IPv6 folks, the IP ID
is gone -- sigh!  But there is real motivation:  a friend just showed me an
analysis of an ISP's DSL service supporting a major system-management
company's web tool.  The ISP's oversubscription resulted in about 1% pkt loss
to one subscriber, which TCP happily translated into a 50% throughput cut for
that subscriber -- not now a happy fan of TCP's 'control loop'.

Other researchers might simply define a new transport on, say UDP, and even
allow IP nodes along a path to comment on the transport's demands, thus giving
UDP, and anything on it, a better idea of how to modulate a source flow.  Some
of this work has already been started.  The need here is more clear, since TCP
traffic is not the dominant future.

However, no matter what is done, we have to do better in distribution than has
been done with TCP/IP and all in its family.  There's no "end in mind" that
can be engineered without strict source control.  This list and others contain
discussions of installed protocol versions not working together well. The
Internet was never designed to be anything but an open, researchy kind of
environment, which is why we're now spending billions on trying to make it
secure, even in ways non-Internet corporate nets were secure many years ago.
Before any engineered solutions to "TCP problems", or the many other Internet
protocol issues, can be rightly implemented, the existence of competent
version and source control must be in place.

Alex

Spencer Dawkins wrote:
> 
> Just a minor clarification to Michael's summary, and a thought:
> 
> --- Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> > Dear Alex,
> >
> [deleted down to]
> >
> > Use mechanisms like source quench -> usually doesn't scale
> > maybe explicit corruption notification ... well, this is being
> > discussed occasionally ... see the trigtran effort, for
> > instance -
> 
> In my active fantasy life, I dream that explicit corruption
> notification is ready for engineering, but the TRIGTRAN charter
> we submitted to Allison is a lot more constrained than this.
> 
> On the other hand, if we thought explicit corruption
> notification was closer to engineering, we'd be thrilled.
> 
> >
> > Quite a statement. Which general-purpose solution do you
> > propose?
> 
> My suggestion is a Stephen Covey "Begin with the end in mind" -
> I'm not sure we have a well-defined general-purpose problem
> statement. If I grokked the chat so far, I'm hearing some people
> working on this problem:
> 
> "Can we build a transport protocol that outperforms TCP in some
> environments?" (implicit answer = "almost certainly"),
> 
> while others are working on this problem:
> 
> "Can we improve TCP's performance in all environments?"
> (implicit answer="maybe a little").
> 
> I'm not saying this is the only reason for a discussion
> disconnect, but it would be enough of a reason by itself.
> 
> Spencer