[moving followups to dev.tech.network, as this seems to be more network-focused at this point.]
On May 21, 12:17 pm, Alan Ogilvie <[email protected]> wrote: > *) For the 'http.max...' configuration settings and current 'pipeline' > usage - it would be nice to see a couple of things live in Firefox: a) the > actual usage of the different HTTP slots for a particular tab/window b) the > total for the entire browser - this sounds like something difficult to see, > but given the general 'add-on' world of Firefox... is that something that > could be exposed? (not for public consumption perhaps) It certainly ought to be possible to write an addon to do this. I don't know if anyone has. > *) Background Tabs - [theory] seem to throttle bandwidth, likely to reduce > impact on foreground tabs, resulting in Flash HDS players that employ an > adaptive bitrate algorithm to fall back to the lowest bitrate available. It's true that we prioritize the foreground tab's channels. But the only notion of "priority" we have right now (this may need to change at some point) is that higher-priority requests sit at the head of the wait queue if there are more requests than available HTTP connections. Once a request has been issued on the wire, we treat it the same as any other, so you get whatever rate TCP winds up giving you in the presence of multiple TCP streams being open (i.e. a bit of a crapshoot). The API I talked about on dev.tech.network (that allows you to set a channel to download with a 'smooth' constant rate) may help with this. For now channel loading is 'bursty', but so long as there's close to enough aggregate bandwidth for all the channels being loaded, and you have decent amount of buffering, you'll be ok. You may be right that this sort of thundering herd approach might make a channel that loses the TCP bandwidth sweepstakes decide to pick a lower-quality video than it needs to. We'll probably need smarter logic to deal with this at some point. > *) I wonder if pipelining happens on the HDS fragment requests - is there a > 'smoking gun' that makes this easy to spot. I'm assuming we'd prefer > pipelining, right? Http pipelining mainly reduces latency, which is not really much of an issue in bandwidth-dominated apps like streaming. You probably *don't* want to pipeline stream requests, because that essentially ties the 2nd and further requests to a particular connection, when they could otherwise grab any available connection that becomes available. Worse, if other, small resources needed for a page are pipelined behind a stream, it will be a *long* time before they are satisfied (I believe Patrick wrote some logic that separates different content types onto different connections precisely to avoid this issue, known as "head of line blocking"). > *) Seems like these http.max... settings vary between Firefox versions, do > they vary on platform? (what's the 'size' of the 'problem', should I be > more concerned) The only cases that might cause you grief are for users using proxies (8 max connections will be an issue if you want to show a number of streams that approaches--or, obviously, exceeds--8. Mobile will also be an issue until we increase the number of max-http connections there (it's currently only 6, vs 256 on desktop). I can't imagine people streaming more than a few videos on a mobile phone today, but on android tablets it seems more likely. The likely solution here is to increase the limits if we see trouble happening, and then see how badly that breaks existing proxy servers and mobile phones (not much fun, but I don't see a better fix). > *) I am trying to speak to our contacts in Adobe to see what they think about > browser cache implications for HDS, and I suspect this will have an impact on > their MPEG-DASH thinking too. Do you know if you have had any contact with > them around this? none that I've heard of. > *) additional use of SPDY could speed up these sort of fragment requests - > though support seems limited. I'd not considered that before. What sort of frequent requests? SPDY, like pipelining, is mainly geared to avoiding the latency of lots of little requests, so it's unlikely to make a difference with the large chunks involved in streaming. cheers, Jason Mozilla _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
