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