There's an interesting article in the April 2011 issue of ACM SIGCOM Computer Communications Review. The study by Shane Alcock and Richard Nelson (also accessible here) looks at the way application level algorithms on YouTube's video servers interact with TCP and the actual buffers in a retail DSL delivery system. I found this particularly interesting as I had already looked into the burstiness of other kinds of traffic in a set of posts in late 2009 (this post in particular).
Here's the way YouTube servers deliver data (at least as of January 2010) to high capacity clients:
By high capacity client I mean the client device has enough buffer space to absorb whatever data the video server wants to send and the client's broadband Internet access service has enough capacity to avoid congestion during delivery of these video bursts. Unfortunately, the delivery rate YouTube was using in January 2010 was enough to overwhelm the data buffers in typical DSL infrastructure as this graph illustrates.
It appears the YouTube servers send data in blocks of 64 KBytes or 128 KBytes (or multiples thereof) and these blocks can exceed the available buffer space in the DSL delivery infrastructure - mostly likely the buffers in Broadband Remote Access Server (BRAS). At least one BRAS I was familiar with in 2004-2005 had 200 ms of buffering, obviously not enough for one burst per second.
The good news is the net effect was only a 1% increase in the total data (due to retransmission) so this isn't a big problem and the authors discussed the issue with Google where engineers were working on a solution (in 2010). What's interesting to me is the extent to which the sizing of buffers for IP infrastructure is still a complex issue and the ease with which a simple application level decision can go wrong.