Subject: [quicwg/base-drafts] Order of Compound Packets (#1287)

From: Nick Banks <[email-masked]>
Date: Wed, 11 Apr 2018 10:52:31 -0700

I am implementing the QUIC compound packets and I am coming across some implementation pain points related to the order of processing the packets in the UDP payload.

Generally, I have a model of "current buffer pointer" and "bytes left" and this continues though the UDP payload, processing QUIC packets until it runs out of space, encounters an invalid packet header that prevents any further processing, or it encounters a packet that requires a particular key to decrypt, that we don't have yet.

1. This model doesn't work if the client Initial packet isn't the first packet in UDP payload, because I use "bytes left" to do the packet length comparison, not UDP payload length. Obviously this could be fixed just by passing "total payload length" around, but that does make the implementation a bit messier.

2. I currently support deferring packets (up to a limit) that I don't have the keys for yet, so that I can process them when/if I do get the key. As you can see from my description of my processing logic above, if I get to a QUIC packet that I don't have the key for, I stop (for the time being) processing the rest of the packet, mark the packet to keep my place, and defer it for later. This would cause problems if a peer packaged up 0-RTT packets before Handshake.

The simple way to fix all these is just to require than Handshake packets be before 0-RTT packets. 1-RTT packets (short headers) are already last because they consume the rest of the UDP payload. Would it be acceptable to make "Handshake before 0-RTT" a MUST?

-- 
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/1287

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 12 Apr 2018 00:33:35 +0000 (UTC)

I agree that the compound packets are pain, programming-wise.  Now one has to have "real packets" versus "QUIC packets" or do something else equally odd.

I'd go as far as to say that there can be at most one long-header packet in a compound packet.  (Is there a use case for having more than one?)

-- 
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/1287#issuecomment-380637430

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Apr 2018 17:59:11 -0700

@nibanks I can understand that the need for passing "total payload length" can be a bit of annoyance.

OTOH, I am not sure why the support for deferring the packets need to be complicated. Can't you buffer the 0-RTT packet found in a compound packet the same way as you handle a UDP datagram that only contains one 0-RTT packet?

My point is that even if we do not mandate handshake packets to be sent before 0-RTT packets most implementations will do so, and that you do not need to optimize (by avoiding a copy) for the case where a client sends a compound UDP datagram that contains a 0-RTT packet followed by a handshake packet.

-- 
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/1287#issuecomment-380641168

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Apr 2018 01:03:11 +0000 (UTC)

@dtikhonov 
> I'd go as far as to say that there can be at most one long-header packet in a compound packet. (Is there a use case for having more than one?)

Handshake packets and 0-RTT packets are both long header packets, so we cannot say that.

Regarding adding restrictions on how packets can be combined, my weak preference goes to having no restriction, since it would allow us to process bundling after our QUIC implementation emits a packet.

Consider the case where we have a packet in the send queue (due to pacing) and then the client decides to send another packet. Wouldn't it be great if we could simply append the new packet to the packet already stored in the queue?

-- 
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/1287#issuecomment-380641753

---

From: Nick Banks <[email-masked]>
Date: Wed, 11 Apr 2018 18:12:45 -0700

@kazuho I agree that's an interesting idea to be able to append a new packet to an already queued up one, but practically I don't know how often it would occur. How often will this new packet end up being a handshake one? I'd expect nearly never. Handshakes would likely be the first ones that needed to be sent out in the first place. If the current queued packet is 1-RTT you can't add to it. And if the currently queued is handshake, then you can already queue to it.

The problem with my deferred packet processing is that I don't want to allocate additional state to keep track of which packets in the UDP payload have already been processed and which haven't. I just want to keep track of the "next" one to process.

-- 
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/1287#issuecomment-380643219

---

From: Nick Banks <[email-masked]>
Date: Wed, 11 Apr 2018 18:43:40 -0700

In addition, if you do happen to have a 0-RTT packet in the queue and you have a handshake packet to send, you would prepend it to the queued packet.

-- 
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/1287#issuecomment-380647928

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Apr 2018 01:57:12 +0000 (UTC)

@nibanks the second problem might be addressed by providing a pseudo-packet that uses the underlying UDP datagram as its source?  I think that for the first, it's tough, but the right check here is on the size of the UDP datagram and not the QUIC packet.

-- 
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/1287#issuecomment-380650021

---

From: Nick Banks <[email-masked]>
Date: Thu, 12 Apr 2018 02:06:15 +0000 (UTC)

I agree that I can come up with a solution to all the problems without changing the spec. I'm just saying I believe it is simpler to implement if we make the simple restriction of Handshake packets before 0-RTT packets.

-- 
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/1287#issuecomment-380651454