[Trimming cc list] On Fri, 2016-03-25 at 19:04 +0000, Bob Briscoe wrote: > Jonathan, > > It does make sense. > Inline... > > On 24/03/16 20:08, Jonathan Morton wrote: > > > > > > > > On 21 Mar, 2016, at 20:04, Bob Briscoe <resea...@bobbriscoe.net> wrote: > > > > > > The experience that led me to understand this problem was when a > > > bunch of colleagues tried to set up a start-up (a few years ago > > > now) to sell a range of "equitable quality" video codecs (ie > > > constant quality variable bit-rate instead of constant bit-rate > > > variable quality). Then, the first ISP they tried to sell to had > > > WFQ in its Broadband remote access servers. Even tho this was > > > between users, not flows, when video was the dominant traffic, > > > this overrode the benefits of their cool codecs (which would have > > > delivered twice as many videos with the same quality over the > > > same capacity. > > This result makes no sense. > > > > You state that the new codecs “would have delivered twice as many > > videos with the same quality over the same capacity”, and video > > “was the dominant traffic”, *and* the network was the bottleneck > > while running the new codecs. > > > > The logical conclusion must be either that the network was severely > > under-capacity > Nope. The SVLAN buffer (Service VLAN shared by all users on the same > DSLAM) at the Broadband Network Gateway (BNG) became the bottleneck > during peak hour, while at other times each user's CVLAN (Customer VLAN) > at the BNG was the bottleneck. The proposition was to halve the SVLAN > capacity serving the same CVLANs by exploiting the multiplexing gain of > equitable quality video... explained below. > > > > and was *also* the bottleneck, only twice as hard, under the old > > codecs; or that there was insufficient buffering at the video > > clients to cope with temporary shortfalls in link bandwidth; > I think you are imagining that the bit-rate of a constant quality video > varies around a constant mean over the timescale that a client buffer > can absorb. It doesn't. The guys who developed constant quality video > analysed a wide range of commercial videos including feature films, > cartoons, documentaries etc, and found that, at whatever timescale you > average over, you get a significantly different mean. This is because, > to get the same quality, complex passages like a scene in a forest in > the wind or splashing water require much higher bit-rate than simpler > passages, e.g. a talking head with a fixed background. A passage of > roughly the same visual complexity can last for many minutes within one > video before moving on to a passage of completely different complexity.
This was all well understood in the 90's, when a ton of VBR video research was ongoing. > Also, I hope you are aware of earlier research from around 2003 that > found that humans judge the quality of a video by the worst quality > passages, so there's no point increasing the quality if you can't > maintain it and have to degrade it again. That's where the idea of > constant quality encoding came from. > > The point these researchers made is that the variable bit-rate model of > video we have all been taught was derived from the media industry's need > to package videos in constant size media (whether DVDs or TV channels). > The information rate that the human brain prefers is very different. > > A typical (not contrived) example bit-rate trace of constant quality > video is on slide 20 of a talk I gave for the ICCRG in May 2009, when I > first found out about this research: > http://www.bobbriscoe.net/presents/0905iccrg-pfldnet/0905iccrg_briscoe.pdf > As it says, the blue plot is averaged over 3 frames (0.12s) and red over > 192 frames (7.68s). If FQ gave everyone roughly constant bit-rate, you > can see that even 7s of client buffer would not be able to absorb the > difference between what they wanted and what they were given. FQ only gives everyone roughly constant bit-rate when everyone is backlogged (sending at or above their fair-share rate). Which contradicts the idea that the traffic is highly stat-muxable. > > Constant quality videos multiplex together nicely in a FIFO. The rest of > slide 20 quantifies the multiplexing gain: > * If you keep it strictly constant quality, you get 25% multiplexing > gain compared to CBR. > * If all the videos respond to congestion a little (ie when many peaks > coincide causing loss or ECN), so they all sacrifice the same proportion > of quality (called equitable quality video), you get over 200% > multiplexing gain relative to CBR. That's the x2 gain I quoted originally. > > Anyway, even if client buffering did absorb the variations, you wouldn't > want to rely on it. Constant quality video ought to be applicable to > conversational and interactive video, not just streamed. Then you would > want to keep client buffers below a few milliseconds. > > > > > or that demand for videos doubled due to the new codecs providing a > > step-change in the user experience (which feeds back into the > > network capacity conclusion). > Nope, this was a controlled experiment (see below). > > > > In short, it was not WFQ that caused the problem. > Once they worked out that the problem might be the WFQ in the Broadband > Network Gateway, they simulated the network with and without WFQ and > proved that WFQ was the problem. > > References > > The papers below describe Equitable Quality VIdeo, but I'm afraid there > is no published write-up of the problems they encountered with FQ - an > unfortunate side-effect of the research community's bias against > publishing negative results. > > Mulroy09 is a more practical way of implementing equitable quality > video, while Crabtree09 is the near-perfect strategy precomputed for > each video: > [Mulroy09] Mulroy, P., Appleby, S., Nilsson, M. & Crabtree, B., "The Use > of MulTCP for the Delivery of Equitable Quality Video," In: Proc. Int'l > Packet Video Wkshp (PV'09) IEEE (May 2009) > [Crabtree09] Crabtree, B., Nilsson, M., Mulroy, P. & Appleby, S., > "Equitable quality video streaming over DSL," In: Proc. Int'l Packet > Video Wkshp (PV'09) IEEE (May 2009) > > Either can be accessed from: > http://research.microsoft.com/en-us/um/redmond/events/pv2009/default.aspx Do you know what (if any) AQM was used with the BRAS WFQ implementation tested? WFQ+drop-tail or WFQ+RED - where the queue depths/RED parameters are set based on the queue fair-share rate - would probably perform much worse than a delay-based FQ-AQM such as FQ-CoDel, because in a delay-based FQ-AQM a deep flow queue does not necessarily imply high delay if that flow queue is currently being served at > fair share rate (since the traffic is so nicely stat-muxable). Regards, // Steve _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
