733010 - Video download should be rate limited to avoid bufferbloat

Status: NEW

(Core :: Networking, defect, P3)

Description

[Patrick McManus [:mcmanus]]

This would apply to both existing <video> and dash

--

This is actually a design item we've already incorporated for an
upcoming implementation of the DASH framework. I don't recall having
talked about it in the scope of normal video/webm stuff but you're
absolutely right that it applies there.

managing queue sizes is particularly important to us in the context of
real time stuff like webrtc, but we care about non-browser apps too :)

I've cc'd some folks who are hands on with the video projects -
hopefully they can chime in here an incorporate this. Its an important
topic. Can the right person file a bug?

(jason, steve, josh, roc: here is a simple
http://devfiles.myopera.com/articles/1891/sunflower-webm.html html5
video page with 22 seconds of video, which I see all come down in 1
chunk as fast as possible.. iirc some videos will use multiple chunks
spread over time, but even that should be ratepaced where possible to
share the network more effectively.. not sure how effectively that is
currently happening)

-Pat

On Thu, 2012-03-01 at 12:51 +0100, Ashwin Rao wrote: Ashwin Rao <[e-mail]>

> >> > Can't agree more. We need a venue for two-way communications.
> >> >
> >> > app dev: TCP sucks because blah blah blah
> >> > TCP dudes: app sucks because blah blah blah
> >>
> >
> > Hi all.
> >
> > I develop network gunk for firefox - if you think there is something we
> > could be doing to make the web more capable, more open, and more awesome
> > please reach out to me.
> >
> > BTW - I'm not trying to just throw this over the wall and say "call me
> > if you need me", I think tcpm is part of my community and try and keep
> > up and contribute. My community is just a big world (from HTML5 to
> > ethernet), so stuff slips through and the needs may not necessarily
> > align.
> 
> Hi,
> 
> I have a suggestion regarding streaming HTML5 videos. Currently
> Firefox does not restrict the rate of data transfer while streaming
> HTML5 videos. Google Chrome and Internet Explorer however restrict the
> rate of data transfer. I have detailed out these rate restrictions in
> a preliminary work available at hal.inria.fr/inria-00638063/en/. Due
> to the absence of rate restrictions, Firefox downloads the data at the
> end to end available bandwidth, which can lead to saturation of the
> buffers in the home-gateways.  Jim Gettys has shown that restrictions
> on the download rate can be used to address the problem of bufferbloat
> [ http://gettys.wordpress.com/category/bufferbloat/ ].  I have not
> looked at the code of Firefox, however I would like to know if it
> would be possible to restrict the rate of data transfer which
> downloading specific web objects. In any case I would be happy to
> discuss this problem with you.
> 
> Regards,
> Ashwin

---

jason says:


One big question is: at what level should we be doing this?  The obvious 
two choices are to 1) have the video layer control download speed by 
calling suspend/resume on the network channel as needed.  That's a 
pretty blunt hammer;  or 2) add some sort of API to necko that lets the 
consumer specify what sort of bitrate they need to get out of the 
channel, and have necko deal with controlling the rate.  Of course, TCP 
doesn't exactly give us great tools for rate control either: besides 
simply not reading from the socket (same as suspending channel). we 
could fiddle with incoming OS socket buffer sizes, anything else?  
Perhaps we should start with suspend/resuming the channel, so we can 
make progress quickly, and keep an eye on how necko internally could 
facilitate things.


--

pat says

presumably #2.. maybe load group based instead of or in addition to
channel. non video use case would be things in the download window when
they were competing with interactive needs.

--

biesi says

FWIW, for the downloads case we could use the existing priorization
mechanism (nsISupportsPriority) to give downloads a lower priority...

Comment 1

[Anuvabh Dutt [:vabh]]

Hi,

Is there any work going on for this?

If yes, then I would like to get in touch with the developers involved as I am interested in contributing.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

No one is working on this.  Please feel free to work on it.  Before going too far, I advise posting your plan for how to deal with it here, and needinfo Patrick and myself

Comment 3

[Anuvabh Dutt [:vabh]]

(In reply to Randell Jesup [:jesup] from comment #2)
> No one is working on this.  Please feel free to work on it.  Before going
> too far, I advise posting your plan for how to deal with it here, and
> needinfo Patrick and myself

I am working with Aswhin ( his email is quoted in the bug description). Th initial idea we have is to dynamically change the media buffer size to throttle the video download rate.

I am new to the Firefox code base and am currently reading the code in dom/media to try to understand how video downloads are handled. I would appreciate pointers on how I should proceed.

Comment 4

[Patrick McManus [:mcmanus]]

personally, I would start with a test case and metric that you would use to declare success.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Also, the relevant cases would be <video>/<audio> elements (.src=URL), MSE/DASH as implemented in JS, and active WebRTC calls.

The people in media you'd want to talk to would mostly be in New Zealand, and hang out in #media on IRC (irc.mozilla.org).  For WebRTC, you'd want to monitor the number of connected PeerConnections (and maybe the traffic on their DTLS/DTLS-SRTP connections - for example, you may have enough bandwidth to pull at full rate from a given server even if a call/<video> is active (like fiber/FiOS); or you may have a smaller pipe, but the PeerConnection with a DataChannel is inactive, or it just has a low-bitrate audio-only connection.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258