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

[Nick Banks <[e-mail]>]

nibanks commented on this pull request.



> @@ -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'm not super opinionated either way, but I feel like coupling the two things go us into this problem in the first place. They are related but still fairly independent in my mind. Especially, if we ever go with the model of a separate timer.

-- 
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#discussion_r250370612