Subject: [quicwg/base-drafts] Coalescing guidance (#1423)

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jun 2018 14:04:43 -0700

Fixes #1287.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1423

-- Commit Summary --

  * Coalescing guidance

-- File Changes --

    M draft-ietf-quic-transport.md (14)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1423.patch
https://github.com/quicwg/base-drafts/pull/1423.diff

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

---

From: Nick Banks <[email-masked]>
Date: Wed, 06 Jun 2018 22:31:34 +0000 (UTC)

nibanks approved this pull request.

LGTM

-- 
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/1423#pullrequestreview-126579441

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jun 2018 04:35:30 -0700

@MikeBishop pushed 1 commit.

e772275  Include decryption failures

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1423/files/195f144870a810fff9e4e1518f52f779d384ea41..e77227596318c72d844707655d68bf59dc5c0bfb

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jun 2018 04:37:04 -0700

Updated to reflect suggestion from second day of Kista interim:  Should also apply to packets that fail decryption, as there are cases an implementation will want to put a long header with a junk payload followed by a short header 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/pull/1423#issuecomment-395734738

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Jun 2018 13:48:26 +0000 (UTC)

martinthomson commented on this pull request.

This is missing text on what to do if the connection ID doesn't match.  I think that we need to be explicit about that.  Otherwise, this looks great.

-- 
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/1423#pullrequestreview-127168018

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Jun 2018 06:55:33 -0700

I don't think connection ID is special. Anything that is a protocol error is in the same boat. E.g. MUST discard the rest of the datagram, and MAY discard the entire datagram. Assuming pre-handshake. Post handshake it would be a protocol violation error with connection close.

-- 
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/1423#issuecomment-395768194

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Jun 2018 17:38:02 -0700

Connection ID could be special.  Keep in mind that a datagram is routed based solely on the value of the first destination connection ID.  If the first packet in the datagram contains the wrong connection ID, then I would assume that it would be OK to treat that by routing it to /dev/null.

-- 
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/1423#issuecomment-396094869

---

From: ianswett <[email-masked]>
Date: Mon, 11 Jun 2018 05:19:11 -0700

In most architectures, I'd expect that if the connection ID is different for the second QUIC packet, the receiver will drop it, since it is likely for a different host.

The alternative would be to expect receivers to process the first packet, and if the next one has a different connection ID for a different host, have it redirect the packet.  Which seems pretty crazy to 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/pull/1423#issuecomment-396223935

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Jun 2018 10:22:52 -0700

The case where the second CID is from a different host is relatively benign -- the receiver would process it and discard it anyway.  More insidious is when the two CIDs are both from the same connection -- you've just given a pretty strong linkability signal.

I'm inclined to say that you MUST NOT send different CIDs, and receivers SHOULD skip any subsequent packet whose DCID differs from that of the first 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/pull/1423#issuecomment-396319677

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Jun 2018 17:30:37 +0000 (UTC)

26c5b74  No mixing CIDs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1423/files/e77227596318c72d844707655d68bf59dc5c0bfb..26c5b742d37f6adbf84fecec5e0abf0d29563484

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 11 Jun 2018 23:57:14 -0700

kazuho commented on this pull request.

 Every QUIC packet that is coalesced into a single UDP datagram is separate and
 complete.  Though the values of some fields in the packet header might be
 redundant, no fields are omitted.  The receiver of coalesced QUIC packets MUST
 individually process each QUIC packet and separately acknowledge them, as if
-they were received as the payload of different UDP datagrams.
+they were received as the payload of different UDP datagrams.  If one or more
+packets in a datagram cannot be processed, either because the keys are not yet
+available or because decryption fails, the receiver MUST still attempt to

It might make sense to add the case where the long header type is invalid. Explicitly allowing a sender to emit an invalid long header type will help us grease the first octet.

-- 
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/1423#pullrequestreview-127837762

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jun 2018 10:36:41 -0700

MikeBishop commented on this pull request.

I was initially dubious about this, thinking that the Length field is type-specific.  But it appears to only be version-specific, which means you can still trust the Length on an unknown type.

Done, though the wording feels a little awkward; suggestions for improved flow welcome.

-- 
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/1423#discussion_r194827321

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jun 2018 10:37:07 -0700

3f3da75  Kazuho's suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1423/files/26c5b742d37f6adbf84fecec5e0abf0d29563484..3f3da757b33e58fd112cb69f8d3f7d396a298f39

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jun 2018 15:51:40 -0700

0653378  Say why

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1423/files/3f3da757b33e58fd112cb69f8d3f7d396a298f39..0653378aedad324bdbc299d4c1f87060928eb066

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jun 2018 16:05:30 -0700

Merged #1423.

-- 
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/1423#event-1677500469