Jonathan,
It does make sense.
Inline...
On 24/03/16 20:08, Jonathan Morton wrote:
On 21 Mar, 2016, at 20:04, Bob Briscoe <research@xxxxxxxxxxxxxx> 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.
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.
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
Bob
- Jonathan Morton
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/