Re: Rate-controlling DASH downloads for more than bufferbloat

On Jun 6, 2012, at 10:24 AM, Eric H. Jung wrote:

> On Tue, Jun 5, 2012 at 9:28 PM, Steve Workman <[email protected]> wrote:
> 
>> 
>> Seems like rate control can be achieved through managing the size of
>> SO_RCVBUF and rate-limiting calls to recv().
> 
> Out of curiosity, why are both needed? Why not one or the other?
> 
I could be wrong, but with just managing calls to recv(), I'm imagining a scenario where SO_RCVBUF is large and TCP does a big download to fill it - so, even if we waited to call recv(), there could be a large burst of data downloaded at one time to fill the buffer. This would be rate-limited from the application side, but the link would/could still be bursty. That's what we want to avoid.

And the other way around, just managing the size of SO_RCVBUF: this would seem to result in more calls to recv to empty the buffer from the applications (HTTP) side. I may have missed something in Necko's socket and HTTP code, but from what I've learned it's event-driven and dumps out data from sockets to HTTP when data is present. I guess in this scenario the network *might* be less bursty, but it's still not a controlled rate of download.