Value of congestion window (cwnd) when loss is detected

[hiren panchasara]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150903/da0f3579/attachment.bin>