ietf
[Top] [All Lists]

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

2016-03-28 10:13:02
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


<Prev in Thread] Current Thread [Next in Thread>