Re: [quicwg/base-drafts] Discuss Application-Limited Sending (#1637)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -999,6 +996,18 @@ paces the sending of any packets in excess of the initial congestion window.
 A sender MAY implement alternate mechanisms to update its congestion window
 after idle periods, such as those proposed for TCP in {{?RFC7661}}.
 
+## Application Limited Sending
+
+The congestion window should not be increased in slow start or congestion
+avoidance when it is not fully utilized.  The congestion window could be
+under-utilized due to insufficient application data to send or flow control
+limits.
+
+When the sender is pacing(see {{pacing}}) packets, the sender may be unable

```suggestion
When the sender is pacing (see {{pacing}}) packets, the sender may be unable
```

> @@ -999,6 +996,18 @@ paces the sending of any packets in excess of the initial congestion window.
 A sender MAY implement alternate mechanisms to update its congestion window
 after idle periods, such as those proposed for TCP in {{?RFC7661}}.
 
+## Application Limited Sending
+
+The congestion window should not be increased in slow start or congestion
+avoidance when it is not fully utilized.  The congestion window could be
+under-utilized due to insufficient application data to send or flow control
+limits.
+
+When the sender is pacing(see {{pacing}}) packets, the sender may be unable
+to use the full congestion window for a period of time after receiving an
+ACK, due to pacing.  In this case, the sender should not consider themselves

```suggestion
acknowledgment.  In this case, the sender should not consider themselves
```

> @@ -999,6 +996,18 @@ paces the sending of any packets in excess of the initial congestion window.
 A sender MAY implement alternate mechanisms to update its congestion window
 after idle periods, such as those proposed for TCP in {{?RFC7661}}.
 
+## Application Limited Sending
+
+The congestion window should not be increased in slow start or congestion
+avoidance when it is not fully utilized.  The congestion window could be
+under-utilized due to insufficient application data to send or flow control
+limits.
+
+When the sender is pacing(see {{pacing}}) packets, the sender may be unable
+to use the full congestion window for a period of time after receiving an
+ACK, due to pacing.  In this case, the sender should not consider themselves
+application limited and should allow the congestion window to increase.

I'm not really following the logic here.  I think that you need more words.

The reason that the congestion window is limited in this fashion is that without being exercised, there is no assurance that this much data can be sent.  If there is a sudden increase in demand from the application such that the inflated limit is now used, that results in using an untested limit, which might result in severe congestion.

-- 
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/1637#pullrequestreview-191994034