Subject: [tcpm] draft-ietf-tcpm-rfc8312bis questions

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 28 Jul 2021 00:54:17 +0000

As discussed in the working group meeting, can you please clarify what behavior changes an implementation will see as a result of adopting 8312-bis versus RFC 8312? Particularly interested to know which changes will result in improved performance.

Thanks!

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 27 Jul 2021 17:57:47 -0700

btw it seems RFC5681 is even more conservative in dealing with stretched
acks in terms of ABC adoption.

sec 3.1

"During slow start,....  While
   traditionally TCP implementations have increased cwnd by precisely
   SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND
   that TCP implementations increase cwnd, per:

      cwnd += min (N, SMSS)                      (2)

   where N is the number of previously unacknowledged bytes acknowledged
   in the incoming ACK.  This adjustment is part of Appropriate Byte
   Counting [RFC3465] and provides robustness against misbehaving
   receivers that may attempt to induce a sender to artificially inflate
   cwnd using a mechanism known as "ACK Division" [SCWA99]."

On Tue, Jul 27, 2021 at 5:54 PM Praveen Balasubramanian <pravb=
[email-masked]> wrote:

> As discussed in the working group meeting, can you please clarify what
> behavior changes an implementation will see as a result of adopting
> 8312-bis versus RFC 8312? Particularly interested to know which changes
> will result in improved performance.
>
>
>
> Thanks!
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 28 Jul 2021 00:13:44 -0700

Hi Praveen,
Following changes improve the performance of CUBIC:

1. Updated K’s definition to use congestion window at the start of congestion avoidance. More details at issue https://github.com/NTAP/rfc8312bis/issues/1 <https://github.com/NTAP/rfc8312bis/issues/1>
2. Adding lower and upper bound for CUBIC target increase - lower bound is no longer mandatory with the change in 1. The upper bound is more interesting as it will make sure that the increase function is slower than slow start. This change averts the risk of overshooting the congestion window during CA. More details https://github.com/NTAP/rfc8312bis/issues/14 <https://github.com/NTAP/rfc8312bis/issues/14>
3. Always use a minimum cwnd of 2. https://github.com/NTAP/rfc8312bis/issues/7 <https://github.com/NTAP/rfc8312bis/issues/7>
4. Change the AIMD friendly equation to use segments acknowledged instead of using time. This allows more accurate increase for cases such as rate limited apps, sending after idle etc. It also performs better with ACK thinning. https://github.com/NTAP/rfc8312bis/issues/20 <https://github.com/NTAP/rfc8312bis/issues/20>
5. When W_est > W_max, we now set alpha to 1. This makes sure that Cubic doesn’t perform worse than New Reno when we are probing for new W_max. https://github.com/NTAP/rfc8312bis/issues/2 <https://github.com/NTAP/rfc8312bis/issues/2>
6. Spurious losses result in lowering the congestion window erroneously. So, we have added guidance for handling spurious losses for CUBIC.  https://github.com/NTAP/rfc8312bis/issues/23 <https://github.com/NTAP/rfc8312bis/issues/23>

Let me know if something is unclear or if you need more info. And as always, feedback is welcome on the current draft.

Thanks,
Vidhi

> On Jul 27, 2021, at 5:54 PM, Praveen Balasubramanian <[email-masked]> wrote:
>

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 28 Jul 2021 00:30:12 -0700

> btw it seems RFC5681 is even more conservative in dealing with stretched acks in terms of ABC adoption. 

Thanks Yuchung for double checking.

>       cwnd += min (N, SMSS)                      (2)

This is mentioned as a recommendation and not a MUST.

>    receivers that may attempt to induce a sender to artificially inflate

Later, 5681 references RFC 3465 - although not for any guidance on the max limit. I am not sure if RFC 5681 needs any update but it would be good to update 3465 to reflect today’s practices.

Thanks,
Vidhi

> On Jul 27, 2021, at 5:57 PM, Yuchung Cheng <[email-masked]> wrote:
> 
> btw it seems RFC5681 is even more conservative in dealing with stretched acks in terms of ABC adoption. 
> 
> sec 3.1
> 
> On Tue, Jul 27, 2021 at 5:54 PM Praveen Balasubramanian <pravb=[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>