Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 1 Sep 2016 18:37:21 +0000
From:      "Cui, Cheng" <Cheng.Cui@netapp.com>
To:        "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: question about if a recent Linux patch on window scaling is required in FreeBSD
Message-ID:  <2FE246D5-C2F4-4D67-963F-3B7A083CE4BD@netapp.com>
In-Reply-To: <27FDDABD-4726-41B1-8A49-FF3274F9AAD3@netapp.com>
References:  <D3E4C4C9.147A0%Cheng.Cui@netapp.com> <27FDDABD-4726-41B1-8A49-FF3274F9AAD3@netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help 
Add freebsd-net to increase the size of audience.=20

Thanks,
--Cheng Cui
NetApp Scale Out Networking


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

    Refresh this question. Can anyone make a comment?
   =20
    Thanks,
    --Cheng Cui
    NetApp Scale Out Networking
   =20
   =20
    On 8/25/16, 3:52 PM, "Cui, Cheng" <Cheng.Cui@netapp.com> wrote:
   =20
        Hello everyone,
       =20
        I hope this email could reach you well, because I found related
        discussions about this topic on window scaling and the case of wind=
ow
        shrinking (or retraction or loss of precision). And I try to make t=
his
        question simple.
       =20
        There is a recent Linux patch at receiver side to round-up advertis=
ed
        window due to precision loss of window scaling. It reaches my atten=
tion
        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 y=
et.
       =20
        The Linux patch is this:
        http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm=
it/?id=3D6
        07bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723
       =20
        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_wn=
d_end()
        >as=20
        > sequence number. This will fail the receivers checks in tcp_seque=
nce()
        >however=20
        > since it is before it's tp->rcv_wup, making it respond with a dup=
ack.
       =20
        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=20
        other side, if the other side is FreeBSD, I think FreeBSD will also=
 fail
        the=20
        check since "tp->snd_una+tp->snd_wnd" is before it's tp->rcv_nxt, a=
nd
        ignore=20
        the sequence number in the packet.
       =20
        I also sent an email to tcpm@ietf.org asking if this Linux patch is=
 RFC
        7323=20
        (window scaling part) compliant, but I have not get any reply yet.
       =20
        So my question here is: Is there any recent change in FreeBSD to
        accommodate the=20
        Linux behavior ("tp->snd_una+tp->snd_wnd" as sequence number)? If n=
ot, do
        we=20
        consider to apply the same way as in the Linux patch?
       =20
        Thanks and apologize in advance if I did not do enough research,
        --Cheng Cui
       =20
       =20
       =20
       =20
   =20
   =20
   =20
   =20

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FE246D5-C2F4-4D67-963F-3B7A083CE4BD>