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

From: janaiyengar <[email-masked]>
Date: Wed, 14 Mar 2018 11:11:44 +0000 (UTC)

Discussed at editors' meeting. We seemed to agree on something like option 4, with some specific rules: create "compound packet types" which have a length, and encode HS+0RTT and HS+1RTT long header packet types. To keep packet processing simple, the long header can be repeated so that a receiver can process parts of the packet under different keys in a straightforward manner.

This doesn't have to be the final resolution, but we should drive this issue to an end.

@kazuho : Would you be interested in driving this? Would you be able to write up a PR with a proposed design (use the one above if you like that design) and propose to the wg?

-- 
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-372985171

---

From: Marten Seemann <[email-masked]>
Date: Thu, 22 Mar 2018 02:34:32 -0700

Do we need to change the invariants for that?
It seems like we could achieve this by adding a length field to the Long Header.

-- 
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-375233626

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Mar 2018 09:47:23 +0000 (UTC)

No, this doesn't modify the invariants.  We'd just define additional packet types for v1 which have a length + additional packet to follow.

-- 
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-375237332

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Mar 2018 09:50:15 +0000 (UTC)

@janaiyengar 
> Discussed at editors' meeting. We seemed to agree on something like option 4, with some specific rules: create "compound packet types" which have a length, and encode HS+0RTT and HS+1RTT long header packet types.
> (snip)

I can handle that, but should we create a PR for this issue now?

I think that the design decision might change based on if we will be having separate packet number space for handshake and protected 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/630#issuecomment-375238143

---

From: ianswett <[email-masked]>
Date: Thu, 22 Mar 2018 03:07:32 -0700

I'm happy to see a PR.

I'm happy adding a length to the INITIAL and HANDSHAKE packet types and then another packet type could be put in the same packet.  I'd rather not repeat connection ID(s) because I don't believe it's possible for them to be different, but given I think we're heading for different PN spaces for unencrypted and encrypted packets, repeating the PN portion is important.

The negative of this is that the second packet type is a special case because you have to know it doesn't include connection IDs.  But if you include them, it's a waste of space and redundant.  I think I prefer a special case over redundant information that may not match, but that's me.

-- 
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-375243126

---

From: MikkelFJ <[email-masked]>
Date: Thu, 22 Mar 2018 03:14:48 -0700

Wasting space is hardly a concern in packets of 1280 bytes in length that are likely padded? And for long certs, if you need multiple packets, CID is hardly going to be the deciding factor. So I'd say keep the packet formats unchanged.

I would assume the packet number increases in the second packet added to the same MTU, no?

I think it is a good idea to only allow certain packets to be heading other packes such as Initial and Handshake, otherwise general packet handling gets unnecessarily complex.

-- 
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-375245526

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 22 Mar 2018 11:06:45 -0700

> Wasting space is hardly a concern in packets of 1280 bytes in length that are likely padded?

One common case where the space becomes precious is when you are doing 0 RTT, and the server tries to use a compound packet to send ServerHello...ServerFinished and the response in 0.5 RTT.

-- 
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-375404629