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

[Patrick McManus <[e-mail]>]

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 <[e-mail]> 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