Re: [quicwg/base-drafts] Persistent Congestion Time Threshold (#2365)

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Thanks Nick, a few suggestions.

> @@ -1003,14 +1003,21 @@ packets might cause the sender's bytes in flight to exceed the congestion window
 until an acknowledgement is received that establishes loss or delivery of
 packets.
 
-When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and the sender's congestion
-window MUST be reduced to the minimum congestion window (kMinimumWindow).  This
-response of collapsing the congestion window on persistent congestion is
-functionally similar to a sender's response on a Retransmission Timeout (RTO) in
-TCP {{RFC5681}}.
+## Persistent Congestion
+
+The network is considered to be experiencing persistent congestion when the
+sender goes a period of time without receiving any ACK frames for its in-flight,
+ack-eliciting packets.  Generally, this can be calculated as a number of
+consecutive PTOs (pto_count is more than  kPersistentCongestionThreshold, see
+{{cc-consts-of-interest}}), but since a PTO only occurs if no other

How about "but since the PTO timer is reset when a new ack-eliciting packet is sent,"

> @@ -1132,6 +1144,8 @@ increases bytes_in_flight.
 
 ~~~
    OnPacketSentCC(bytes_sent):
+     if (bytes_in_flight == 0):
+       probe_start_time = Now()

It's important not to start this if the packet isn't ack-eliciting, but I will say that requirement makes this more complex, since you have to track the first ack-eliciting packet to be sent.

> @@ -1147,6 +1161,8 @@ acked_packet from sent_packets.
    OnPacketAckedCC(acked_packet):
      // Remove from bytes_in_flight.
      bytes_in_flight -= acked_packet.size
+     if (bytes_in_flight != 0):
+       probe_start_time = Now()

I don't think it's necessary to check bytes_in_flight != 0 here?

> @@ -1003,14 +1003,21 @@ packets might cause the sender's bytes in flight to exceed the congestion window
 until an acknowledgement is received that establishes loss or delivery of
 packets.
 
-When an ACK frame is received that establishes loss of all in-flight packets
-sent prior to a threshold number of consecutive PTOs (pto_count is more than
-kPersistentCongestionThreshold, see {{cc-consts-of-interest}}), the network is
-considered to be experiencing persistent congestion, and the sender's congestion
-window MUST be reduced to the minimum congestion window (kMinimumWindow).  This
-response of collapsing the congestion window on persistent congestion is
-functionally similar to a sender's response on a Retransmission Timeout (RTO) in
-TCP {{RFC5681}}.
+## Persistent Congestion

I think this should be a sub-section of Probe Timeout?

-- 
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/2365#pullrequestreview-195737638