Subject: [quicwg/base-drafts] Recovery incorrectly declares packets lost at higher encryption levels (#1413)

From: ianswett <[email-masked]>
Date: Tue, 05 Jun 2018 01:52:02 -0700

Currently the recovery draft indicates you should use fast retransmit to declare packets lost, even if there's no evidence the peer can decrypt the packet.

A simple example is if the first client initial is sent with 0RTT and then the Initial is lost; Then the client Initial is retransmitted and acked, 0RTT packets will be declared lost via early and/or fast retransmit.

If QUIC sticks with a single packet number space, then encryption level will have to be added to each outstanding packet we'll have to not declare packets at an encryption level lost until at least one packet at that level has been acked.

-- 
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/issues/1413

---

From: Christian Huitema <[email-masked]>
Date: Wed, 06 Jun 2018 21:57:27 -0700

Don't you need to mark the packet level anyhow? In my implementation, I mark packet in the retransmission queue with their original encryption type, such as CI/0RTT/HS/1RTT. I need that to implement the acknowledgement checks (HS cannot ack 0RTT), and I use that to avoid spurious retransmission of 0RTT packet, pretty much the way you describe.

-- 
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/issues/1413#issuecomment-395293026

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Jun 2018 22:11:02 -0700

Could that be delaying loss detection for peers that do not buffer packets they do not understand?

-- 
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/issues/1413#issuecomment-395294991

---

From: ianswett <[email-masked]>
Date: Wed, 06 Jun 2018 23:53:54 -0700

Yes, my implementation has encryption level as well and you need it somewhere in practice, but it's not documented in the recovery draft.

@mikkelfj Can you clarify the exact concern about delaying loss detection?

-- 
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/issues/1413#issuecomment-395313139

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Jun 2018 23:57:54 -0700

@ianswett My concern was mostly a question because I don't have the full overview, but the concern is for example that a server will not retransmit 1-RTT data for several roundtrips while it is waiting for client finished while the client is a small IoT device with limited buffering so it drops anything it cannot consume. I'm not stating this would be a problem, merely asking.

-- 
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/issues/1413#issuecomment-395314047

---

From: ianswett <[email-masked]>
Date: Thu, 07 Jun 2018 01:21:16 -0700

Yes, a server would not retransmit 1RTT data until the peer had the keys the ACK them.  As you said, a peer may drop packets it can't immediately process, so I don't know of a way to improve upon this case.

-- 
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/issues/1413#issuecomment-395335198

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:49:06 -0700

Closed #1413.

-- 
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/issues/1413#event-1702641526