question about if a recent Linux patch on window scaling is required in FreeBSD

[Cui, Cheng]

Refresh this question. Can anyone make a comment?

Thanks,
--Cheng Cui
NetApp Scale Out Networking


On 8/25/16, 3:52 PM, "Cui, Cheng" <Cheng.Cui at netapp.com> wrote:

    Hello everyone,
    
    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.
    
    I think the Linux'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. But at
    the 
    other side, if the other side is FreeBSD, I think FreeBSD will also fail
    the 
    check since "tp->snd_una+tp->snd_wnd" is before it's tp->rcv_nxt, and
    ignore 
    the sequence number in the packet.
    
    I also sent an email to tcpm at ietf.org asking if this Linux patch is RFC
    7323 
    (window scaling part) compliant, but I have not get any reply yet.
    
    So my question here is: Is there any recent change in FreeBSD to
    accommodate the 
    Linux behavior ("tp->snd_una+tp->snd_wnd" as sequence number)? If not, do
    we 
    consider to apply the same way as in the Linux patch?
    
    Thanks and apologize in advance if I did not do enough research,
    --Cheng Cui