TCP experts,
I have a couple of questions regarding the freeBsd receive window advertisement and updating sender side flow control state based on this.
1. 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.
3121 if ((thflags & TH_ACK) &&
3122 (SEQ_LT(tp->snd_wl1, th->th_seq) ||
3123 (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
3124 (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 not ack any additional data 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.
2. Can a receiver ever update its rcv window to be less than the previously updated value without really receiving that much data?
eg: Receiver advertises a window of 10K, Sender sends 6K instead of advertising 4K in the Ack can it advertise 2K may be because in that receiver implementation they have async receives which could be cancelled or any other way where the receive buffer shrinks?
Thanks
I have a couple of questions regarding the freeBsd receive window advertisement and updating sender side flow control state based on this.
1. 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.
3121 if ((thflags & TH_ACK) &&
3122 (SEQ_LT(tp->snd_wl1, th->th_seq) ||
3123 (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
3124 (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 not ack any additional data 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.
2. Can a receiver ever update its rcv window to be less than the previously updated value without really receiving that much data?
eg: Receiver advertises a window of 10K, Sender sends 6K instead of advertising 4K in the Ack can it advertise 2K may be because in that receiver implementation they have async receives which could be cancelled or any other way where the receive buffer shrinks?
Thanks