[Info-vax] Accuweather new contract

[johnwallace4 at yahoo.co.uk]

On Monday, 30 March 2015 17:47:52 UTC+1, JF Mezei  wrote:
> On 15-03-30 09:19, Bill Gunshannon wrote:
> 
> > That has always been the case with the TCP/IP spec.  I can't imagine
> > why any implementation would not have been taking advantage of this 
> > unless it was just plain broken.
> 
> A geeky friend said some time ago while testing newly introduced cable
> speeds that he could not achieve the 20mbps download with only 1mbps
> upload on Windows but could on Linux due to Windows sending acks for
> every packet. (those acks require more than 1mbps in upload).
> 
> Cable did impove advertised upload speeds with DOCSIS-3 to provide
> sufficient upload bandwidth to make use of higher download speeds.
> 
> Note that I have never really checked this myself.
> 
> While the specs for TCP have always said that an ACK conforms receipt of
> all bytes up to and including what the ACK is for (which means all
> packets before it that may nopt have been acked), it does not mean that
> stacks have been smart enough to monotor throughput and realise that
> they can ACK every second packet for instance.
> 
> Another aspect that varies from stack to stack is the TCP windowing.
> The specs dictate the sender abides by the window size set by recipient,
> and that when a packet has been declared unreceived, the widnow size is
> halved, but it gives the recipient plenty of flexibility to set the
> window size.

You might want to go read about Nagle's algorithm and its friend/enemy
the TCP Delayed Ack parameter (aka the option TCP_NODELAY or similar),
which have been available for a decade or (much?) more with most IP
stacks (including DEC/CPQ/HP's for VMS, and TCPware, and probably
MultiNet). 

There should be a few writeups around; the one at
http://www.stuartcheshire.org/papers/NagleDelayedAck/
even mentions Apple, and if you include VMS in your search string you
should find a few relevant references.

It all comes down to the usual tradeoff between responsiveness (aka
latency) vs throughput. In general, you can optimise for of the two,
but to get both frequently requires a miracle. This applies not just
to TCP networks.