Subject: Re: [quicwg/base-drafts] handshake and 0rtt data in a single packet (#630)

From: Kazuho Oku <[email-masked]>
Date: Tue, 23 Jan 2018 20:22:00 -0800

Rethinking this, I now think that [option 4](https://github.com/quicwg/base-drafts/issues/630#issuecomment-308361033) (i.e. add length field to long packet header to allow multiple QUIC packets to be stored in a single UDP packet) is the simplest.

A server might reject 0-RTT data. In such case, INITIAL packet is accepted but 0-RTT data is rejected.

If we allow INITIAL packet to convey 0-RTT data, that would mean that the part of the packet can be acknowledged. That collides with the principle that sent data is acked per packet.

Option 4 avoids the issue by allowing two QUIC packets to fit into a single UDP 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/630#issuecomment-360016646

---

From: ianswett <[email-masked]>
Date: Wed, 24 Jan 2018 04:34:15 +0000 (UTC)

My suggestion was for the INITIAL packet to embed the 0RTT data in an encapsulated 'packet' with it's own packet number, though the embedded packet may have it's packet number defined by the fact it's embedded.  The reason to embed rather than adding a length field is because it's very easy to define a frame type which indicates an embedded packet, and adding a length seems more complex and is typically not useful.

Also, the belief is that if you can't process the handshake data, there's no reason to try to process the embedded 0RTT data.

-- 
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/630#issuecomment-360018155

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Jan 2018 04:46:50 +0000 (UTC)

Thank you for pointing out that. I agree with your observations.

OTOH, it might still be the case that option 4 is easier to implement, since you do not need to encrypt INITIAL packet after encrypting 0RTT data as an encapsulated 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/630#issuecomment-360019661

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 24 Jan 2018 20:30:17 +0000 (UTC)

@ianswett That makes the most sense to me as well.

-- 
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/630#issuecomment-360263541