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

Cui, Cheng Cheng.Cui at
Thu Sep 1 18:37:45 UTC 2016

Add freebsd-net to increase the size of audience. 

--Cheng Cui
NetApp Scale Out Networking

On 8/30/16, 10:19 AM, "Cui, Cheng" <Cheng.Cui at> wrote:

    Refresh this question. Can anyone make a comment?
    --Cheng Cui
    NetApp Scale Out Networking
    On 8/25/16, 3:52 PM, "Cui, Cheng" <Cheng.Cui at> 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:
        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()
        > sequence number. This will fail the receivers checks in tcp_sequence()
        > 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:, 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
        other side, if the other side is FreeBSD, I think FreeBSD will also fail
        check since "tp->snd_una+tp->snd_wnd" is before it's tp->rcv_nxt, and
        the sequence number in the packet.
        I also sent an email to tcpm at asking if this Linux patch is RFC
        (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
        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

More information about the freebsd-transport mailing list