Subject: [quicwg/base-drafts] Clarify whether QUIC packets with no payload are acceptable (#1745)

From: ianswett <[email-masked]>
Date: Fri, 14 Sep 2018 11:44:21 -0700

QUIC changed to allow empty STREAM frames.

Are QUIC packets with no payload also acceptable?  They're pointless, but also presumably harmless?  Either way, it's worth being specific about this.

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

---

From: Nick Banks <[email-masked]>
Date: Fri, 14 Sep 2018 11:51:02 -0700

I agree they are harmless and I would prefer not to need to add extra logic to my implementation to check for empty packets. My vote is to allow them.

-- 
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/1745#issuecomment-421451607

---

From: Marten Seemann <[email-masked]>
Date: Fri, 14 Sep 2018 11:55:56 -0700

The reason we allowed empty STREAM frames was because they serve a purpose (they cause a change in the stream state machine). Before this change, you'd have to send a MAX_STREAM_DATA frame with the current offset, which was not a nice solution.

I'd prefer to keep disallowing empty packets, unless someone can come up with any use case for that.

-- 
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/1745#issuecomment-421452844

---

From: ianswett <[email-masked]>
Date: Fri, 14 Sep 2018 11:59:30 -0700

Marten, you said "keep disallowing empty packets", but I couldn't find any text in the IETF drafts that forbids them.  Possibly I missed it and then I'm happy to close this issue, since at least it's clear.

-- 
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/1745#issuecomment-421453742

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 14 Sep 2018 11:59:58 -0700

I agree with @marten-seemann. If there's no reason for empty packets to exist, I'd prefer we forbid them.

-- 
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/1745#issuecomment-421453886

---

From: Marten Seemann <[email-masked]>
Date: Fri, 14 Sep 2018 12:10:02 -0700

@ianswett: I didn’t look it up in the draft, but that’s what gQUIC is doing, that’s why I said we should keep doing it.

-- 
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/1745#issuecomment-421456480

---

From: MikkelFJ <[email-masked]>
Date: Fri, 14 Sep 2018 19:10:34 +0000 (UTC)

If you forbid empty, you must also consider padding only. And then you must consider if keep alive only happens with ping, which is extra load on the connection. What can go wrong with empty? Bandwidth abuse? That can happen by other means.

-- 
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/1745#issuecomment-421456612

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 14 Sep 2018 12:23:21 -0700

PING packets have a purpose... to elicit an ACK. Should an empty packet require an ACK?

-- 
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/1745#issuecomment-421459720

---

From: ianswett <[email-masked]>
Date: Fri, 14 Sep 2018 12:28:12 -0700

Thanks for clarifying Marten, that is what gQUIC does today.

Empty packets definitely should not elicit an ACK, since they're tiny and there's nothing to declare lost/retransmit/etc.

-- 
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/1745#issuecomment-421460853

---

From: MikkelFJ <[email-masked]>
Date: Fri, 14 Sep 2018 12:28:43 -0700

No, that is the point / PING has more overhead. You might not care for ping every keep alive packet. Not a big deal, just saying.

-- 
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/1745#issuecomment-421460974

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2018 18:45:18 +0000 (UTC)

Section 5:

> QUIC payloads MUST contain at least one frame, and MAY contain multiple frames and multiple frame types.

-- 
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/1745#issuecomment-422126730

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2018 11:45:19 -0700

Closed #1745.

-- 
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/1745#event-1850542824

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 18 Sep 2018 09:32:44 -0700

An empty long-header packet would be a natural choice for coalescing with a non-empty short-header packet.  Would we want to therefore call it a valid packet?  Or still call it invalid and let the language of "4.9. Coalescing Packets" take care of this case:

> If one or more packets in
>    a datagram cannot be processed yet [..] or processing fails (decryption failure, unknown type,
>    etc.), the receiver MUST still attempt to process the remaining
>    packets.  The skipped packets MAY either be discarded or buffered for
>    later processing [..].

-- 
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/1745#issuecomment-422460785