QUIC Version 44 and IETF QUIC

[Ian Swett]

Though IETF QUIC is not yet complete, the Google QUIC team has started the transition to IETF QUIC.  QUIC version 44 is the first version of Google QUIC to incorporate all changes described in the Invariants draft that was extensively discussed at IETF 101 in London.  This version is now in now enabled in a small experiment in Chrome Canary and the intent is to roll it out as quickly as possible. 

Because IETF QUIC, and therefore GQUIC version 44, changes the public header including the first byte of the packet, we’ll be watching closely to ensure there are no user-visible issues caused by the header changes.  If you are a middlebox vendor that does QUIC classification, or are a customer of middleboxes that do QUIC classification, please test with version 44 now to ensure any issues can be fixed before it reaches Chrome Stable.

Version 44 can be manually enabled in the newest Canary and Dev with:

--quic-version=QUIC_VERSION_44

Chrome also has all the variable length integer frames implemented behind a never-to-be-deployed QUIC version 99.  Changes from Version 99 will be moved into 45, 46, etc as quickly as is practical, though the initial focus is on moving to the invariants header, because subsequent changes will be almost entirely within the encryption envelope.

Subsequent versions will include coalesced packets and packet number encryption, though the timeframe is not yet clear.

The first deployed version of Google QUIC with TLS1.3 will implement the QUIC Record Layer that was agreed to at the Krista interim. We had previously planned on deploying an implementation based on the previous Stream0 design, but see little value in that at this time.

Thanks, Ian

[Lars Eggert]

Hi,

On Tuesday, August 21, 2018 at 9:51:58 PM UTC+2, Ian Swett wrote:

Though IETF QUIC is not yet complete, the Google QUIC team has started the transition to IETF QUIC.  QUIC version 44 is the first version of Google QUIC to incorporate all changes described in the Invariants draft that was extensively discussed at IETF 101 in London.  This version is now in now enabled in a small experiment in Chrome Canary and the intent is to roll it out as quickly as possible. 

it's great to hear that Google remains committed to pivoting to the upcoming open standard for QUIC - thanks, guys! We all understand this is way more difficult for you than for anyone who can simply start fresh.

Lars 

[Ian Swett]

Thanks Lars.

Version 44 is now enabled for the majority of Chrome Canary and Dev users, or will be upon restart.

As I mentioned above, if anyone is aware of middleboxes that may need to update their QUIC identification algorithms, please ask them to test with Chrome Canary or Dev.  They should also feel free to contact me directly and/or consult the QUIC Invariants IETF draft about the format of the QUIC public header.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[王明明]

1. I want to know what is the difference between IETF QUIC (Http/3) and Google QUIC.  

2. Why not formulate just one standard. 

3. And I know Apple has prepared to support quic, but which one will apple support, GQUIC or HTTP/3?

在 2018年9月14日星期五 UTC+8上午3:57:38，Ian Swett写道：

[Ryan Hamilton]

I believe we have previously stated that working to converge Google QUIC to IETF QUIC (aka, HTTP/3). IETF QUIC is evolving, and Google QUIC is evolving. Eventually Google QUIC v?? will be identical to IETF QUIC, but we're not there yet. 

In any case, there is not a comprehensive list of differences between Google QUIC v44 and IETF QUIC, but it'd be an extensive list :)

[王明明]

Thanks a lot!!!

在 2018年11月24日星期六 UTC+8上午1:19:15，r...@chromium.org写道：

[chuck crisler]

Was something significant changed in youtube recently? I test with a page for chrome://net-internals/#quic open to monitor the flows and streams created. There were always 1 or more XYZ.googlevideo.com flows created for the video flows, but that seemed to stop 2-3 weeks ago. Now, none of the flows reports carrying many packets, certainly not enough for video. Did I miss something?

Thank you!

Chuck Crisler

[Ian Swett]

There are no changes in YouTube's QUIC support I'm aware of, and I just checked and it works for me.

I believe chrome://net-internals is being deprecated in favor for chrome://net-export fairly soon, FWIW.

[Slava Shebanov]

Hi, 

I want to experiment with QUIC using Cronet library for android. The information I cannot find anywhere: does cronet support IETF QUIC or only gQUIC? Or it supports both already? As I understand cronet is just Chrome network library and its support of IETF QUIC/gQUIC versions should be aligned with Chrome support?

[Ian Swett]

It currently supports gQUIC.  Most of the changes necessary to support IETF QUIC have been committed and are in version 99.  However, version 99 is constantly changing as it catches up with IETF QUIC(which is also constantly changing), so it's not suitable for deployment.

[Slava Shebanov]

Thank your for quick response! Helped me a lot.

[Stanislav Slusny]

Hi Ian,

do you plan to participate at IETFQUIC interop meetings with Chrome (and version 99) ?

Thanks,

Stanislav 

[Ian Swett]

Yes, we worked on interop in Tokyo last week, but didn't quite get there.  Once header protection and multiple packet number spaces are in, we'll be in a much better place.  Both are in progress, and are necessary for any real interop.

[Александр Сорокин]

Hi. We are trying to connect to gQUIC server via Cronet, but we always receive "connection_refused" / "quic_connection_migration_handshake_unconfirmed".

One of our thoughts is that version are incompatible. However, I cannot find a place where Cronet quic's version is described.

Library version is 72.3626.96.

Is there any public information about it?

вторник, 21 августа 2018 г., 22:51:58 UTC+3 пользователь Ian Swett написал:

[sunny ruan]

Does GQUIC version 44 begin support Destination connection ID and Source connection ID ? version 43 and below support single connection ID?

在 2018年8月22日星期三 UTC+8上午3:51:58，Ian Swett写道：

[Ian Swett]

v44 uses the IETF long header framing with a separate destination and source CID, but always uses a 0 byte CID from server to client and 8 bytes from client to server.  An upcoming version will move to two completely independent CIDs, but that code is not quite complete yet.

[sunny ruan]

  thank you! lan

  Is there any other difference between Q39 and Q44?

在 2019年2月27日星期三 UTC+8下午9:50:47，Ian Swett写道：

[puneet kumar]

Hi Ian,

What is the latest version of QUIC Congestion control IETF? Is there any link to RFC, I can refer to?

[sunny ruan]

  hi, lan

  Does Q44 use TLS 1.3?

在 2018年8月22日星期三 UTC+8上午3:51:58，Ian Swett写道：

Though IETF QUIC is not yet complete, the Google QUIC team has started the transition to IETF QUIC.  QUIC version 44 is the first version of Google QUIC to incorporate all changes described in the Invariants draft that was extensively discussed at IETF 101 in London.  This version is now in now enabled in a small experiment in Chrome Canary and the intent is to roll it out as quickly as possible. 

[Nick Harper]

No, Q044 does not use TLS 1.3.

[sunny ruan]

hello lan,

How to use QUIC without HTTP/SPDY semantics? As far as I know , cronet and proto-quic  both use http/spdy.

在 2018年8月22日星期三 UTC+8上午3:51:58，Ian Swett写道：

Though IETF QUIC is not yet complete, the Google QUIC team has started the transition to IETF QUIC.  QUIC version 44 is the first version of Google QUIC to incorporate all changes described in the Invariants draft that was extensively discussed at IETF 101 in London.  This version is now in now enabled in a small experiment in Chrome Canary and the intent is to roll it out as quickly as possible. 

[Ian Swett]

You can extend QuicSession and QuicStream.  Quartc is an example of a non-HTTP application.

[sunny ruan]

 Thanks, lan

 This is very helpful to me.

在 2019年3月6日星期三 UTC+8上午9:46:27，Ian Swett写道：

[Lan Pishu]

 hi,lan,we are planning to remove all the irrelevant dependencies of Quartc,is the 'gn + ninja' build system  enough to make it possible? Not very familiar with these tools.

在 2019年3月6日星期三 UTC+8上午9:46:27，Ian Swett写道：

You can extend QuicSession and QuicStream.  Quartc is an example of a non-HTTP application.

[Ian Swett]

I believe removing the dependencies of quartc should be straightforward.  It's designed to depend on the core QUIC code, but not vice versa.

On Wed, Mar 6, 2019 at 3:55 AM Lan Pishu <lanpis...@gmail.com> wrote:

 hi,lan,we are planning to remove all the irrelevant dependencies of Quartc,is the 'gn + ninja' build system  enough to make it possible? Not very familiar with this tools.

[Ian Swett]

On Thu, Mar 7, 2019 at 8:17 AM sunny ruan <sunny...@gmail.com> wrote:

  Hi, lan

   I have saw the Quatrc, and have some questions:

     1.what's the relationship between quartc and webRTC?

Quartc is a way to map most(or maybe all?) of WebRTC onto QUIC. 

     2.Does quic have an advantage over 5G network?

I have no idea, I've never been able to test on a 5G network.  Possibly connection migration could be an advantage, because my understanding is that 5g coverage will be more localized and there may be more 5G -> other network transitions?

在 2019年3月6日星期三 UTC+8下午7:25:18，Ian Swett写道：