GQUIC -> QUIC migration

[martinthomson]

From @martinduke in quicwg/base-drafts#1006:

We're pretty close to settling on a wire image, I think. It would be useful for the transport draft (and eventually the RFC) to have an appendix covering issues with simultaneous support of GQUIC versions and QUIC v1.

I believe all the entities actually trying to support GQUIC are heavily involved in the working group. However, I imagine there are quite a lot of middleboxes out there doing some basic ID/classification (if not more) on GQUIC today, and will need some guide on how to simultaneously handle two packet header formats, etc.

If people are opposed to an appendix, I suppose a short-lived internet draft would also get the job done. In any case, I'd like to see a placeholder sooner rather than later.

[mirjak]

Is this related to issue #25 or can both things be addressed in the same section?

[ianswett]

I'm not clear what the goal here is. A this point, gQUIC is on the verge of being deprecated. I would not want to encourage anyone who doesn't already support both IETF QUIC and gQUIC to add support for gQUIC. Adding text about this might make people think this is desirable, which it definitely is not.

[mirjak]

Rereading @martinduke original comment, I guess this was more about handling of different versions in the network and therefore should go into the manageability draft, if at all. Would it make sense to say something more general about handling of different versions (and just take gQUIC as the deployed example)...? Not sure what though...

[ianswett]

Well, if things like the spin bit are adopted, then a future version could drop support for it? I'm not sure what else is worth saying?

[martinthomson]

Do we already have this in the new version upgrade text?

[mirjak]

I guess we don't have anything in the manageability draft though...

[britram]

@ianswett Given the current state of GQUIC/QUIC deployment and transition, is this still relevant or OBE for -manageability?

[ianswett]

By the time the RFC is shipped, it's almost certain any text about this will be obsolete.

Most GQUIC traffic is already using the invariant header and draft 20 long packet types, so it should already look very similar to IETF QUIC from a middlebox perspective.

[dtikhonov]

Most GQUIC traffic is already using the invariant header and draft 20 long packet types

Is that so? Chrome Stable (as of 75.0.3770.100) uses Q043, which has the "classic" GQUIC headers.

[ianswett]

A small fraction of users in Chrome are still on v43(or even TCP) as a holdback, but the majority of users should be on v46, and v46 is default enabled in the code itself, but probably not until m76.

[dtikhonov]

I see what happened: my "enable QUIC" flag was "Yes." Switching it to "Default" made Chrome use Q046. I stand corrected.

[ianswett]

Yes, that's an unfortunate consequence of forcing it on at the moment. There may be a way to ensure that flag does what you'd expect(ie: enable v46).

…

On Tue, Jul 2, 2019 at 8:06 PM Dmitri Tikhonov ***@***.***> wrote: I see what happened: my "enable QUIC" flag was "Yes." Switching it to "Default" made Chrome use Q046. I stand corrected. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AEZES4K3JZH3JTWMVJW7TMLP5PUQPA5CNFSM4EMWYS42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZC4EBQ#issuecomment-507888134>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEZES4LBXSAIAIBQMVLFWN3P5PUQPANCNFSM4EMWYS4Q> .

[mirjak]

I think we can close this specific issue. However, is there any general guidance that could/should be given when supporting multiple versions/transitioning to a new version?

[mirjak]

Actually we already have a section on "Enabling New Versions". If you think anything is still missing there please provide an PR. Other than that I will close the issue now.