Date: Thu, 9 Oct 2014 22:47:27 +0000 From: Madhusudhan Ravi <mravi@vmware.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: TCP receive window management Message-ID: <D05C5E8E.968D%mravi@vmware.com>
next in thread | raw e-mail | index | archive | help
I have a question regarding the freeBSD receive window advertisement and up=
dating sender side flow control state based on this.
Is it expected that a retransmitted packet not carry an updated receive win=
dow?
The following are the state variables used for maintaining a peer's rcv win=
dow state on the sender side. snd_wnd, snd_wl1, snd_wl2. In tcp_input at th=
e label step6: where these states are updated there are checks which make s=
ure rcv window is not updated by old segments.
if ((thflags & TH_ACK) &&
(SEQ_LT(tp->snd_wl1, th->th_seq) ||
(tp->snd_wl1 =3D=3D th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
(tp->snd_wl2 =3D=3D th->th_ack && tiwin > tp->snd_wnd))))) {
Based on the above checks for the case of a fast retransmitted packet that =
does ack additional data ((SEQ_LT(tp->snd_wl2, th->th_ack) is TRUE) and ha=
s the latest rcv window. th_seq could be < snd_wl1 and in this case rcv win=
dow is not updated to the latest one. Is this intentional or is there somet=
hing that I am missing.
Thanks
Madhu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D05C5E8E.968D%mravi>