QUIC from youtube

[Chuck Crisler]

Sorry for the noise. I have been trying to test QUIC from youtube since late last week and receive TLS/TCP instead of QUIC. Has something changed with youtube?

[Ian Swett]

No, nothing has changed about the YouTube config.

What client are you using?

On Tue, Nov 2, 2021 at 8:44 AM Chuck Crisler <ccrisle...@gmail.com> wrote:

Sorry for the noise. I have been trying to test QUIC from youtube since late last week and receive TLS/TCP instead of QUIC. Has something changed with youtube?

--
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/6b630e84-1d6a-4223-a6e0-e5a8eb9ae687n%40chromium.org.

[Chuck Crisler]

Chrome 88.0.4324.182 This gave me QUIC last Thursday afternoon, but not since.

[Ian Swett]

M88 is fairly old, I'd suggest updating.

[Chuck Crisler]

Continuing saga. I work on a middleware box. I have upgraded to 95.0.4638.69 and am still seeing unexpected behavior. A given video will start out with IETF QUIC for several of the small flows. However, the primary video flows will be TLS/TCP. All of the flows follow the same networking path, at least from the client through my box. I realize that something in our box must be doing something to cause Chrome to fall back to TLS/TCP. Is there some logging that I can enable on Chrome to investigate what is going on?

[Bin Wu]

It'd be useful for debugging if you can reproduce the problem with a Chromium NetLog:

https://www.chromium.org/for-testers/providing-network-details

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/85d062a8-15f3-4906-88b1-ee5246282f54n%40chromium.org.

[Chuck Crisler]

Thank you, I will try that. However, I just found this timing info from a packet capture. Chrome started with a QUIC connection that took ~26.6 ms between the first Tx packet and the response. It then made a TCP connection that took 18 ms between the SYN and SYN ACK. There weren't any other QUIC connections started after that. Could that be the reason?

[Ian Swett]

I'm actually not sure why Chrome created a TCP connection in that particular case, so a netlog would be very useful to better understand what you're seeing.

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/29a438bb-6dc2-4c4a-9a67-2561e58e3eabn%40chromium.org.

[Ryan Hamilton]

The best way for us to understand what is happening will be to look at a net log. Once we have one, it'll probably be very obvious what's happening. Without one, it's pretty tricky to guess. Look forward to seeing what the net log shows!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/29a438bb-6dc2-4c4a-9a67-2561e58e3eabn%40chromium.org.

[Chuck Crisler]

Here is the file. Thank you in advance for your help.

[Ryan Hamilton]

Hm. That log shows any number of QUIC sessions to YouTube. For example 2127: QUIC_SESSION is a QUIC session which shows a video playback. Can you be more specific about what doesn't work?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAO_ovOKTgqE4XronBHB%3DupJHmTVg9OhfuQeprB%3DNR0yUV9rH9A%40mail.gmail.com.