[lwip-devel] [bug #20199] TCP appears to be "Shrinking the Window"

[Tom Evans]

URL:
  <http://savannah.nongnu.org/bugs/?20199>

                 Summary: TCP appears to be "Shrinking the Window"
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: tom_evans
            Submitted on: Monday 06/18/2007 at 05:03
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

This report is from code inspection. It may be wrong. I have not been able to
demonstrate this condition as I don't have a running test harness for TCP
(yet). I raised this issue in:

http://lists.nongnu.org/archive/html/lwip-users/2007-06/msg00089.html and
Kieran Mansley replied "Could you file a bug report on savannah?". So this is
it.

The "silly window avoidance" code in tcp_output_segment() is as follows:

  /* silly window avoidance */
  if (pcb->rcv_wnd < pcb->mss) {
    seg->tcphdr->wnd = 0;
  } else {
    /* advertise our receive window size in this TCP segment */
    seg->tcphdr->wnd = htons(pcb->rcv_wnd);
  }

Assume data is arriving in small chunks and is not being
removed, so the window is getting smaller. Now when (pcb->rcv_wnd <
pcb->mss), all of a sudden the window advertised in the transmitted packet
(in seg->tcphdr->wnd) looks like it slams shut to zero.

This is mentioned in section "Managing the Window" on Page 42 of the TCP
RFC:

    ftp://ftp.rfc-editor.org/in-notes/rfc793.txt

    The mechanisms provided allow a TCP to advertise a
    large window and to subsequently advertise a much
    smaller window without having accepted that much
    data.  This, so called "shrinking the window,"
    is strongly discouraged.

"Requirements for Internet Hosts -- Communication Layers", on Page 91:

    ftp://ftp.rfc-editor.org/in-notes/rfc1122.txt

    4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41

       A TCP receiver SHOULD NOT shrink the window,
       i.e., move the right window edge to the left.

"SWS Avoidance" (the recommended way to do it) is documented in the following
section:

    4.2.3.3  When to Send a Window Update" of RFC1122.

       A TCP MUST include a SWS avoidance algorithm
       in the receiver [TCP:5].

       IMPLEMENTATION:
       The receiver's SWS avoidance algorithm determines
       when the right window edge may be advanced; this
       is customarily known as "updating the window".
       ...
       The suggested SWS avoidance algorithm for the receiver
       is to keep RCV.NXT+RCV.WND fixed until the reduction
       satisfies:

         RCV.BUFF - RCV.USER - RCV.WND  >=
                    min( Fr * RCV.BUFF, Eff.snd.MSS )

       where Fr is a fraction whose recommended value is 1/2,
       and Eff.snd.MSS is the effective send MSS for the
       connection (see Section 4.2.2.6).  When the inequality
       is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.

In summary, the window should only shrink "naturally" (because of incoming
data). SWS Avoidance delays the window OPENING until it can be opened EITHER
to the MSS or to half of the receive buffer size.

As a separate item, the lwIP code is only performing the former comparison,
and not the latter. If it did both it would also be immune to a
misconfiguration where accidentally setting (TCP_WND < TCP_MSS) would lock it
up.

The code (by inspection) doesn't calculate pcb->rcv_wnd from the sequence
numbers, but only runs it up and down (between zero and TCP_WND) based on
data arrival and removal. It looks like it might need a copy of pcb->rcv_wnd
that is the "advertised window" and which "lags behind" the "true window",
following RFC1122.







    _______________________________________________________

Reply to this item at:

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

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