Hey all,
I want to propose download rate-control as not just a way to avoid bufferbloat (https://bugzilla.mozilla.org/show_bug.cgi?id=733010), but also as a way to deal with competing DASH flows, to help detect link over/under-use and to help optimize TCP throughput.
Seems like rate control can be achieved through managing the size of SO_RCVBUF and rate-limiting calls to recv(). I've read multiple comments online to see if there's some underlying OS implementation issue I should be aware of. I don't see any - do any of you know of any?
RATE-LIMITING TO MITIGATE BUFFERBLOAT
Already previously discussed as a good idea here: https://bugzilla.mozilla.org/show_bug.cgi?id=733010
RATE-LIMITING TO AVOID OSCILLATIONS IN COMPETING FLOWS
Multiple adaptive players often result in oscillating, unfair bandwidth usage [1]. It seems like these oscillations are caused by the pattern of ON OFF downloads caused by periodic best effort HTTP requests. Rate limiting the downloads, and minimizing idle connection time with back-to-back requests could mitigate these oscillations and allow a fair convergence.
CONTROLLED RATE VARIATION TO DETECT LINK OVER-USE AND UNDER-USE
Increase the download rate gradually, and only shift up to a higher encoded bit-rate (identified in the DASH manifest) when the increasing rate reaches that value. Randell previously suggested we use something like (http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02 ). In very abstract terms, the receiver increases the download rate until it detects an overuse of the link - at this point, it reduces the bandwidth estimation and then the download rate. We *could* do a similar thing though rate-limiting.
(Btw, the bandwidth estimation in this algorithm is delay-based - it uses the assumption that increases in delay imply overuse of the link, and vice-versa. I think we can use other methods of bandwidth estimation if need be).
RATE LIMITING TO OPTIMIZE TCP THROUGHPUT
Other reading seems to suggest adapting in this way in the App layer should work well with TCP slow-start. Non-rate controlled downloads can lead to idle periods which can cause TCP slow-start; whereas a continual stream of HTTP responses at a controlled rate *could* avoid this.
So, can we do rate-limiting as above without worrying about hidden OS implementation issues?
Issues that are not resolved completely by this theoretical musing:
-- Would TCP really help to converge on fairly shared bandwidth for competing flows, or would a new oscillation or unfairness take place?
-- What about competition with non-rate-controlled streams? Or other protocols, e.g. DASH vs WebRTC
-- Bandwidth estimation is not discussed here but is, of course, very important. It will impact how well rate limiting works.
-- Media buffer underflow/overflow could be managed by adjusting the download rate as well. Seems like maintaining a consistent buffer size is desirable to smooth out short-lived variations in bandwidth capability.
-- *Could* this be implemented effectively in Necko/NSPR...
Let me know your thoughts.
Steve.
[1] Akshabi et al; "What happens when HTTP adaptive streaming players compete for bandwidth"
_______________________________________________
dev-tech-network mailing list
dev-tech-
https://lists.mozilla.org/listinfo/dev-tech-network
)
On Tue, Jun 5, 2012 at 9:28 PM, Steve Workman <> 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?
Eric
_______________________________________________
dev-tech-network mailing list
dev-tech-
https://lists.mozilla.org/listinfo/dev-tech-network
)
On Jun 6, 2012, at 10:24 AM, Eric H. Jung wrote:
> On Tue, Jun 5, 2012 at 9:28 PM, Steve Workman <> 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.
_______________________________________________
dev-tech-network mailing list
dev-tech-
https://lists.mozilla.org/listinfo/dev-tech-network
)
