[e2e] Is a non-TCP solution dead?

[Mark Allman]

Alex-

I have now caught up on this entire thread.  It was painful.  

I do not understand what sort of magic bullet you're looking for.
You claim that TCP performance is poor.  But, it *has* been
improved.  And, then you turn around and say that the improvements
are only in RFCs and not in the real world and so cite results from
TCPs that do not support the improvements (like fast retransmit!).
Use the new stuff that has been developed!  If you don't then why
are you complaining?  If you do and they do not fix the problem then
write it all down and show everyone where the problems still are.

> 1) Well, we know its max can be set wrong by default -- NT was
> shipped with a 6-pkt window limit.  Microsoft upped that a bit a
> while later.  The user, however, did not have access to the
> adjustment.  So, talk about RFCs is often irrelevant.

If talk about RFCs is irrenlevant than so is talk of "protocol
problems".  If the host operating system (from MS or whoever) is
using a small window then performance may be sub-optimal.  And, it
may happen for a number of reasons (can't fill the pipe, loss
recovery is brittle, delayed ACK packet counts, etc.).  But, this is
not a problem with TCP.  This is a problem with the implementation
of TCP.  That is, you could change the implementation in ways that
do not change the algorithms or the protocol specs and achieve
better performance.  (I've done it.)

> 2) A lost pkt will put the receiver into triple Acking,
> eventually, to try to replace it, if the receiver is of that
> vintage.  If the sender doesn't understand that, as this NT TCP
> apparently did not, or if one repeated Ack is lost, then the
> sender goes into long timeout, perhaps back to slow start.  

Again, we know better, but cannot force all implementations to know
better.  If you use a larger window or limited transmit your
performance will increase.

> Add in Alok's RFC quote: "Many TCP's acknowledge only every Kth
> segment out of a group of segments arriving within a short time
> interval;..." and you can see that very long delays can occur when
> an Ack is lost.  One question we can legitimately ask today is:
> Why worry about delaying Acks?  Ack every segment received.  This
> would also allow new feedback info to be included with an Ack, as
> discussed in the archives, and so let the sender know some useful
> things more quickly.

Or, to flip this around.... when things are running smoothly, why
waste the network resources to send an ACK for every segment?  I am
certainly an advocate of getting new information to senders as
quickly as possible.  For instance, note that RFC2581 says packets
that arrive out-of-order should be ACKed immediately (to help out
with loss recovery).  That seems fine to me.  But, with enough of a
window delayed ACKs do not hurt much at all during steady-state TCP.

(And, I don't think anyone has noted that delayed ACKs do hurt in
growing the cwnd -- which happens on a per-ACK basis rather than on
a per-ACKed-byte basis.  RFC3465 is a start at correcting this.)

Note that I am not claiming that TCP does not have problems or even
that CC belongs in the transport in some ideal networking stack.
TCP definately has its problems.  And, one can make the case for CC
being in the network layer (or transport or application).  But, I'd
like to see a coherent argument made on the topic rather than bits
and pieces of assertion based on sketchy NDA encumbered data in
email to a mailing list.  And, further, I'd like to see results that
show these problems that you have found.  If they're as easy to show
as you say then forget the pile of NDA data and generate some new
unencumbered data -- it should be easy, right?  We all love to see
reports like that.  As Jonathan noted, there are plenty of people
who would add energy to solving the problems.  But, until these
problems can be nailed down and shown concretely to the community we
don't have much of a chance at solving them based on what Dave
correctly identified as an extended rant.  If sure would be nice
(since you have all of these "problems" in your pocket) if you were
part of the solution.

allman


--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/