From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 55A703B2FF for ; Sun, 28 Feb 2016 08:33:39 -0500 (EST) Received: by mail-io0-x233.google.com with SMTP id z135so163540843iof.0 for ; Sun, 28 Feb 2016 05:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=RRzOCw4EDF1Fi8VJd1IMdDVr34T15Sk22FZhLfoYKrc=; b=CYxmvkzU2E2X1iwWku1Bzh8sAxpyzu4jo7cAq+axSTvr9pERAYTnhze00gnA8MgSnl d7vOxR3DdiboObGbQ1ZAVq1V++rr2QufsQ1kLH7Bk2DyfQPjKc4Qkm/GYw3GXU9dkJnm jC2Pld3TyS230z8ZvJ7PGzwEDbW1ur8tskEyFv5c/Dfm8S32GsyNQyclbRrgwukqc2hE VHljKvkEjnc4yiA3P47ZE/OQYkeJ90+ust+b0ARb1+03k8CN5tlKAyU+Xr6n84vyz6LT eKFALkgwpxyoGbd734YPBPhGn0Nfqnq4uFoAfaGnNPo41H3F720BtE3MmG4rhHz/6x5c JgBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=RRzOCw4EDF1Fi8VJd1IMdDVr34T15Sk22FZhLfoYKrc=; b=YxwlDPaRPbX7fS52gqSQYI51BraHhBikb4oxFoR+DqJ8Tw4nGivy2YcnBiz7x2fvEb /LghND3zutL1pdHxzSHbqjizy1pnBfY3MGu6eFd6YRGpkCFO2RMJB325CjaFOkydZhWO EHPQb6TIwKOVcPK3OjaceLMpSSBA5lb41qFC0nDpKHKBsZll8zDSdcCurUV4YCvo9rin zxOuAoAvQlzBa87H5pC0wT+UL+RialZZjTjn8FvsUHDDMJp9w4YTiaVYbiXbZen1OzJz W2Ku7yHnviNeW2pcScnow1z3mE2ULnXWuel8xGd/FsHi6aBPy0AgoLc/93YUwenl3rjl h4Vw== X-Gm-Message-State: AG10YORcmhvB6WeqvxmaNhqzXyO/JOqyFCdtyL2VQbOcqcINdfy0E2DBdLYxOEWGORT9vo3JfnnFoWv40FWOeQ== MIME-Version: 1.0 X-Received: by 10.107.16.16 with SMTP id y16mr16397473ioi.13.1456666418800; Sun, 28 Feb 2016 05:33:38 -0800 (PST) Received: by 10.50.36.9 with HTTP; Sun, 28 Feb 2016 05:33:38 -0800 (PST) In-Reply-To: <56D1F349.6040601@taht.net> References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> Date: Sun, 28 Feb 2016 13:33:38 +0000 Message-ID: From: Alan Jenkins To: =?UTF-8?Q?Dave_T=C3=A4ht?= Cc: bloat@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 13:33:39 -0000 On 27/02/2016, Dave T=C3=A4ht wrote: > > > > On 2/26/16 3:23 AM, De Schepper, Koen (Nokia - BE) wrote: >> Hi Wes, >> >> Just to let you know that we are still working on AQMs that support >> scalable (L4S) TCPs. >> We could present some of our latest results (if there will be a meeting = in >> Buenos Aires, otherwise in Berlin?) >> >> * Performance of HTTP Adaptive Video Streaming (HAS) with different TCP'= s >> and AQMs >> o HAS is currently ~30% of Internet traffic, but no AQM testing so fa= r >> has included it > I am aware of several unpublished studies. There was also something that > compared 1-3 HAS flows from several years back from stanford that I've > longed to be repeated against these aqm technologies. > > https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs244-14-conf= used-timid-and-unstable-picking-a-video-streaming-rate-is-hard/ Wow. >> o the results are very poor with a particular popular AQM > > Define "very poor". ? Heh. After skimming the same sections as you, I think my restraint must be vastly inferior to yours. I didn't like to compain on the AQM list. I think your point about the measurements made for background web traffic are more interesting. But it looks a bit weird and I can imagine the results being used inappropriately. >> Presenter: Inton Tsang >> Duration: 10mins >> Draft: Comparative testing of draft-ietf-aqm-pie-01, >> draft-ietf-aqm-fq-codel-04, draft-briscoe-aqm-dualq-coupled > > > >> >> For experiment write-up, see Section 3 of >> https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-pub= lic1.pdf I wouldn't complain that I can't sustain 2056Kbps goodput when my fair share of the shaped bandwidth is 2000Kbps. The results might be showing a significant degradation, or it could be a marginal one that pushes over the boundary (between the 2056k and 1427k encodes). Which of those conclusions you start from might be influenced by whether you're developing a different AQM, hmm. The HAS over TCP must be more bursty than a simple TCP download. All this could be explained by a competitive advantage in queues without fair scheduling. There's no effort to rule it out here, at least. You can see in the first link above, HAS used to basically die in competition with a simple TCP download. Clearly it's been fixed for this case - assuming current commonly deployed queues. SFQ looks *very* different to these queues, as they point out, and you see in the throughput graphs. So it is possible there's an issue with the closed-source HAS being tested. Somehow I doubt the Google Video's of this world would remain degraded, if there's a real issue here. (I know, game theory of incremental deployment, sigh). It can't be a co-incidence that the variation below 1.5Mbps happens when the HAS decides to switch the roles of video and audio TCP streams (!). That it's below 1.5Mbps for a the first 30s is a second pointer, towards the handling of bursts related to "slow start". It's strange to just say "the upside with a possibility to peak in throughput cannot happen". What that means is you want a new HAS stream to inflict this quality drop on an established one, so your new stream doesn't have to start at the lower quality in order to build up a buffer. Sure, that's even more contrived. And it's probably what you'd prefer in practice. Either you've got enough bandwidth for two streams, or the established one is going to visibly downgrade anyway. But that's a path-dependent result, on SFQ [1990] not being deployed when the HAS was being optimized. It doesn't seem to be a clear demonstration of the fundamental advantages of L4S / DualQ. Alan