Subject: [tcpm] Discrepancy in guidance about cwnd at loss?

From: hiren panchasara <[email-masked]>
Date: Mon, 25 Apr 2016 17:20:40 -0700

In case of Fast Recovery, what should cwnd be when the loss is realized
on 3rd dupack?

In RFC6675 5. Algorithm Details, (4.2) says:
"ssthresh = cwnd = (FlightSize / 2)
The congestion window (cwnd) and slow start threshold
(ssthresh) are reduced to half of FlightSize per [RFC5681]."

But looking at RFC5681 3.2.  Fast Retransmit/Fast Recovery, (3) says:
"The lost segment starting at SND.UNA MUST be retransmitted and cwnd set
to ssthresh plus 3*SMSS."

'per [RFC5681]' seems wrong in RFC6675. Or am I missing or
mis-interpreting something?

Cheers,
Hiren

---

From: Mark Allman <[email-masked]>
Date: Mon, 25 Apr 2016 23:09:38 -0400

> mis-interpreting something?

The plus 3*SMSS is an artificial construct to allow additional
sending before loss recovery is over.  You have to read through the
fast recovery algorithm to see how it works.  Ultimately, (1) we
don't send more than FlightSize/2 and (2) cwnd is dropped back to
ssthresh (i.e., FlightSize/2).

So, the "per [RFC5681]" is correct.

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 25 Apr 2016 21:57:13 -0700

> ssthresh (i.e., FlightSize/2).
The key is that 3*SMSS inflation magic is to deal with non-SACK
situation. in RFC 6675 this is not needed b/c the sacked packets are
discounted in the 'pipe' variable. Linux folded the former trick into
the pipe algorithm by emulating the sacked_out counters
(tcp_add_reno_sack()) when receiving DUPACKs on non-sack connections.

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 26 Apr 2016 00:08:10 -0700

Hi Hiren,

It's ok because the behavior will be the same in principal as Mark and
Yuchung explained.
Let's use a simple example.
Say cwnd=4 and you've sent S1, S2, S3, S4, but S1 is lost while S2, S3, S4
have arrived at the receiver.
If you follow RFC5681 description, after receiving 3 dup acks, cwnd = 2+3 =
5.
In this case, the left edge of the window is S1 and the right edge will be
S5 as cwnd = 5. This allows you to transmit S5.

In case of RFC6675, cwnd = 2 and pipe size = 1. (because S2, S3, S4 have
been SACKed)
This also allows you to send S5.

Thanks,
--
Yoshi

---

From: hiren panchasara <[email-masked]>
Date: Tue, 26 Apr 2016 08:40:50 -0700

On 04/25/16 at 09:57P, Yuchung Cheng wrote:
> situation.
Ah, okay. This is what I was missing.
> in RFC 6675 this is not needed b/c the sacked packets are

Thanks a lot for taking time and explaining.

Cheers,
Hiren

---

From: hiren panchasara <[email-masked]>
Date: Tue, 26 Apr 2016 08:42:09 -0700

> This also allows you to send S5.

Thank you for providing the example. :-)

Cheers,
Hiren