Subject: Re: [quicwg/base-drafts] PMTUD (#64)

From: Patrick McManus <[email-masked]>
Date: Tue, 03 Jan 2017 09:59:04 -0800

both 105 and 106 shift us from MAY use some kind of pmtud onto SHOULD use some kind of pmtud (the details of which vary). Functionally, that's creating a requirement of implementations that I don't think is justified as necessary by the experience so far and the complexity laid out in the PR.

given ian's experience of 90% effectiveness in comment in https://github.com/quicwg/base-drafts/issues/64#issuecomment-265016665 I would be wary of introducing ICMP into this 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/issues/64#issuecomment-270178534

---

From: martinduke <[email-masked]>
Date: Tue, 03 Jan 2017 10:11:26 -0800

> given ian's experience of 90% effectiveness in comment in #64 (comment) I would be wary of introducing ICMP into this at all.

'90% effectiveness' means we're leaving about 150 bytes per datagram on the table.  It would be fine to have a protocol that didn't packetize data all that efficiently in the name of simplicity, but if that is the goal then we should absolutely get rid of the many variable-length header fields, which introduce a ton of complexity for less than 100 bytes of savings in most cases.

-- 
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/64#issuecomment-270181742

---

From: Patrick McManus <[email-masked]>
Date: Tue, 03 Jan 2017 11:17:12 -0800

I should have been more clear that I was making 2 different (but related)
comments

1] PMTUD overall ought to remain a MAY

2] in describing PMTUD we could choose to detail a loss based in band
approach or an ICMP approach (or a hybrid etc..).  I meant to advocate for
the in band approach because of concerns over the complexity of ICMP given
its rather small impact here.

* part of the complexity is simply ICMP is a whole different protocol stack
- often with different same host consumers than the QUIC stack (as has been
mentioned).

* a bigger part of the complexity imo is that ICMP introduces
unauthenticated and unencrypted inputs into the system. So you have to at
least add the complexity of verifying them independently which undermines a
lot of their original advantages over a loss based approach anyhow (e.g
partially the argument about search space, the argument about faster) and
who knows if this also enables meaningful traffic analysis such as
identifying reliable vs non reliable streams, etc.. Much better in my
opinion to keep all quic inputs authenticated as much as possible - and
this is a place where it seems possible.

I'm not actually a big fan of the variable-length header fields, but your
argument isn't really apples to apples. Variable-Length-Encoded bytes are
truly saved bandwidth, while the 150 byte MTU shortcoming relates to packet
overhead ratios.. adding 150 bytes of data to each packet has about the
same bandwidth impact as saving 6 or 7 actual bytes if my arithmetic worked
out.

On Tue, Jan 3, 2017 at 1:11 PM, martinduke <[email-masked]> wrote:

> given ian's experience of 90% effectiveness in comment in #64
> <https://github.com/quicwg/base-drafts/issues/64> (comment) I would be
> wary of introducing ICMP into this at all.
>
> '90% effectiveness' means we're leaving about 150 bytes per datagram on
> the table. It would be fine to have a protocol that didn't packetize data
> all that efficiently in the name of simplicity, but if that is the goal
> then we should absolutely get rid of the many variable-length header
> fields, which introduce a ton of complexity for less than 100 bytes of
> savings in most cases.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/64#issuecomment-270181742>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5sxEbWTvUmKtgbh7rwymjzSWrReJbks5rOo9NgaJpZM4LCCRR>
> .
>

-- 
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/64#issuecomment-270198226

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jan 2017 23:34:26 -0800

I think that #106 is closer now, we should discuss at the interim.

-- 
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/64#issuecomment-273996749

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 18:13:48 -0800

As discussed in Tokyo, @martinduke to propose text for PR #106 to reduce the default packet size to the IPv6 default and recommend PLPMTUD with optional usage of ICMP information

-- 
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/64#issuecomment-275291775