Re: [aqm] Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC

[Jonathan Morton <[e-mail]>]

>> 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.

In other words, yes the network *was* congested…

> The proposition was to halve the SVLAN capacity serving the same CVLANs by exploiting the multiplexing gain of equitable quality video... explained below.

…and this is one of the key facts that helps me understand the use-case.

I’d be a lot more sympathetic if, as your original description strongly implied, it was all about getting better quality or more capacity from a given network, rather than attempting to *halve the capacity* of a part of the network that was *already congested* at peak hour.  The latter strategy is wrong-headed, especially from the “customer experience” point of view you espouse.

> 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

I understand CQR versus VBR versus CBR.  Now I also understand that “equitable quality” means that the codec adapts the quality to the available bandwidth - which is not the same as CQR, and is more akin to VBR.  This is the other key fact that was omitted from your previous description.

It’s also implicitly clear that the video sources are under the ISP’s control, hence relatively centralised, otherwise they wouldn’t be able to dictate which codec was used.  In theory they could therefore share information explicitly about network conditions each individual stream experiences.

Instead, it seems information was shared only implicitly, by relying on the specific behaviour of a single queue at each bottleneck, which is to give the same congestion signal (whether that be loss, delay, or ECN) to all flows through it.  WFQ broke that assumption, as would any other flow-isolation scheme which avoided impeding lightweight flows when controlling bulk flows, regardless of the precise definition of a “flow".

But I do have to ask: what is the *qualitative* difference between the action of WFQ to equalise capacity per flow, and the off-peak scenario where each flow is bottlenecked at the CVLANs?  I don’t see it.

 - Jonathan Morton