[Info-vax] Accuweather new contract

[johnwallace4 at yahoo.co.uk]

On Monday, 30 March 2015 18:40:06 UTC+1, johnwa... at yahoo.co.uk  wrote:
> 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.

Editing error: try "the TCP options NO_DELAY and NO_DELACK (or similar)"
(instead of just NO_DELAY).