On 09/03/15 at 10:53P, hiren panchasara wrote: > On 09/03/15 at 09:16P, hiren panchasara wrote: > > On 09/03/15 at 09:13P, Lawrence Stewart wrote: > [skip] > > > > > > You want to read up about window inflation during fast recovery in RFC > > > 5681 followed by 3782, and then consult Stevens vol 2 to understand how > > > variables are used for different purposes depending on connection state > > > and which code path was taken (something I greatly dislike and would > > > love to change one day). > > Here is my understanding of these rfcs: > RFC 5681: > 3.2. Fast Retransmit/Fast Recovery > When we detect loss: > 2. When the third duplicate ACK is received, a TCP MUST set ssthresh to > no more than the value given in equation (4). When [RFC3042]is in use, > additional data sent in limited transmit MUST NOT be included in this > calculation. > > ssthresh = max (FlightSize / 2, 2*SMSS) <-- equation (4). > In my example, > ssthresh = max (14480 / 2, 2*1448) = 7240. i.e. 5 packets > > 3. The lost segment starting at SND.UNA MUST be retransmitted and cwnd > set to ssthresh plus 3*SMSS. This artificially "inflates" the > congestion window by the number of segments (three) that haveleft the > network and which the receiver has buffered. > > cwnd = (ssthresh + 3*SMSS) > In my example, > cwnd = 7240 + 3*1448 = 11584, i,e, 8 packets > > RFC 3782: > We either do sack based recovery *or* newreno based recovery. And we do > sack based when TF_SACK_PERMIT is present. > So I don't think this comes into play. Please correct me if that is not the > case. > > Stevens vol 2: > > sshthresh: > "When t_dupacks reaches 3 ( tcprexmtthresh ), the value of snd_nxt is > saved in onxt and the slow start threshold ( ssthresh ) is set to one-half > the current congestion window, with a minimum value of two segments." > > snd_cwnd: > The congestion window is set to the slow start threshold plus the number > of segments that the other end has cached. By cached we mean the number > of out-of-order segments that the other end has received and generated > duplicate ACKs for. These cannot be passed to the process at the other > end until the missing segment (which was just sent) is received. > > So, according to this, sshthresh itself is set pretty high i.e. cwnd/2. > And, snd_cwnd = sshthresh + cached packets at the other end. > > In my example, when server realizes loss, cwnd is 17377 i.e. 12 packets. > Half of that is 6 packets. And cached packets is 2 because the dup acks > we got were for 'ack 2897'. So, according to stevens, snd_cwnd should > have been 6+2 = 8 packets. Which matches up to what RFC 5681 suggests.
My interpretation of cached packets is wrong here. It should be the packets that receiver *cannot* send up the stack. Receiver told us via SACK (sack 1 {4345:10137}) that it has got at least up to 10137, i.e. 7 packets. And cumulative ack is 2897, i.e. 2 packets. So cached packets at the receiver that it cannot send up comes out to be 5 packets. According to this, the snd_cwnd should be 6(ssthresh) + 5(cached) = 11 packets. Cheers, Hiren
pgp42WTrDCjgY.pgp
Description: PGP signature