How video streaming (like YouTube) benefits from QUIC?

[wei wang]

Hi all

Google's web server and YouTube have adopted quic, and obtained obvious performance improvement. 

I know that quic is mainly designed for web, and the obtained improvements come from the quic's features like, reducing HOL delay on top of UDP, multiplexing on one connection (web pages usually have many resources like js,css, etc), 0 RTT connection (web pages are usually small pieces), better congestion control, and fec. It looks like all these features are customized for web.

But how video streaming benefits from quic?

such as VoD, it is like file download, only a single file, it looks like that it can not get benefits from multiplexing on UDP.

or 0 RTT seams no use, because the connection keeps all the time. 

just name a few. Maybe I am misunderstanding. 

So can anyone kindly talk about this? how each feature of quic make video streaming better

thanks!

[Ian Swett]

DASH uses separate audio and video requests, and is a chunked format.  DASH is used for the majority of YouTube video streaming, so there multiplexing without HoL blocking may have benefit there.

We have disabled 0RTT and that only measurably effects latency(as you would expect).  But a 1RTT QUIC handshake is still faster than the 2 to 3 TLS 1.2 over TCP requires.

There are (at least)four potential sources of gains for YouTube, but it's extremely difficult to quantify how much each contributes:

1) Loss Recovery - QUIC is similar to TCP's RACK, but has some additional advantages.  Given video rebuffers are driven by tail events(ie: a request taking 2x as long as expected) I believe this dominates.

2) No HoL blocking

3) Lack of middlebox interference

4) No issues with client RWIN tuning - We've looked at this and the results weren't conclusive.

Good question, unfortunately arriving at a definitive answer is almost impossible, though I believe we could quantify #2 with enough work.

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

[Siva Kesava]

Any more specific reasons on how QUIC improves streaming of YouTube videos over DASH?

Thanks

Siva Kesava

[David Pio]

#3 is something I hadnt considered before. how large of a problem is traffic shaping of video streams?

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Gregory Ray]

Dash is irrelevant afaik, the same benefits can be seen with HLS w/ quic or even just progressive MP4 (front loading the moov atom) over quic.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[Siva Kesava]

Leaving DASH aside can we pin pointedly say that because of a
particular design(like 0RTT) QUIC performs better than TCP for any
video streaming services? I mean can we quantify the results for a
particular design in both the protocols?

>> <javascript:_e(%7B%7D,'cvml','proto-quic%2Bunsu...@chromium.org');>.

>> To post to this group, send email to proto...@chromium.org

>> <javascript:_e(%7B%7D,'cvml','proto...@chromium.org');>.

[刘犇]

I am so appreciated for your answer and there is another question: whether we could display a DASH segment that is very large on Youtube when the segment not be received completely? That is to say, whether the data of a stream of QUIC can be extracted when the stream is not closed?

Thanks!
在 2016年4月28日星期四 UTC+8下午8:34:45，Ian Swett写道：