RACING between QUIC and TCP
226 views
Skip to first unread message
ctrlCV coder
May 5, 2022, 11:51:35 PM5/5/22
to QUIC Prototype Protocol Discussion group
hi guys,
BTW, I'm interested in the details about the implementation, can you please guide me where can I find the code about that?
I tried to send request with Quic, and added the host as QuicHint in purpose of sending the request in Quic manner for the first time. However I found that whether Quic or HTTP/2 was random.
After investigating with Wireshark, I noticed that both Quic packet and TCP packet were sent at the same time, and it seems that TCP connection established first. Is this the reason why the request was sent in HTTP/2? Or will it be sent in Quic if the Quic connection established first?
After investigating with Wireshark, I noticed that both Quic packet and TCP packet were sent at the same time, and it seems that TCP connection established first. Is this the reason why the request was sent in HTTP/2? Or will it be sent in Quic if the Quic connection established first?
BTW, I'm interested in the details about the implementation, can you please guide me where can I find the code about that?
Thank you!
Fan Yang
May 6, 2022, 8:20:45 AM5/6/22
to proto...@chromium.org
Correct. If the QUIC connection established first, the request will be sent on the QUIC connection.
More information can be found in QUIC discovery doc. Given you added the host via AddQuicHint, so the discovery part is bypassed.
The chromium code can be found in HttpStreamJobController. In particular, both TCP and QUIC jobs get started, and the TCP job gets delayed. The delay time is determined here. In your case, the delay time is likely 0 given QUIC is not known to work on the current network.
Hope this helps, Fan
--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/65935c18-7039-42c8-b917-2cb6ff307663n%40chromium.org.
ctrlCV coder
May 8, 2022, 9:41:03 PM5/8/22
to QUIC Prototype Protocol Discussion group, fay...@chromium.org
I understood! Thank you for your detailed guidance!
Fan Yang
May 9, 2022, 11:16:54 AM5/9/22
to ctrlCV coder, QUIC Prototype Protocol Discussion group
You are very welcome.
It would be interesting to understand those scenarios where QUIC loses the race to TCP, given TCP connection needs at least 2 RTTs (TCP + TLS) while QUIC only needs 1.
In the attached snapshot, it looks like the RTT is ~70ms, and the QUIC CHLO with packet number 1 is likely lost.
ctrlCV coder
May 10, 2022, 5:59:55 AM5/10/22
to QUIC Prototype Protocol Discussion group, fay...@chromium.org, QUIC Prototype Protocol Discussion group, ctrlCV coder
Yes I noticed that there were two CHLO with packet number 1 and 3, is the second one retrying for the first one please? Can you please let me know where to put a breakpoint to learn more details about the retrying, as I'm wondering if it possible to optimise this issue.
Thank you!
Fan Yang
May 10, 2022, 6:40:17 AM5/10/22
to ctrlCV coder, QUIC Prototype Protocol Discussion group
Yes, packet 3 is the retransmission of packet 1.
More information about loss detection and recovery can be found in RFC9002, and the implementation lives in quic_sent_packet_manager.
ctrlCV coder
May 10, 2022, 8:46:10 AM5/10/22
to QUIC Prototype Protocol Discussion group, fay...@chromium.org, QUIC Prototype Protocol Discussion group, ctrlCV coder
Thank you so much!
Reply all
Reply to author
Forward
0 new messages