4 ms·
I had hoped this talk would stir more discussion than it has so far. I don´t know. That 45% figure for quic was news to me.
by dtaht 3y ago
I had hoped this talk would stir more discussion than it has so far.
I don´t know. That 45% figure for quic was news to me.
- vitus 3y ago(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%).
- geraldhh 3y agosame maybe packets with the "Saturation Experienced" bit are getting dropped