QUIC Latest Version

[Yufeng Duan]

Hello,

I am testing the latest version toy quic client. I used tcpdump to capture the packets at the client side. The public flag field in the Client Inchoate Hello message is 0x09 which I suppose implies a Connection ID of 4 bytes. In fact, however, the CID here is 8 bytes as I found there are 8 bytes between the public flag and the version field. By the way, the version also changed to Q033. I just wonder if the definition in the public flag or something else has changed in the protocol?

Best,
Yufeng

[Ryan Hamilton]

Howdy,

Indeed, with QUIC v33, we've changed the public flags. You can look at quic_protocol.h for a full description, or see the updated public wire spec. With QUIC v33, 0x09 would suggest an 8 byte connection id + the version, which is what you see. Annoyingly, we hit some obstacles in rolling this out, which necessitated clients need to send 0x0D (The old 8 byte connection ID flags) in order to work around some middle box bugs. I think this code is not yet in Chrome, but will be there soon. However, we'll be removing it as soon as possible.

Cheers,

Ryan 

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

[Alexis La Goutte]

On Thu, Apr 28, 2016 at 7:27 PM, Ryan Hamilton <r...@chromium.org> wrote:

Howdy,

Indeed, with QUIC v33, we've changed the public flags. You can look at quic_protocol.h for a full description, or see the updated public wire spec. With QUIC v33, 0x09 would suggest an 8 byte connection id + the version, which is what you see. Annoyingly, we hit some obstacles in rolling this out, which necessitated clients need to send 0x0D (The old 8 byte connection ID flags) in order to work around some middle box bugs. I think this code is not yet in Chrome, but will be there soon. However, we'll be removing it as soon as possible.

Hi Ryan,

Thanks for information but the Wireshark dissector is broken too :-(

and Version information is after CID and public flags.

It is no possible to kept the same framing ? and use last reserved field (like 0x80)? for the new 32 byte diversification nonce

Cheers

[Ryan Hamilton]

On Thu, Apr 28, 2016 at 11:01 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Hi Ryan,

Thanks for information but the Wireshark dissector is broken too :-(

Alas, QUIC is currently still changing rapidly.​ And tools will need to be updated as the underlying protocol changes. For example, QUIC 34 is coming soon which changes the internals of the ACK frame and removes the private flags byte. The downside of this churn is that tools need to be updated, which has non-trivial cost. The upside is that we're able to experiment with the protocol and evolve it rapidl.

 

and Version information is after CID and public flags.

​As far as I know, the location of the version has not change as part of QUIC 33. Does it appear to have moved?

 

It is no possible to kept the same framing ? and use last reserved field (like 0x80)? for the new 32 byte diversification nonce

​It's *possible* but undesirable. We are reserving that bit to indicate that the public flags are more than a single byte long, for future changes to the protocol.

Cheers,

Ryan​

[Ian Swett]

If it's helpful for wireshark, no 2 or 4 byte connection ids were never sent to our our knowledge, only 0 and 8 bytes were used before, so it should be possible to know the connection id length without depending on the version by only looking at 1 bit and ignoring the other for the time being.

But yes, it does require a change, unfortunately.

[Alexis La Goutte]

On Thu, Apr 28, 2016 at 8:40 PM, 'Ian Swett' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hi Ian,

If it's helpful for wireshark, no 2 or 4 byte connection ids were never sent to our our knowledge, only 0 and 8 bytes were used before, so it should be possible to know the connection id length without depending on the version by only looking at 1 bit and ignoring the other for the time being.

 Thanks for this information, it will be more easy to make a "Hack" and continue to support older release :-)

[Alexis La Goutte]

On Thu, Apr 28, 2016 at 8:37 PM, Ryan Hamilton <r...@chromium.org> wrote:

On Thu, Apr 28, 2016 at 11:01 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Hi Ryan,

Thanks for information but the Wireshark dissector is broken too :-(

Alas, QUIC is currently still changing rapidly.​ And tools will need to be updated as the underlying protocol changes. For example, QUIC 34 is coming soon which changes the internals of the ACK frame and removes the private flags byte. The downside of this churn is that tools need to be updated, which has non-trivial cost. The upside is that we're able to experiment with the protocol and evolve it rapidl.

Ok,

It is possible to send a message when there is a new release ? with a QUIC(K) list of change ?
 

 

and Version information is after CID and public flags.

​As far as I know, the location of the version has not change as part of QUIC 33. Does it appear to have moved?

No really move but with the variable length of CID...

 

It is no possible to kept the same framing ? and use last reserved field (like 0x80)? for the new 32 byte diversification nonce

​It's *possible* but undesirable. We are reserving that bit to indicate that the public flags are more than a single byte long, for future changes to the protocol.

Cheers,

Ryan​

[Robbie Shade]

On Thu, Apr 28, 2016 at 3:00 PM, Alexis La Goutte <alexis....@gmail.com> wrote:

It is possible to send a message when there is a new release ? with a QUIC(K) list of change ?

This is a good idea, and we'll try to send a message to this list whenever a new version is released in the future. Thanks!

[Alexis La Goutte]

Hi,

For information i have push a small fix to add dissection of Q033 with Wireshark (Master) : https://code.wireshark.org/review/#/c/15164/

I have plan a serie of other patch to add support of new stuff (change with Q033, new error message...)

Also for QUIC team, what it is the last "QUIC packet" ? because it is no a public reset flag and with wireshark, we see a error message...

No found a spec (draft or Wire Spec), this type of packet...

Cheers

[Ryan Hamilton]

On Thu, May 5, 2016 at 8:08 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Also for QUIC team, what it is the last "QUIC packet" ? because it is no a public reset flag and with wireshark, we see a error message...

No found a spec (draft or Wire Spec), this type of packet...

​I don't understand the question. When you say "last", what are you referring to?​

[Alexis La Goutte]

Hi Ryan,

From the first message with pcap sample, there is packet :

0000   09 fa de b0 e5 57 e6 92 a0 51 30 33 33 06 80 87
0010   0f e6 2e 6f bc a6 1f 2a 57 ee 01 40 00 00 ff ff
0020   00 06 00 05 02 19 00 00 00 1b 00 4e 6f 20 72 65
0030   63 65 6e 74 20 6e 65 74 77 6f 72 6b 20 61 63 74
0040   69 76 69 74 79 2e

[Ryan Hamilton]

Dumping that packet, I see:

Header: { connection_id: 11570563657858342650, connection_id_length: 8, packet_number_length: 1, multipath_flag: 0, reset_flag: 0, version_flag: 1, version: 33, fec_flag: 0, entropy_flag: 0, entropy hash: 0, path_id: 0, packet_number: 6, is_in_fec_group: 0, fec_group: 0 }

AckFrame: { entropy_hash: 0, largest_observed: 0, ack_delay_time: 9223372036854775807, packets: [  ], is_truncated: 0, received_packets: [  ] }

StopWaitingFrame: { entropy_hash: 0, least_unacked: 1 }

ConnectionCloseFrame: { error_code: 25, error_details: 'No recent network activity.' }

[Alexis La Goutte]

Hi Ryan,

Thanks for dump, it will be supported by Wireshark soon (i have fixed some typo and other stuff)

Also, what the better documentation ? Draft or Wire Layout Specification ?

the sequence number is now packet number ? because there is always some typo on some document...

Do you known also how to generate special packet (how do you have same pcap) like Version Negotiation or Public Reset

Cheers,

[Ryan Hamilton]

On Mon, May 9, 2016 at 8:11 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Hi Ryan,

Thanks for dump, it will be supported by Wireshark soon (i have fixed some typo and other stuff)

​Awesome.​

 

Also, what the better documentation ? Draft or Wire Layout Specification ?

​The IETF draft is auto-generated from the Wire Spec google doc, so I would recommend that.

​

 

the sequence number is now packet number ? because there is always some typo on some document...

​Yes, that's a fairly recent terminology change. If you point to the typos, we can fix them.

​

 

Do you known also how to generate special packet (how do you have same pcap) like Version Negotiation or Public Reset 

​One good place to look would be in the tests for the QuicFramer. We have one for Public Reset Packets and one for Version Negotiation Packets.​

Hope that helps!

[Alexis La Goutte]

On Mon, May 9, 2016 at 7:04 PM, Ryan Hamilton <r...@chromium.org> wrote:

On Mon, May 9, 2016 at 8:11 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Hi Ryan,

Thanks for dump, it will be supported by Wireshark soon (i have fixed some typo and other stuff)

​Awesome.​

 

Thanks to you for the help :)

Also, what the better documentation ? Draft or Wire Layout Specification ?

​The IETF draft is auto-generated from the Wire Spec google doc, so I would recommend that.

Thanks
 

​

 

the sequence number is now packet number ? because there is always some typo on some document...

​Yes, that's a fairly recent terminology change. If you point to the typos, we can fix them.

Ok, it will send the typo found

​

 

Do you known also how to generate special packet (how do you have same pcap) like Version Negotiation or Public Reset 

​One good place to look would be in the tests for the QuicFramer. We have one for Public Reset Packets and one for Version Negotiation Packets.​

Ok thanks,

The QuicFramer test send traffic ? how to launch ?
 

Hope that helps!

[Ryan Hamilton]

On Mon, May 9, 2016 at 10:19 AM, Alexis La Goutte <alexis....@gmail.com> wrote:

Do you known also how to generate special packet (how do you have same pcap) like Version Negotiation or Public Reset 

​One good place to look would be in the tests for the QuicFramer. We have one for Public Reset Packets and one for Version Negotiation Packets.​

Ok thanks,

The QuicFramer test send traffic ? how to launch ?

​Sorry, no. But that test should contain hex dumps of those packets, which hopefully might be able to suit your needs.

​