Re: Ratelimiting video to avoid buffer bloat

> > The problem isn't the buffered video but the IP level buffering that 
> happens on big tcp downloads...  that's why I filed it against 
> networking first
>
> I don't follow--the OS buffers for a TCP socket are much smaller than 
> the media cache's buffer.   Or are you talking about clogging router 
> buffers?  I still don't see how necko doing the suspend/resume vs the 
> media cache makes a difference here.

yes, router buffer of the bottleneck link. That's where the problem is 
and where the problem can be slow to clear - once data is at the host 
its not an issue for anything but ram.

if necko can do it we can apply the code to things other than media 
consumers (e.g. download window) where the notion of appropriate rate 
might be derived from some shared state about all the necko connections 
- so we don't want to push that decision out to the end consumer who 
doesn't have visibility into all the other transfers.

additionally, there are things necko can do other than just stop reading 
on suspend.. it can slam rwin (the recv buffer) down to ~0, which is 
going to stop the transmit faster in the presence of large windows (and 
windows larger than bw*delay are the heart of bufferbloat), 
alternatively it can just reduce rwin to something smaller than bw*delay 
to effectively slow the transmission rate and make sure the bottleneck 
link gets its buffers cleared at least once every rtt.. etc.. etc..