Re: [quicwg/base-drafts] Rework section on persistent congestion (#3961)

[mjoras <[e-mail]>]

@mjoras commented on this pull request.



>  max_ack_delay irrespective of the packet number spaces in which losses are
 established.
 
+This duration is intended to allow a sender to use initial PTOs for aggressive
+probing, as TCP does with Tail Loss Probe (TLP; see {{RACK}}), before
+establishing persistent congestion, as TCP does with a Retransmission Timeout
+(RTO; see {{?RFC5681}}).
+
+The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is
+approximately equivalent to two TLPs before an RTO in TCP.
+
+This design uses an explicit duration instead of consecutive PTO events since
+the PTO timer is restarted every time an ack-eliciting packet is sent. An
+application that trickles data restarts the PTO timer repeatedly, preventing the

Yeah I think this paragraph is a little confusing. I think the intent is basically suggesting that an application which itself is steadily writing relatively small amounts of data into the transport will perpetuate the PTO timer, and hence detecting persistent congestion should not depend on this. However the use of "application" and "trickle" together is probably going to be confusing to some.

Additionally it seems like the first sentence and the last sort of overlap, which makes the paragraph read a little strangely.

-- 
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/3961#discussion_r461976858