Add freebsd-net to increase the size of audience. Thanks, --Cheng Cui NetApp Scale Out Networking
On 8/30/16, 10:19 AM, "Cui, Cheng" <cheng....@netapp.com> wrote: 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....@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 t...@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 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"