I have a question regarding the freeBSD receive window advertisement and
updating sender side flow control state based on this.
Is it expected that a retransmitted packet not carry an updated receive window?
The following are the state variables used for maintaining a peer's rcv window
state on the sender side. snd_wnd, snd_wl1, snd_wl2. In tcp_input at the label
step6: where these states are updated there are checks which make sure rcv
window is not updated by old segments.
if ((thflags & TH_ACK) &&
(SEQ_LT(tp->snd_wl1, th->th_seq) ||
(tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
(tp->snd_wl2 == 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 has the
latest rcv window. th_seq could be < snd_wl1 and in this case rcv window is not
updated to the latest one. Is this intentional or is there something that I am
missing.
Thanks
Madhu
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
