Subject: Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)

From: ekr <[email-masked]>
Date: Sat, 01 Feb 2020 09:37:15 -0800

"
    For the purpose of verifying that an Initial packet is larger than the required minimum, all bytes count.
    For all other purposes, including congestion control and amplification control, only valid packets count.
"

I don't agree that these bytes shouldn't count for amplification control. Amplification control is about received byes, and these are bytes.

-- 
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/3333#issuecomment-581052047

---

From: Marten Seemann <[email-masked]>
Date: Mon, 03 Feb 2020 06:18:19 -0800

> I don't agree that these bytes shouldn't count for amplification control. Amplification control is about received byes, and these are bytes.

Does that mean random garbage (that's not appended to a QUIC packet) is supposed to count as well? That would require implementations to do 5-tuple tracking.

-- 
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/3333#issuecomment-581435301

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 03 Feb 2020 06:42:22 -0800

On Mon, Feb 3, 2020 at 6:18 AM Marten Seemann <[email-masked]>
wrote:

> I don't agree that these bytes shouldn't count for amplification control.
> Amplification control is about received byes, and these are bytes.
>
> Does that mean random garbage (that's not appended to a QUIC packet) is
> supposed to count as well? That would require implementations to do 5-tuple
> tracking.
>
That doesn't seem to follow necessarily. If a UDP datagram contains a valid
QUIC packet, count the bytes of the datagram. Otherwise, drop the datagram.

-- 
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/3333#issuecomment-581446588

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Feb 2020 06:51:13 -0800

IIRC we discussed and agreed that amplification control happens an the UDP datagram level. The rational was that unless we do so, clients using 0-RTT by coalescing Initial and 0-RTT packets into a single datagram would see inferior performance.

-- 
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/3333#issuecomment-581450687

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 04 Feb 2020 16:09:12 -0800

Whatever the language about outside padding, an endpoint must not discard the entire datagram, just because data after a long-header packet looks unparseable to it. It is possible that the client is trying a 0-RTT resumption with packet coalescing using a QUIC version/extension that is unknown to the server.  The right behavior is to process packets that are understood (which may result in version negotiation) and stop processing that datagram.

-- 
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/3333#issuecomment-582177920

---

From: Christian Huitema <[email-masked]>
Date: Wed, 05 Feb 2020 01:52:30 -0800

This "unparseable PAD" looks like a "kindness of strangers" issue. An implementer may want to do that because it looks like it will save 3 CPU cycles somewhere, but that only works if all other implementation agree that it is a good idea. Experience shows that they don't. So just accept that this will just not work 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/3333#issuecomment-582327039

---

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Feb 2020 02:07:41 -0800

"For the purposes of avoiding amplification prior to address validation, servers MUST count the bytes received in datagrams that are uniquely attributed to a connection.  This includes datagrams that contain packets that are successfully processed and datagrams that contain discarded 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/3333#issuecomment-582333099

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 05 Feb 2020 02:12:01 -0800

@martinthomson "that are uniquely attributable to a connection" is vague and will differ by implementation (for example, one implementation will not even try to attribute a packet with an invalid "SCID Len" but another will).

How about: "... well-formed packets that are uniquely attributable to a connection" ?

-- 
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/3333#issuecomment-582334723

---

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 02:16:04 -0800

Discussed in ZRH. Proposed resolution is @martinthomson's quoted comment above. 

-- 
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/3333#issuecomment-582336344

---

From: ekr <[email-masked]>
Date: Wed, 05 Feb 2020 02:16:45 -0800

MT "packets that are discarded, including when those packets are the sole packets in the datagram"

-- 
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/3333#issuecomment-582336643