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. Does this look reasonable? Cheers, Hiren
pgp0BZJvH9e9h.pgp
Description: PGP signature
