Subject: resourceTiming.nextHopProtocol reports"hq" - is that ok?

From: Lucas Pardue <[email-masked]>
Date: Mon, 12 Mar 2018 23:37:02 +0000

Hi,

TL;DR is that I see Chrome 64+ report the ALPN ID "hq" when I retrieve protocol information in client-side JavaScript. Is this ok?

Background
========
I was playing around on my site https://quic.stream which talks GQUIC 39, advertised with the Alt-Svc ALPN ID "quic".

My website previously used chrome.loadTimes() to detect the protocol, however things have moved on and now Chrome suggests I use  resourceTiming.nextHopProtocol() instead . So I updated my client code and was surprised to see that it now reports that I am talking "hq", rather than the previous string "http2+quic/39".

I created a thread on Google's proto-quic group [1] but Ryan Hamilton and I seem to disagree. Our discussion suggests that draft-ietf-quic-http-10 is a bit ambiguous, section 2.1.1 and 2.2.1 seem to be at odds. Ryan also kindly pointed out a w3c issue that touched on this topic [2].

Section 2.2.1 says:

   Only implementations of the final, published RFC can identify
   themselves as "hq".  Until such an RFC exists, implementations MUST
   NOT identify themselves using this string.

   Implementations of draft versions of the protocol MUST add the string
   "-" and the corresponding draft number to the identifier.  For
   example, draft-ietf-quic-http-01 is identified using the string "hq-
   01".

(FWIW, In the wild I see lots of "hq" being advertised, which seems to break this rule. )

So, is it ok to report "hq" in this case?

In my opinion, it would be really helpful to expose more information than just "hq" to JavaScript. As Yoav points out on [2], reducing fidelity of this data makes my life as a site operator harder when trying to gather protocol-related metrics.

Kind regards
Lucas

[1] https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/L5LkAg8VGZM
[2] https://github.com/w3c/navigation-timing/issues/71

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 13 Mar 2018 00:26:26 +0000

Just for reference, here's 2.1.1:

   For example, suppose a server supported both version 0x00000001 and
   the version rendered in ASCII as "Q034".  If it opted to include the
   reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and
   0x1abadaba, it could specify the following header:

   Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0"

That suggests that if a server want to advertise HTTP over Google QUIC
Q034, it can use "hq" in the advertisement. Perhaps that's not the intent?

In any case, if we think that "hq" is the wrong identifier to be using in
the resource timing API, it would probably be a good idea for the WG to
clarify the issue with the w3c since I believe that's what drove the chrome
implementation.

Cheers,

Ryan

On Mon, Mar 12, 2018, 4:37 PM Lucas Pardue <[email-masked]> wrote:

> Hi,
>
>
> TL;DR is that I see Chrome 64+ report the ALPN ID "hq" when I retrieve
> protocol information in client-side JavaScript. Is this ok?
>
>
> Background
> ========
> I was playing around on my site https://quic.stream which talks GQUIC 39,
> advertised with the Alt-Svc ALPN ID "quic".
>
> My website previously used chrome.loadTimes() to detect the protocol,
> however things have moved on and now Chrome suggests I use
> resourceTiming.nextHopProtocol() instead . So I updated my client code and
> was surprised to see that it now reports that I am talking "hq", rather
> than the previous string "http2+quic/39".
>
> I created a thread on Google's proto-quic group [1] but Ryan Hamilton and
> I seem to disagree. Our discussion suggests that draft-ietf-quic-http-10 is
> a bit ambiguous, section 2.1.1 and 2.2.1 seem to be at odds. Ryan also
> kindly pointed out a w3c issue that touched on this topic [2].
>
> Section 2.2.1 says:
>
> In my opinion, it would be really helpful to expose more information than
> just "hq" to JavaScript. As Yoav points out on [2], reducing fidelity of
> this data makes my life as a site operator harder when trying to gather
> protocol-related metrics.
>
> Kind regards
> Lucas
>
> [1]
> https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/L5LkAg8VGZM

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 13 Mar 2018 14:46:35 +1300

> Q034, it can use "hq" in the advertisement. Perhaps that's not the intent?

The 2.2.1 clause "MUST NOT" and "MUST" about appending "-" and draft
number overrides all regular text, examples, and lesser requirements
within the Draft. When an RFC is published it should not contain those
MUST/MUST NOT and the "hq" ALPN becomes valid.

AFAIK it is done this way to avoid having to re-write many references to
things during the final stage of RFC publication.

That said, 2.1.1 is just an example. Examples are always trumped by
normative requirements.

> In any case, if we think that "hq" is the wrong identifier to be using
> in the resource timing API, it would probably be a good idea for the WG
> to clarify the issue with the w3c since I believe that's what drove the
> chrome implementation.

It is wrong since it violates the MUST/MUST NOT.

Compliant implementations for that document use the "hq-10" ALPN.
Anything using "hq" before the RFC is actually published is just forcing
the RFC editor and IANA to assign a different ALPN to avoid those broken
implementations when the final protocol is established.

AYJ

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 12 Mar 2018 20:56:30 -0700

> implementations when the final protocol is established.

​That makes sense, but I'm confused what the quic= parameter of the QUIC
Alt-Svc advertisement is intended to be used for then?​

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 13 Mar 2018 17:46:35 +1300

On 13/03/18 16:56, Ryan Hamilton wrote:
> 
> On Mon, Mar 12, 2018 at 6:46 PM, Amos Jeffries wrote:
> 

For informing the recipient of any additional versions of QUIC which the
sender supports. At present it could be referring to older Drafts which
are still supported (but not preferred), and after RFC publication to
different versions of the "hq" protocol (if any).

Amos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 08:05:37 +0000

> different versions of the "hq" protocol (if any).

Everything Amos said here.  Remember that there are two versions in
play here: QUIC and HTTP over QUIC.  And using "hq" camps on a value
we intend to use.  If Google are indeed using it, then it might
already be unrecoverable, but that depends on how thoroughly it can be
removed.

If this use of "hq" continues - even in part - then we'll have to pick
a different value for HTTP over QUIC.

The actual ALPN that Google QUIC uses is unlikely to matter in the
long term, but I would use hq-00, even if it has diverged from that
since the -00 drafts went out.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 13 Mar 2018 10:10:11 +0000

Martin Thomson wrote:

> Everything Amos said here.  Remember that there are two versions in play
> here: QUIC and HTTP over QUIC.  And using "hq" camps on a value we intend
> to use.  If Google are indeed using it, then it might already be unrecoverable,
> but that depends on how thoroughly it can be removed.
>
> If this use of "hq" continues - even in part - then we'll have to pick a different
> value for HTTP over QUIC.
>
> The actual ALPN that Google QUIC uses is unlikely to matter in the long term,
> but I would use hq-00, even if it has diverged from that since the -00 drafts
> went out.

Looking at my chrome://net-internals/#alt-svc, it presents a table of "accepted" QUIC adverts. Mine currently contains 64 entries, mostly google endpoints. A random sample of these shows most offer "hq".

Not sure if that is a case of the horse bolting.

Cheers
Lucas

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 14 Mar 2018 15:57:55 -0700

> since the -00 drafts went out.

​As discussed in-person, the current use of "hq" by Google shouldn't cause
long term harm because it's used in conjunction with a quic​= list that
only includes google QUIC versions.

That being said, I'm happy to change this. We've disabled the experiment in
Chrome which thinks in understands "hq" in an Alt-Svc advertisement and
we'll also disable the server-side announcement. In addition, I've updated
the w3c issue about nextHopProtocol
https://github.com/w3c/navigation-timing/issues/71 and have sent off a
Chrome code review
https://chromium-review.googlesource.com/c/chromium/src/+/963492 to change
the resource timings API output which kicked off this thread.

Cheers,

Ryan

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 15 Mar 2018 00:30:41 +0000

Ryan,

Thanks for being so responsive to this issue. Looking forward to testing some future version of Chrome.

Kind regards
Lucas
________________________________________
From: Ryan Hamilton [[email-masked]]
Sent: 14 March 2018 22:57
To: Martin Thomson
Cc: Amos Jeffries; HTTP Working Group
Subject: Re: resourceTiming.nextHopProtocol reports"hq" - is that ok?

On Tue, Mar 13, 2018 at 1:05 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

​As discussed in-person, the current use of "hq" by Google shouldn't cause long term harm because it's used in conjunction with a quic​= list that only includes google QUIC versions.

That being said, I'm happy to change this. We've disabled the experiment in Chrome which thinks in understands "hq" in an Alt-Svc advertisement and we'll also disable the server-side announcement. In addition, I've updated the w3c issue about nextHopProtocol https://github.com/w3c/navigation-timing/issues/71 and have sent off a Chrome code review https://chromium-review.googlesource.com/c/chromium/src/+/963492 to change the resource timings API output which kicked off this thread.

Cheers,

Ryan

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 15 Mar 2018 15:21:49 -0700

My pleasure! FWIW, the Chrome change has landed and should be live in the
next Chrome Canary release.

On Wed, Mar 14, 2018 at 5:30 PM, Lucas Pardue <[email-masked]>
wrote:

> That being said, I'm happy to change this. We've disabled the experiment
> in Chrome which thinks in understands "hq" in an Alt-Svc advertisement and
> the w3c issue about nextHopProtocol https://github.com/w3c/
> navigation-timing/issues/71 and have sent off a Chrome code review
> https://chromium-review.googlesource.com/c/chromium/src/+/963492 to
> change the resource timings API output which kicked off this thread.
>
> Cheers,
>
> Ryan
>
>