Subject: [quicwg/base-drafts] Limit the size of packets (#501)

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 21:47:20 -0700

This is primarily for constrained implementations.  Based on experience with
TLS, there can be real burden for those implementations just implementing an
AEAD correctly over large records.  This setting would allow an absurdly
constrained device some defense against peers who might otherwise send jumbo
packets.  After all, jumbo packets can be more efficient.

No real consensus for this yet, just a proof that it is possible.

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

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

-- Commit Summary --

  * Limit the size of packets

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/501.patch
https://github.com/quicwg/base-drafts/pull/501.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/501

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 18:29:48 -0700

I'm not convinced there's a need. QUIC is pretty complex; I would argue that severely constrained implementations that can't do AEAD over 1280 bytes are unlikely to do QUIC. 

TLS doesn't have the luxury of saying this, since it has to work for every lightbulb.

-- 
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/501#issuecomment-299351090

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 May 2017 18:39:09 -0700

hq is certainly quite complex, but is QUIC really that complex if you pare it down?  It's not that much more complicated than TLS and TCP.  I wouldn't be so presumptive about what can and cannot be done.  Also, @hardie was so kind as to point me at [RFC 2675](https://tools.ietf.org/html/rfc2675), which suggests that 64k isn't the outer limit on packet size.

-- 
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/501#issuecomment-299351997

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 19:12:33 -0700

Yes, just TLS + QUIC is more complex than TLS + TCP. Having worked on the SCTP implementation in BSD which had no hq but only transport, I can say that adding multistreaming alone adds a fair bit of complexity. (I'm talking about prod code, not a lab prototype.)

It surely is possible to pare it down to the point that much of the flexibility is lost, to the point that the endpoint can't do AEAD over 1232 bytes (not 1280 bytes.) But why would one care to use QUIC at that point and not just do TCP (or even TCP over UDP)?

-- 
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/501#issuecomment-299355241

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 May 2017 19:18:53 -0700

Careful, you stand to risk undermining some of your benefits.  The limit I'm more concerned about here is 64k, not 1232/1252.  The protocol doesn't prevent an endpoint from sending 64k packets (or greater if you accept the possibility that someone implemented RFC 2675, which I understand is unlikely).

-- 
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/501#issuecomment-299355777

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 19:44:15 -0700

I don't understand what you mean by "Careful, you stand to risk undermining some of your benefits." -- can you clarify?

Yeah, I guess the only other outcome would be that the endpoint would drop a large packet, which is ... less than awesome. Ok.

-- 
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/501#issuecomment-299358047

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 19:44:51 -0700

janaiyengar approved this pull request.

-- 
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/501#pullrequestreview-36427710

---

From: Martin Thomson <[email-masked]>
Date: Mon, 08 May 2017 18:21:13 -0700

Even with approval, I want to leave this until after the interim before landing, so that we can discuss it in the wider group.  It's not urgent.

-- 
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/501#issuecomment-300034678

---

From: Patrick McManus <[email-masked]>
Date: Tue, 09 May 2017 08:09:24 -0700

I'm concerned about this because I think the most likely outcome is an
implementation trying to use this to deal with PMTU issues via endpoint
configuration and accidentally creating long term ossification as the
network evolves. Packet size is more of a network property than it is a
resource scaling property (though this issue clearly shows that it is
both!) and configuring it strictly as resource limit might be a mistake.

On Mon, May 8, 2017 at 9:21 PM, Martin Thomson <[email-masked]>
wrote:

> Even with approval, I want to leave this until after the interim before
> landing, so that we can discuss it in the wider group. It's not urgent.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/501#issuecomment-300034678>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5sxxBS6fsIbITN9f0CHiJtsQCR-6Jks5r37-IgaJpZM4NQOTD>
> .
>

-- 
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/501#issuecomment-300195452

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 May 2017 18:58:54 -0700

Yes, this isn't a stand-in for PMTU.  Using it for that would be quite inappropriate.  I can add an admonition on that point if you think that would help at all.

-- 
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/501#issuecomment-300352105

---

From: janaiyengar <[email-masked]>
Date: Wed, 10 May 2017 22:50:09 -0700

Discussing at interim SGTM.

-- 
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/501#issuecomment-300689192