[lwip-devel] [task #14128] Appropriate bye counting/stretch ACK support

[Joel Cunningham]

URL:
  <http://savannah.nongnu.org/task/?14128>

                 Summary: Appropriate bye counting/stretch ACK support
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: jcunningham
            Submitted on: Mon 22 Aug 2016 04:15:28 PM GMT
                Category: TCP
         Should Start On: Mon 22 Aug 2016 12:00:00 AM GMT
   Should be Finished on: Mon 22 Aug 2016 12:00:00 AM GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: jcunningham
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
                  Effort: 0.00

    _______________________________________________________

Details:

LwIP currently doesn't implement appropriate byte counting when making
adjustments to the congestion window during slow start.  RFC 3465
<https://tools.ietf.org/html/rfc3465> outlines both security and performance
issues with the initial slow start implementation

I've run into the performance issue when LwIP sends data to clients that use
stretch ACKs.  Typically ACK stretching is used with delayed ACKs, which only
send 1 ACK per 2 MSS packets, but I've seen empirically both Windows 7 and OS
X stretch large number of ACKs (OS X stretched 11 ACKs in one test).

LwIP's slow start implementation increments the congestion window by pcb->mss
regardless of how much was actually ACKed.  When stretch ACKs are used the
congestion window will grow much slower during slow start.

LwIP is also vulnerable to what the RFC calls "ACK Division":


This scheme involves the receiver sending multiple ACKs
for each incoming data segment, each ACKing only a small portion of
the original TCP data segment.  Since TCP senders have traditionally
used ACK counting to increase cwnd, ACK division causes
inappropriately rapid cwnd growth and, in turn, a potentially
inappropriate sending rate.





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?14128>

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