[e2e] Is a non-TCP solution dead?

[Cannara]

Rick,

Take a Sniffer and watch what happens on a standard, Windows/NT client-server
interaction, like reading a 2MB file over a 100mS WAN path.  Why would odd pkt
counts not be expected?  How is the admin or user supposed to understand how
to change the default TCP settings in the stack it got from Sun, HP,
Microsoft, etc?  These are the questions real TCP engineering would have
addressed.  The intentional omission of an Ack for imagined optimization was
one of the sillier decisions made in later TCPs.

Now, add in a 0.4% loss on the path, which engages the backoff algorithms in
TCP incorrectly, and the "missing odd ack" problem becomes aggravated beyond
reason.  What an 'unreasonable' expectation of the NOS designer that even or
odd pkt requests should get equivalent support from the transport!  What an
'unrealistic' expectation that x% pkt loss on a path should not generate 30x
slowdown.

Ah, but we do love those famously-named algorithms, presented at international
fetes, and all those papers in publication.  {:o]

Alex

Rick Jones wrote:
> 
> Cannara wrote:
> > Some of the 'fixes' to TCP have been especially naive, like the "every
> > other pkt Ack" trick.  Imagine the delays additive in a large file
> > transfer when blocking (e.g., SMB) results in odd pkts.  How someone
> > could imagine saving every other Ack was worth, say, 150mS penalty
> > every 30kB, is unfathomable, unless they just never really thought out
> > the implications.  No one designing TCP/IP ever thought that
> > individuals would be going to chain stores and buying PCs to connect
> > to a global network, nor that these buyers should be taught parameter
> > optimization.  Indeed, the design choices mean consumers should be
> > enlightened!
> 
> Not meaning to address any perceived/actual naivete in a given fix, but
> I thought that the "ack every other segment" was not something that was
> meant to be implemented quite that literally, and that it was to
> fall-out of a "piggy-back and ACK on a window update" and have a window
> update be triggered by the application's consumption of >=2MSS worth of
> data.
> 
> I also can't say as I've ever seen an odd request size result in delayed
> ACK (what I presume you allude to with the 150 mS) delaying of the
> exchange rate - at least not on stacks that hadn't botched their
> implementation of the Nagle algorithm (or apps that hadn't presented the
> locically associated data to the transport at the same time).
> 
> rick jones