QUIC 0-rtt and 2-rtt connection

[Prasenjeet Biswal]

Is there a way to check both the 0-rtt and 2-rtt connection establishment using the QUIC toy server and google chrome client?

--
Prasenjeet Biswal

[Romain Jacotin]

Wireshark can decode only the public header of QUIC packet. But it is easy to see the first crypto handshake message (QUIC sequence number 1 + CHLO message and tags in clear text without ciphering)

KR,

Romain

[Ryan Hamilton]

When you say, "check" do you mean that you'd like to see how many packets were exchanged? I don't think the toy client saves the server config in any way that would permit it to do a 0-RTT connect, but it would be pretty easy to wire something up, if someone were so inclined!

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

[Prasenjeet Biswal]

Thanks Ryan and Romain.

Actually I am using chromium browser as client and want to see the time difference when the chromium browser client does both 0-rtt and 2-rtt connection establishment.

Is this experiment possible to do with toy quic server? As I see in the server log this is the sequence of events.

1. Client sends Chlo
2. Server rejects.

------1 rtt------------

3. Client sends Chlo again.
4.Server sends Shlo.

-----2-rtt------

Client sends request.

This uses 2 RTT for connection establishment. Is it possible to do a 0-rtt connection establishment?

Also I could not see the FEC flag set to 1 even in very lossy environment (70%).

1. Is the Forward Error Connection used in toy server?

2. Is the forward error connection used in google public server using quic?

Thanks
Prasenjeet Biswal

[Ryan Hamilton]

On Tue, Apr 21, 2015 at 4:33 PM, Prasenjeet Biswal <bprasen...@gmail.com> wrote:

Thanks Ryan and Romain.

Actually I am using chromium browser as client and want to see the time difference when the chromium browser client does both 0-rtt and 2-rtt connection establishment.

Is this experiment possible to do with toy quic server? As I see in the server log this is the sequence of events.

1. Client sends Chlo
2. Server rejects.

------1 rtt------------

3. Client sends Chlo again.
4.Server sends Shlo.

-----2-rtt------

Client sends request.

This uses 2 RTT for connection establishment. Is it possible to do a 0-rtt connection establishment?

​I believe that if you keep Chrome running and wait 30 seconds for that connection to time out, you can make another request which will be a 0-RTT connection.​

Also I could not see the FEC flag set to 1 even in very lossy environment (70%).

​FEC is not currently enabled in Chrome. We are still experimenting with the best configurations to take advantage of FEC.

Cheers,

Ryan

[Prasenjeet Biswal]

I could not see the 0-rtt connection on the toy quic server log files using chrome as client.I requested a page on chrome from the toy server and then after connection timed out, asked the page again.It still did a 2-rtt connect.

I am attaching the server log file where we can see two pairs of (CHLO,REJ,CHLO,SHLO). Can you confirm if I am doing the exercise correctly? Also can you confirm if the public google servers use 0-rtt facility of QUIC.

Since FEC is not enabled as mentioned, does that mean QUIC currently uses congestion avoidance + packet-pacing ?

Thanks

Prasenjeet Biswal

[Romain Jacotin]

Hi Prasenjeet,

I am definitely NOT a QUIC expert but your log seem to say that the first REJ from the server was because of an invalid server config in CHLO ( bad SCID ? ).

And the later REJ was because the "Client nonce's timestamp is not in the strike register's valid time range".

My only two cents ...

Romain

[Fatima Zarinni]

Hi All,

I am also experimenting with the Quic toy server, and I am also observing that the 0-RTT feature for Quic is not triggered. 

I tried accessing a test webpage again from chrome, after the previous session timed out, however, I can see that CHLO, REJ, CHLO and SHLO are all exchanged again before the actual data packet is received and decrypted at the server. 

I am attaching the server log for the case where I again accessed the test webpage. One thing I noticed is that there is an error message after sending REJ:

[0506/095551:WARNING:quic_framer.cc(1703)] DecryptPacket failed for sequence_number:2

[0506/095551:VERBOSE1:quic_framer.cc(2218)] Error: QUIC_DECRYPTION_FAILURE detail: Unable to decrypt payload.

I have repeated the experiment with the latest stable chrome for both Android and Ubuntu (Q024), as well as, with the unstable Chrome Dev (Quic025) on Ubuntu. I saw a similar problem in all cases.  

I was wondering if this is a bug or if the 0-RTT feature is just not enabled in the chrome browser?  I would appreciate any feedback. 

Thank you,

Fatima

[Prasenjeet Biswal]

Hi Fatima

I experienced a similar problem.One workaround is you do not consider the first results and successively ask for the resources again before the connection is removed from the time-wait list(~20 - 25 sec.).This can emulate a 0-rtt connection.

I checked it with quic_client and server logs still show REJ packets, so I think it may not be a problem of chrome.Also as Romain mentioned my log showed bad SCID(this always happens in first connection) and Client's nonce expired(if you ask for load the page after previous connection is removed from time-wait list ).

Thanks

Prasenjeet Biswal

[Ryan Hamilton]

0-RTT is definitely enabled in Chrome. You can verify this by looking at QUIC connections to Google hosts. When connection to the toy server, you will see that the first time Chrome makes a QUIC connection, it sends an "inchoate" (non-0-RTT) CHLO:

t= 2338 [st=    0]    QUIC_SESSION_CRYPTO_HANDSHAKE_MESSAGE_SENT
                      --> CHLO<
                            SNI : "www.example.com"
                            VER : 'Q025'
                            CCS : 0x7B26E9E7E45C71FF
                            UAID: "canary Chrome/44.0.2394.0"
                          >

On a subsequent connection, Chrome will send a "full" (potentially 0-RTT) CHLO:

t=30790 [st=    1]    QUIC_SESSION_CRYPTO_HANDSHAKE_MESSAGE_SENT
                      --> CHLO<
                            SNI : "www.example.com"
                            STK : 0xEDC464FDE30ACF0B69A9EEB20C4668BCF216898CF2D77EF210F8C909F8DE8BEE9B5D242E7B22AB50A5E4DB4DF57F8AB8C98D
                            VER : 'Q025'
                            CCS : 0x7B26E9E7E45C71FF
                            NONC: 0x554B75321467975826143E1715A7EB5A8DC721AF81D3FF412B0F52BD789F0646
                            MSPC: 100
                            AEAD: 'AESG'
                            UAID: "canary Chrome/44.0.2394.0"
                            SCID: 0x87D67C95A6DA1C764C8135BB844B457F
                            TCID: 0x00000000
                            SRBF: 262144
                            ICSL: 30
                            PUBS: 0xA6A4320D5E6C86D59A9AD2B8993754FFD0F7DF2E2EF1167E773C6ECAA82F0641
                            SCLS: 0x01000000
                            KEXS: 'C255'
                            COPT: 
                            IRTT: 17736
                            CFCW: 10485760
                            SFCW: 10485760
                          >

However, I do see the same behavior that the toy server replies to the full CHLO with a REJ. 

t=30795 [st=    6]    QUIC_SESSION_CRYPTO_HANDSHAKE_MESSAGE_RECEIVED
                      --> REJ <
                            STK : 0xA15F874305A6E873A453966503BC73A74A75AA55FF64D76617641A4E94749E8387F795E021BC6BB6CCBFBFA4597AC634513C79CA
                            SNO : 0xF1AEFEF6184EF3874D06E62F8189A6E61FF728FE54EF638977FFD02322F3B2CDFD49FF43F463E015FBB1CFCF585294D8
                            SCFG: 
                              SCFG<
                                AEAD: 'AESG','CC12'
                                SCID: 0x87D67C95A6DA1C764C8135BB844B457F
                                PUBS: 0x200000C48F7637F9313E9B33BB32F50F0E87A3F7EEF224FF3DB8873CA2F54463139C54
                                KEXS: 'C255'
                                OBIT: 0x1467975826143E17
                                EXPY: 0x10C3385600000000
                              >
                            RREJ: 0x05000000
                          >

Looking at the RREJ (which is the reject reason), we see that it corresponds to:

  // Client nonce's timestamp is not in the strike register's valid time range.

  CLIENT_NONCE_INVALID_TIME_FAILURE = 5,

Looks like we should probably tweak the toy server so that it avoids the startup period. I'll look into the best way to do this.

In the meantime, you can apply this patch:

diff --git a/net/quic/crypto/quic_crypto_server_config.cc b/net/quic/crypto/quic_crypto_server_config.cc

index 5391673..20fc00d 100644

--- a/net/quic/crypto/quic_crypto_server_config.cc

+++ b/net/quic/crypto/quic_crypto_server_config.cc

@@ -221,7 +221,7 @@ QuicCryptoServerConfig::QuicCryptoServerConfig(

       primary_config_(nullptr),

       next_config_promotion_time_(QuicWallTime::Zero()),

       server_nonce_strike_register_lock_(),

-      strike_register_no_startup_period_(false),

+      strike_register_no_startup_period_(true),

       strike_register_max_entries_(1 << 10),

       strike_register_window_secs_(600),

       source_address_token_future_secs_(3600),

Cheers,

Ryan

[Ryan Hamilton]

I've written https://codereview.chromium.org/1125313003/ which will disable the startup period for the toy server.  This should land later today...

[Fatima Zarinni]

Thank you Ryan for the detailed response and the patch! I appreciate it. I also tested against the Google severs and saw what you are seeing.

Also, Thanks Prasenjeet for your reply.

Best regards,

Fatima 

[Ryan Hamilton]

You're very welcome! By the way, that change I mentioned earlier has been submitted so if you re-sync and re-build you should see 0-RTT to the quic_server.

Cheers,

Ryan

[Fatima Zarinni]

Hi Ryan,

I noticed that the 0-RTT feature is still *not* triggered when we close the browser, reopen the browser and then again fetch a page from the same server. Similarly, if we close the tab and then reopen the tab and again fetch from the same server, we will again not observe the 0-RTT feature.

I was wondering if server related information stored at the client should persist if we reopen tabs or if we relaunch chrome ?

Also, the latest Android Chrome Dev still uses Quic version 25. However, it appears that now we we have Quic version 30. I was wondering if QUIC for android chrome is not updated, or is it just announcing a mismatched version.

Thank you,

Fatima

 

[Ryan Hamilton]

On Tue, Jan 19, 2016 at 8:24 PM, Fatima Zarinni <fatimah...@gmail.com> wrote:

Hi Ryan,

I noticed that the 0-RTT feature is still *not* triggered when we close the browser, reopen the browser and then again fetch a page from the same server.

Chrome does not do 0-RTT when the network changes, or when the browser starts, until it has verified that it can speak QUIC successfully, so this is expected.

 

Similarly, if we close the tab and then reopen the tab and again fetch from the same server, we will again not observe the 0-RTT feature.

​This is very surprising, because it should work just fine. Can you attach a net-internals log which demonstrates this behavior?

​

 

I was wondering if server related information stored at the client should persist if we reopen tabs or if we relaunch chrome ? 

​Yes, Chrome does persist this information (via the Chrome disk cache, and HttpServerProperties).​

 

Also, the latest Android Chrome Dev still uses Quic version 25. However, it appears that now we we have Quic version 30. I was wondering if QUIC for android chrome is not updated, or is it just announcing a mismatched version.

​All versions of Chrome are currently using QUIC 25.​

​Cheers,

Ryan​

[Fatima Zarinni]

Hi Ryan,

Thank you for your reply. I appreciate it.

I also reran my experiments to reconstruct the problem with closing/reopening tabs. However, I realized that you are right here, and 0-RTT *is* triggered.

There is something else that is happening where a new connection is created in the middle of a pageload, and not because a new tab is opened. I will send the net-internal logs to you in this regards. 

Thank you,

Fatima