Subject: [quicwg/base-drafts] Define under-utilizing the congestion window (#2675)

From: ianswett <[email-masked]>
Date: Tue, 07 May 2019 18:18:21 -0700

Fixes #2630
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2675

-- Commit Summary --

  * Define under-utilizing the congestion window

-- File Changes --

    M draft-ietf-quic-recovery.md (8)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2675.patch
https://github.com/quicwg/base-drafts/pull/2675.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675

---

From: Marten Seemann <[email-masked]>
Date: Tue, 07 May 2019 18:20:20 -0700

marten-seemann commented on this pull request.

> @@ -836,9 +836,11 @@ in Linux (3.11 onwards).
 
 ## Under-utilizing the Congestion Window
 
-A congestion window that is under-utilized SHOULD NOT be increased in either
-slow start or congestion avoidance. This can happen due to insufficient
-application data or flow control credit.
+When bytes in flight is smaller than the congestion window and sending is not
+pacing limited, the congestion window is under-utilized.  When this occurs,

Where does the pacing limitation come from? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#pullrequestreview-234828693

---

From: ianswett <[email-masked]>
Date: Tue, 07 May 2019 18:32:46 -0700

ianswett commented on this pull request.

 

There are congestion controllers now, and hopefully more in the future, that operate primarily pacing limited, not CWND limited, so this was an effort to capture that, but it's certainly imperfect.  Any suggestions?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r281885995

---

From: ianswett <[email-masked]>
Date: Thu, 09 May 2019 06:15:30 -0700

@ianswett pushed 1 commit.

e9043ce40d8a9f55e4940208401e34edf5088c43  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675/files/8688ce44a2085781d464ee68958a728a3d60afbe..e9043ce40d8a9f55e4940208401e34edf5088c43

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 06:00:34 -0700

4913286e08119bdb3d32a5a88f281076156b56a5  Reword section on bursts

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675/files/e9043ce40d8a9f55e4940208401e34edf5088c43..4913286e08119bdb3d32a5a88f281076156b56a5

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 16:27:04 -0700

janaiyengar commented on this pull request.

This still misses an important question: when a sender goes to increase the congestion window (upon receiving an ACK), what does it do? Should it not increase the cwnd because inflight < cwnd? There's discussion in #2554 which is still relevant to this.

> @@ -848,9 +850,10 @@ and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
-Bursting more than an intial window's worth of data into the network might
-cause short-term congestion and losses. Implemementations SHOULD either use
-pacing or reduce their congestion window to limit such bursts.
+Sending multiple packets into the network without any delay between them
+creates a burst of load that might cause short-term congestion and losses.

```suggestion
creates a packet burst that might cause short-term congestion and losses.
```

> @@ -848,9 +850,10 @@ and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
-Bursting more than an intial window's worth of data into the network might
-cause short-term congestion and losses. Implemementations SHOULD either use
-pacing or reduce their congestion window to limit such bursts.
+Sending multiple packets into the network without any delay between them
+creates a burst of load that might cause short-term congestion and losses.
+Implemementations SHOULD either use pacing or reduce their congestion window

```suggestion
Implementations SHOULD either use pacing or reduce their congestion window
```

> @@ -848,9 +850,10 @@ and not fully utilize the congestion window due to this delay. A sender
 should not consider itself application limited if it would have fully
 utilized the congestion window without pacing delay.
 
-Bursting more than an intial window's worth of data into the network might
-cause short-term congestion and losses. Implemementations SHOULD either use
-pacing or reduce their congestion window to limit such bursts.
+Sending multiple packets into the network without any delay between them
+creates a burst of load that might cause short-term congestion and losses.

I don't think this description of burst is necessary though. It doesn't help with #2686, if that's what you were trying to address. I would drop this, but I realized that the existing statement is potentially misleading in what it says. (more discussion on this in #2686)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#pullrequestreview-236344073

---

From: ianswett <[email-masked]>
Date: Mon, 13 May 2019 18:10:32 -0700

c3ca83ebd719ecd6dd682d1355e9d30593a947e6  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675/files/4913286e08119bdb3d32a5a88f281076156b56a5..c3ca83ebd719ecd6dd682d1355e9d30593a947e6

---

From: ianswett <[email-masked]>
Date: Mon, 13 May 2019 18:18:13 -0700

I added the definition of burst, because I realize it might not be obvious?

I think the core of #2686 is that the existing text is unclear.  The existing text says you SHOULD not burst more than an initial window into the network(ever), with nothing specific to coming out of quiescence.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r283593774

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 May 2019 18:42:11 -0700

>  The existing text says you SHOULD not burst more than an initial window into the network(ever), with nothing specific to coming out of quiescence.

Yes, I think this is the problem. I believe the intent here was to say that a sender SHOULD NOT do more than IW as an upper limit on bursts without recommending that as the correct limit for any bursting.

We can either specify that _all_ bursts should be limited to IW, irrespective of how much data is in the network already, or that bursts coming out of quiescence should be limited to IW. While I'm not sure how to change this text here, I'm trying to steer clear of saying something overly broad. (I'll suggest some text).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r284953524

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 01:04:55 -0700

mikkelfj commented on this pull request.

If not out of quiescence, an IW burst would probably be bad. You could just wait a millisecond or two and repeat in badly designed pacing logic.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r285016666

---

From: ianswett <[email-masked]>
Date: Fri, 17 May 2019 05:48:08 -0700

I'd rather have it apply always, because I don't want to have one packet sent, and then a sender can burst the full window.  Making it specific to quiescence adds unnecessary complexity to the rules and may not accomplish the goal of mitigating the congestion caused to other flows of bursty sending.

I thought my existing text does that, but people are still confused, so better text would be greatly appreciated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r285110568

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 05:55:52 -0700

The problem is that it is not clear when the next burst can be sent.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2675#discussion_r285113566