Re: [tcpm] question about if a recent Linux patch is compliant with RFC7323 on window scaling

["Cui, Cheng" <[e-mail]>]

Six days have passed and no response yet. Can anyone in this board make a comment?

Thanks,
--Cheng Cui
NetApp Scale Out Networking


On 8/24/16, 5:06 PM, "Cui, Cheng" <[e-mail]> wrote:

    Hello David,
    
    I hope this email could reach you well, because I found related
    discussions about this topic on window scaling and the case of window
    shrinking (or retraction or loss of precision). And I try to make this
    question simple.
    
    There is a recent Linux patch at receiver side to round-up advertised
    window due to precision loss of window scaling. It reaches my attention
    because the same problem could also happen between a pair of Linux and
    FreeBSD nodes, and I am not aware of any similar patch in FreeBSD yet.
    
    The Linux patch is this:
    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6
    07bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723
    
    And I quote some description of the Linux patch below:
    > If the sender uses up the entire window before it is shrunk, this can
    >have
    > chaotic effects on the connection. When sending ACKs,
    >tcp_acceptable_seq()
    > will notice that the window has been shrunk since tcp_wnd_end() is before
    > tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number.
    > This will fail the receivers checks in tcp_sequence() however since it
    > is before it's tp->rcv_wup, making it respond with a dupack.
    
    
    If the Linux sender?s behavior is right ("ACK-only packets should be sent
    with the largest in-window sequence number that has ever been sent." ref:
    https://www.ietf.org/mail-archive/web/tcpm/current/msg10512.html) it
    actually chooses "tp->snd_una+tp->snd_wnd" (tcp_wnd_end()) instead of
    tp->snd_nxt, as it thought tp->snd_nxt is out of window, in case of
    precision loss which made the receiver?s advertise-window smaller.
    However, the RFC7323 explicitly specifies the receiver should right shift
    the exact scale factor, without mentioning any further round-up:
    
    https://tools.ietf.org/html/rfc7323#page-9
    >    o  The window field (SEG.WND) of every outgoing segment, with the
    >       exception of <SYN> segments, MUST be right-shifted by
    >       Rcv.Wind.Shift bits:
    > 
    >                     SEG.WND = RCV.WND >> Rcv.Wind.Shift
    
    And also if I am understanding correctly, RFC7323 page 10 (2.4. Addressing
    Window Retraction) specifies it is the sender?s responsibility to handle
    the sequence number out of window:
    https://tools.ietf.org/html/rfc7323#page-10
    >    4)  On first retransmission, or if the sequence number is out of
    >        window by less than 2^Rcv.Wind.Shift, then do normal
    >        retransmission(s) without regard to the receiver window as long
    >        as the original segment was in window when it was sent.
    > 
    >    5)  Subsequent retransmissions MAY only be sent if they are within
    >        the window announced by the most recent <ACK>.
    
    In your discussion of the link below, if I am understanding correctly, you
    were also in favor of "Yes. It is ok to have more receive buffer space
    available than you advertise in the window, but not ok to advertise a
    larger window than you are willing to accept." So I think you were not in
    favor of rounding-up the advertise-window.
    
    https://www.ietf.org/mail-archive/web/tsvwg/current/msg06475.html
    
    
    So my question is: Is the Linux patch (on receiver side to round-up the
    advertise-window) RFC compliant? Or is it just the right thing (vendor
    specific) and other systems like FreeBSD have to follow up, so that their
    talks can have no problem?
    
    Thanks and apologize in advance if I did not do enough research,
    --Cheng Cui