From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DCC1121F1D1 for ; Tue, 3 Dec 2013 13:22:32 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so7249540wid.11 for ; Tue, 03 Dec 2013 13:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gKHWRT2lFg6o8y7MJ7kYQF5SXgFBzSs9NHBypDOOJ48=; b=CSdzS201X7MhOk5QFGPEk/Ka3opNyBDKURZJwIZS1xXJESQO7ZqHYh/pQyLEsbT5k9 FZ5tFarvgEozDmOKA3jUTi3D8+ZKYeiAZUEQksx242pWX6cWJbnj9XKXXUAYEjvCC0y+ 6pRD1Vs0FFmtjK2g8FM3c6/7VxmeTrG/0rlOyJKZSLl8VJNRxW0G1fdnNZQzLE//Qp5N bDOAh10WEqbgYzhS2QBHsxCeEXmXYgaQp/bmq2tC7jolLo2+MVmwcxXqZglRBZItTn+W f5Iddh+JG1OpehgwdleyObmpmkh9CwG6JvMOJ1BC0CP5GAKlcARmNaSrIH0NUAse1JIE gL1A== MIME-Version: 1.0 X-Received: by 10.195.13.45 with SMTP id ev13mr59791078wjd.20.1386105750387; Tue, 03 Dec 2013 13:22:30 -0800 (PST) Received: by 10.217.51.5 with HTTP; Tue, 3 Dec 2013 13:22:30 -0800 (PST) Date: Tue, 3 Dec 2013 13:22:30 -0800 Message-ID: From: Dave Taht To: bloat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] congestion control and video conferencing X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:22:33 -0000 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? --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html