Change:
this is relatively routine, but in other cases, it is more difficult (sec-unpredict, sec-extreme). <ins> And as with other parts of the ecosystem, new technology brings new challenges.  For example, with the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while still being transmitted to the cache, and while the cache does not yet know the size of the object.  Some of the popular caching systems were designed around cache footprint and had deeply ingrained assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </ins> 2.4. Historical data shows that users consume more video and videos at

Discussion:
…cy streaming)
This reads nicely to me. I'm not asking about this for today (it's I-D cutoff day, after all), but is there any reference that could be provided for the user to learn more?
Not really, I think I just know a guy who knows a guy who says this happened or something...
From Will - Caching Systems May be worth mentioning that concurrent gaming downloads nowadays drive larger traffic peaks than live or VOD streams. Additionally, something missing from this section is the impact of chunk transfer of aggregating responses. These are being used increasingly for low latency delivery. The caching system is receiving the object in real-time while simultaneously forwarding it to the client. The object size is not known until the transmission is complete. Much of caching infrastructure failover and redundancy is predicated on knowing the size of the object you are transmitting. Distribution tiers have a hard time separating a gap in data from a failure of an upstream component. Setting appropriate time-outs becomes problematic.
This is a true and fine point, but I'm not sure it needs mention in a video-centric doc, except maybe how this impacts video delivery from the shared resources, but I think the congestion control sort of takes that. I'll give it some thought, but I don't think it's really specific to caching or what we get out of raising it here, so I'm leaning toward not doing anything in this section on this point.
I'll follow up with a separate question about the other half of this comment, I'm not quite sure what it's saying. But it's a good point that talking about some non-intuitive failure modes might be handy here.
Hi, NAME - any update here?
Not yet. I did send a message hoping to learn enough about the failure modes and what you can do about them to write something meaningful here, but there are some vacation-related delays and once people are back I may have to ping again.