re: http://conferences.sigcomm.org/sigcomm/2013/papers/fhmn/p21.pdf
"We have found that the algorithm works as expected when a GCC ow accesses the bottleneck in isolation, whereas it is not able to provide a fair band- width utilization when a GCC flow shares the bottleneck with either a GCC or a TCP flow." I basically long ago came to the conclusion that video conferencing can't work without aqm and packet scheduling on the bottleneck links. Period. I wasn't aware there was also trouble even with two video conferencing flows sharing the same link! I run webrtc based and google hangout based talks through cerowrt with fq_codel all the time while doing other benchmarks, but haven't come up with good ways to quantify that. The results are generally pretty spectacular with the few glitches I get attributable to wifi misbehavior more than anything else. Is anybody else testing webrtc through various aqm technologies? I'd like to repeat this paper in a fq_codeled/pied/red'd environment and see what happens... anyone interested in helping? -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
