Re: [quicwg/base-drafts] Explain asymmetric confirmation condition (#2881)

[Marten Seemann <[e-mail]>]

> Well, keep in mind that "recovery" for PING, which is the way you would approach this if you never had anything to send, depends on you generating a new PING with every transmission.

If I understand your point correctly, you would either need to change `    RetransmitUnackedCryptoData()` into `RetransmitUnackedCryptoDataAndAtLeastOne1RTTPacket()` or `RetransmitUnackedCryptoDataAndSend1RTTPing()`. That sounds doable, but it gets complicated when you take the congestion controller into account: It could happen that you have enough cwnd to send the retransmissions for the Handshake packets, but not for the 1-RTT packet. What you really want is to send the retransmission for the 1-RTT packet as a probe packet (i.e. never blocked by congestion control).

> I might be willing to let the connection time out in that case though.

I don't think timing out is acceptable in the case where just 2 packets are lost. In my opinion, the only case where a timeout is justifiable is if the connection is (effectively) blackholed.

You can see the root cause of #2863 as not a problem with loss recovery at all, but with our definition of "handshake confirmed": The server is dropping the keys too early. If the server kept the keys for longer, this loss pattern would harm the connection at all.

-- 
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/2881#issuecomment-509534345