From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 DBA203B2FA for ; Mon, 29 Feb 2016 12:55:26 -0500 (EST) Received: by mail-ob0-x22d.google.com with SMTP id fz5so10115597obc.0 for ; Mon, 29 Feb 2016 09:55:26 -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=WGRRxOk2k0VDrd09j/GvEwRUqIv8Zy7R2RgOZnY8W44=; b=iK+ArD5szfQlzbZG9MHmFD5RaZKmatK+dNOuqucRTdh1nZ1LRMXiBQeZF2aNs8/ky3 v8I66kCVLz81bBbXYmUcZgusmlIZYzAfI0R93lla5M/nkEAlW1Ht7AzXU5JZUtnxgoPe qUgHjE5ilMb+NusDlY+EQk8yYWfi+B+WFxzX8VqxjYi6v/Ay9rklcETJeBQ60+RJ0uKX XnSV2bFIH/Aja2gxqUYs44PCkmCG0DQJ1R9KBHAiCgKSdh+D0u2YzzD9IPCRslG9ZL1J koAXsk8STNuD1pBZyQzKeJx6e2zN7/AnhHLSRLWYbevLEXx1hoz/q2bk+SbwW5cvwxF0 Nfgw== 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=WGRRxOk2k0VDrd09j/GvEwRUqIv8Zy7R2RgOZnY8W44=; b=fGpyPLk1/CQ0S/OrCiw4OSef4uHY5ZZ71UZXIL4MjDjU6DPZDJdt3P0Ql592m7hzw6 398a8FexwfY04vy59a07+Kw8Nvvyj+L2qkttvqSPahvGGje2SkgPjxS+Gw1V/syC5+rZ WgfKNuYinaL+6gweXPzZn2dUhZE0rs/VAEeta646ycllqvaMnDjrPe2IcSYUDMOi6S0Y 4Jsw0/hg3Dybl9HbmiGtDhnUn8fPfCqg20cM0WnCrYNa5E+FRhl959R43gah0nGH9Ylf 0vTaxqv259SM6TktZXMYYOhXqBNwLoojgD/m3LPtuYIdi7QaM972LVkIeZZBvDkios1A 3Z3A== X-Gm-Message-State: AD7BkJL93AiGQHWVzaRs/3YZMYeHLcsGsq0TFshCTbXulCzT4kBFZQszmtHx4Hxu2b0Wdee0nKApk5xF0yI2jw== MIME-Version: 1.0 X-Received: by 10.60.226.134 with SMTP id rs6mr13331979oec.69.1456768526260; Mon, 29 Feb 2016 09:55:26 -0800 (PST) Received: by 10.202.79.67 with HTTP; Mon, 29 Feb 2016 09:55:26 -0800 (PST) In-Reply-To: References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> Date: Mon, 29 Feb 2016 09:55:26 -0800 Message-ID: From: Dave Taht To: Alan Jenkins Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , bloat 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: Mon, 29 Feb 2016 17:55:27 -0000 On Sun, Feb 28, 2016 at 5:33 AM, Alan Jenkins wrote: > On 27/02/2016, Dave T=C3=A4ht wrote: >> On 2/26/16 3:23 AM, De Schepper, Koen (Nokia - BE) wrote: >> 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-con= fused-timid-and-unstable-picking-a-video-streaming-rate-is-hard/ > > Wow. Updated for 2015, here: https://reproducingnetworkresearch.wordpress.com/2015/05/31/cs244-15-confus= ed-timid-and-unstable-picking-a-video-streaming-rate-is-hard/ I love this class over at stanford. I've read everything they've published. With huge percentages of research papers being shown to not be reproducible, and networking being a moving target rather than rooted in the laws of physics, chemistry or biology, CS244 is desperately needed. If *every* university doing networking work had a second year class that took on classic and recently popular papers and updated them for current conditions we'd make short work of the backlog of stuff I'm dubious about and have better assumptions to stand on going forward. There are decades of work, in particular, that finds results at <4mbits that I do not think hold at > 20mbit or > 100mbit. Actually, more work spent reproducing papers (and having reproducible papers) would be great across all fields of science..... > > >>> 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 wrote this a month ago. Hit save. Edited saturday. Shouldn't have left in as much grumpiness as I did. That said, we could build on this experimental design. That experiment would be more like: phase 1) 20Mbit link, 4ms (google fiber), 10ms (cable), 20ms(dsl) (assuming co-location of the video server), 40ms(random source) base RTT to the video server. If pressed for time, just pick one of the above. Provide a reference for actual measured behavior first for the technology under emulation and emulate the actual bandwidth asymmetry. HAS app shooting for 18mbit video. How long does it take the flow to ramp u= p? Add *one* long running upload flow - How long does the HAS app take to ramp= up? Vary the AQMs on both sides of the link. Run with ECN and without. Apply web traffic as background - what rates are chosen, what is the PLT? I'd lean towards a web test that emulated a search, decision, web page fetch loop. (honestly I have a low bar for HAS traffic quality personally - merely never stopping playback to buffer is it. I am hard pressed to remember the last non-wifi-based interruption I've had on a video download using sqm-scripts) phase 2) trying 1-3 HAS flows on that link (as per the stanford experiment but shooting for 18mbits per flow), varying the AQMs. Then add in a single upload flow. Then try web traffic. Then all three.... phase 3) Adding in web traffic, a twitch game, a videoconference/voip session, a (set of) uploads, a (set of) downloads. To look further forward, pick an even higher encoding rate for the HAS video. Run the downlink at rates like 75-200mbit. Try it over wifi, too.... Getting to a high quality fast and staying there is *hard*, not just for mixed HAS traffic. The videoconferencing servers I've looked at thus far (jitsy, freeswitch) are doing *no* congestion control to speak of, although there are some patches in flight - I am seeing 8mbits udp down, 2mbit up from freeswitches's conference server.... > > I didn't like to complain on the AQM list. Well, the EU commission is unlikely to read that list also, but perhaps they will read that paper and other rite outputs. I have no idea what impact these outputs they will have. I look forward (with some dread) as to what sorts of head end aqm/fq technologies are adopted in the future on cable, fiber, cellular, etc, if any, ever. At this point I am kind of expecting 5G to more or less roll out first with better aqm/fq technologies as that's where the heavy hardware/software investment seems to be going. It looks like we'll see DOCSIS 3.1 trials in a few cities this year, but there's no public data on what, if any, improvements were made to the CMTSes. And gfiber (and services like comcast's blast) are so freaking fast that nearly all the bloat moves to the wifi. At the same time, the only things that seriously stress out wifi are multiple devices, and trying to watch HAS traffic over it! I did do some testing recently on the latest/greatest of the ethernet over powerline AV/1200 devices from netgear. It was another one of those - write my comments, hit save for a month - sort of exercises. > > 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. The typical pattern is to try and fetch 10seconds of video in under 2-4(?) sec, otherwise degrade to a lower rate. > > 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). Google switched to using sch_fq (host fq + pacing) pretty universally a year or two back, youtube switched first. There was a tcp patch that landed recently in the mainline kernel that didn't slam a connection after an idle period with the current size of the congestion window. That looked pretty important... (I have no idea how long it was in production)