Subject: Proposed response to the 3GPP Liaison Statement

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 Oct 2019 12:09:57 +1100

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
~~~

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 31 Oct 2019 12:13:48 +1100

https://tools.ietf.org/html/draft-iab-path-signals-03 seems like it might be a helpful supporting document.

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,
> 
> ~~~
> 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 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,
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 31 Oct 2019 06:58:06 -0700

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

> If you do choose to cite it, it has been published as RFC 8558, so it
would be best to use that.

Ted

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 31 Oct 2019 18:14:09 +0000

RFC 8558 is very relevant.  It says, in Recommendations, that implicit signals should be replaced by explicit signals when originators wish to provide them to network elements on the path.

Since QUIC is removing implicit signals, I read the question from 3GPP to mean “what are you replacing them with [for originators who wish to provide them]?”.  QUIC WG response reads as: “nothing, short of attaching encryption keys to packets”.  Even if QUIC v1 today can offer no replacement for the removed signal, QUIC WG should make an effort to at least suggest a practical way to satisfy RFC 8558’s recommendation of an explicit signal “for those who want it”.  Maybe point to some other specific layer where the WG believes the signal belongs (and can be deployed relatively quickly)?

As for the content of the reply, it includes “The impact upon network operators was discussed extensively as part of that decision.”  Were network operators a part of those discussions, and what was their feedback?

  *   Igor

From: Ted Hardie <[email-masked]>
Sent: Thursday, October 31, 2019 9:58 AM

On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
https://tools.ietf.org/html/draft-iab-path-signals-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dpath-2Dsignals-2D03&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=bqfwnQ_X0sS2s_-ECuNdlHuwGgGS1ExL0htjWFkdcmA&s=n0t-4YZjV8NbJEQGurqtHwTmD1WjZbvGY_rqh6eYGNE&e=> 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

---

From: David Schinazi <[email-masked]>
Date: Thu, 31 Oct 2019 13:54:29 -0700

I support the chair's proposed response.

If 3GPP wants to use QUIC for their own use-case, that sounds great. But at
this point in time the QUIC WG should be focusing on delivering
HTTP/3+QUICv1, not gathering more requirements, and not documenting best
practices for these other use-cases. It's possible that TCP is a better fit
than QUICv1 for the 3GPP's use-case, but it's not the responsibility of the
QUIC WG to figure out whether that is the case.

David

On Thu, Oct 31, 2019 at 11:14 AM Lubashev, Igor <[email-masked]> wrote:

> RFC 8558 is very relevant.  It says, in Recommendations, that implicit
> signals should be replaced by explicit signals when originators wish to
> provide them to network elements on the path.
>
>
>
> Since QUIC is removing implicit signals, I read the question from 3GPP to
> mean “what are you replacing them with [for originators who wish to provide
> them]?”.  QUIC WG response reads as: “nothing, short of attaching
> encryption keys to packets”.  Even if QUIC v1 today can offer no
> replacement for the removed signal, QUIC WG should make an effort to at
> least suggest a practical way to satisfy RFC 8558’s recommendation of an
> explicit signal “for those who want it”.  Maybe point to some other
> specific layer where the WG believes the signal belongs (and can be
> deployed relatively quickly)?
>
>
>
>
>
> As for the content of the reply, it includes “The impact upon network
> operators was discussed extensively as part of that decision.”  Were
> network operators a part of those discussions, and what was their feedback?
>
>
>
>    - Igor
>
>
>
>
>
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Thursday, October 31, 2019 9:58 AM
>
> https://tools.ietf.org/html/draft-iab-path-signals-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dpath-2Dsignals-2D03&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=bqfwnQ_X0sS2s_-ECuNdlHuwGgGS1ExL0htjWFkdcmA&s=n0t-4YZjV8NbJEQGurqtHwTmD1WjZbvGY_rqh6eYGNE&e=>
> seems like it might be a helpful supporting document.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 01 Nov 2019 09:08:10 +1100

> would be best to use that.

Oh.  The tools link doesn't show that 8558 replaces the iab draft.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Oct 2019 22:56:43 +0000

Maybe we should suggest that they write an I-D for what they think their requirements are?