Re: Proposed response to the 3GPP Liaison Statement

[Ted Hardie <[e-mail]>]

On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson <[e-mail]> wrote:

> https://tools.ietf.org/html/draft-iab-path-signals-03 seems like it might
> be a helpful supporting document.
>
> If you do choose to cite it, it has been published as RFC 8558, so it
would be best to use that.

Ted



> On Thu, Oct 31, 2019, at 12:09, Mark Nottingham wrote:
> > QUIC WG participants,
> >
> > Lars and I have discussed a response to this statement and plan on
> > sending the message below. If you have comments, please respond to this
> > e-mail by 6 November.
> >
> > Regards,
> >
> > ~~~
> > Thank you for your input to our specifications.
> >
> > Regarding the encryption of headers in addition to payload, this was a
> > conscious design decision by the Working Group. Transport header
> > encryption prevents modification by middleboxes, thereby avoiding
> > ossification of the protocol, and also makes traffic analysis more
> > difficult. The impact upon network operators was discussed extensively
> > as part of that decision.
> >
> > Regarding the spin bit, we believe that your characterisation is correct.
> >
> > Regarding packet loss measurements, QUIC does support them, but only by
> > the endpoints of communication -- not by third parties observing it.
> > Keys may be exported by one of the endpoints to allow decoding of
> > packet traces (e.g., with Wireshark), but that is not part of the QUIC
> > standard.
> >
> > Regarding performance analysis, it would be helpful if you described
> > your use case in more detail. However, it's important to know that the
> > Working Group decided early on that QUICv1 would focus on the use case
> > of HTTP/3.
> >
> > In turn, HTTP standardisation focuses primarily on the Web browsing use
> > case; while we acknowledge that there are other uses of the protocol,
> > and we accommodate them where possible, we cannot change the protocol
> > in ways that harms that use. Exposing transport metadata would likely
> > do so.
> >
> > Kind regards,
> >
> > Mark Nottingham and Lars Eggert, QUIC Working Group chairs
> > ~~~
> >
> >
>
>