It looks like the massive uptake in QUIC is largely due to Google and Facebook, per Bart's presentation. One of the biggest obstacles to broader adoption is the increased CPU cost (due to lack of NIC TLS / GSO offload support from the vendors) so it's interesting that as the vendor representative, he brought this up.
I'm curious how Cisco is getting these measurements, since if the proportion of YT traffic is accurate, then the overall internet bandwidth is much larger than I thought it was.
(I think there's some reluctance to engaging with video content, as opposed to a text summary or slides.)
Google serves a lot of QUIC (mostly IETF QUIC; we're trying to get rid of our usage of pre-standardization Google QUIC but smart TVs have been a persistent challenge). Facebook too. Cloudflare does QUIC too, but they don't serve as many bytes.
I knew that Netflix serves entirely TCP -- they were shocked to hear that we serve so much QUIC because it's so much less efficient without vendor support and/or significant engineering investment. They also serve a lot more bandwidth out of each cache node in part because their catalog is so much smaller than YT's (and so they don't really need to cachefill on demand), so for them, NIC offload is a hard requirement.
45% also seems high to me, which is why I'm interested in Cisco's methodology here. I think it's very possible that the Cisco report is overestimating the size of FB properties and underestimating the size of YT / other Google properties. At the same time, it seems to me that they're overestimating QUIC adoption on the YT side (YT is generally around 2/3 QUIC by bytes egressed, not 85-90%).
4 comments
[ 4.5 ms ] story [ 22.9 ms ] threadI'm curious how Cisco is getting these measurements, since if the proportion of YT traffic is accurate, then the overall internet bandwidth is much larger than I thought it was.
I don´t know. That 45% figure for quic was news to me.
Google serves a lot of QUIC (mostly IETF QUIC; we're trying to get rid of our usage of pre-standardization Google QUIC but smart TVs have been a persistent challenge). Facebook too. Cloudflare does QUIC too, but they don't serve as many bytes.
I knew that Netflix serves entirely TCP -- they were shocked to hear that we serve so much QUIC because it's so much less efficient without vendor support and/or significant engineering investment. They also serve a lot more bandwidth out of each cache node in part because their catalog is so much smaller than YT's (and so they don't really need to cachefill on demand), so for them, NIC offload is a hard requirement.
45% also seems high to me, which is why I'm interested in Cisco's methodology here. I think it's very possible that the Cisco report is overestimating the size of FB properties and underestimating the size of YT / other Google properties. At the same time, it seems to me that they're overestimating QUIC adoption on the YT side (YT is generally around 2/3 QUIC by bytes egressed, not 85-90%).
maybe packets with the "Saturation Experienced" bit are getting dropped