[lwip-devel] [bug #27771] Silly-window-avoidance shrinks window unnecessarily

[Kieran Mansley]

Follow-up Comment #4, bug #27771 (project lwip):

Imagine that the 10 bytes was just the first 10 bytes of a longer transfer,
and that the sender has in fact got the other 502 possible bytes in flight. 
If we advertised the 10 bytes of new window after receiving it, the server
would then get an ACK that allows it to send 10 more bytes.  In reality it
might want to send much more, but would be limited by the window, and so send
just 10 bytes.  This would result in a situation where the network descended
to lots of small packets.  If instead we batch up the window updates and give
it a window updates of 1 MSS or more, the sender will always be able to send a
full segment (when it is able to send at all) and so will result in a
situation there the network sticks to MSS-sized frames: this is much more
efficient.

The critical thing here is not the total amount of window we're advertising
(as the receiver, we can't deduce the sender's state, and so can't know how
much window is really outstanding) it's the size of the increments to the
window that's important.

The downside is that it makes systems where WND = MSS behave a bit worse (the
window will decrease to zero before getting an update of 1 MSS) but (i) these
systems were never optimal; (ii) we can add a compile time warning; and (iii)
we can add a condition to the window update to also update if the increment is
> WND/2 as suggested by David Empson. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?27771>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/