Re: [quicwg/base-drafts] No RTT samples, no persistent congestion (#3889)

[Kazuho Oku <[e-mail]>]

@martinthomson I think that depends on the following two aspects:

First, the accuracy we want to have in the definition of persistent congestion (see https://github.com/quicwg/base-drafts/issues/3875#issuecomment-658532149). If we think of persistent congestion as a ballpark figure that resembles a blackhole period of somewhere *around* 3 PTO, during which an endpoint would have sent *at least 2 or 3 packets*, then I think the change proposed in this PR is sufficient.

Second, if your concern is about endpoints not arming PTO for ApplicationData and that becoming an edge of persistent congestion, then I'd assume that the wort case that we might want to discuss is when all the following conditions are met:
* the TLS handshake transcript send by the server does not fit in 3 datagrams (therefore the server would have RTT estimate when sending the first 0.5 RTT data)
* client spends long time in verifying the certificate chain
* both the 1-RTT packets that carrried 0.5 RTT data and the first 1-RTT data (i.e. the one containing HANDSHAKE_DONE) gets lost

Under such scenario, persistent congestion would be declared. But then, the condition matches the definition of the previous paragraph. Therefore, I think we can call this a non-issue, if we are fine with what's written in the previous paragraph.

-- 
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/3889#issuecomment-659156793