Value of congestion window (cwnd) when loss is detected

[hiren panchasara]

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
-------------- 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/036d1db5/attachment.bin>