Recovery-31: Limits on kPersistentCongestionThreshold values?

[gloinul]

Section 7.6.1:

The RECOMMENDED value for kPersistentCongestionThreshold is 3, which is approximately equivalent to two TLPs before an RTO in TCP.

Any values that needs to be explicitly forbidden? For example does it need a sentence saying that it MUST be larger than X? I would think that 1 would be to low and allow slow start after just one RTT+variations? I understand that likely would give the application bad behavior but likely also have negative impact on other applications if the QUIC stack ends up doing slow start crashing into the wall and then slow starting again?

[ianswett]

I lean towards not being overly proscriptive here. We could elaborate on the pros and cons of smaller and larger values if you think that is necessary? Exponential backoff is clearly critical, but it's less clear to me that the CWND really needs to be collapsed in these situations.

[gloinul]

I am really just trying to asses if there are significant risks with any specific ranges of values. For example causing very bursty behavior that could be considered harmful or becoming extremely aggressive after a persistent congestion event, in those cases some text may be necessary.

[larseggert]

Based on #4215, labeling this as "editorial"