Dave, The message of the results that we presented in November is that it is possible, with currently deployed access hardware, to configure RED so that it consistently improves the end user experience of common network services over Tail-Drop (which is most often configured), and that this improvement can be achieved with a fixed set of RED configuration guidelines.
We did not run experiments with sfq_codel because it is not deployed in access networks today. We ran experiments with plain CoDel to understand the difference between a well-configured RED and a more recent single-bucket AQM in our target scenarios, and as reported, didn't observe significant differences in application QoE. Additional inline clarifications below. -Shahid. -----Original Message----- From: Dave Taht [mailto:[email protected]] Sent: Monday, July 14, 2014 2:00 PM To: Akhtar, Shahid (Shahid) Cc: Fred Baker (fred); John Leslie; [email protected] Subject: Re: [aqm] Obsoleting RFC 2309 On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) <[email protected]> wrote: > Hi Fred, All, > > Let me an additional thought to this issue. > > Given that (W)RED has been deployed extensively in operators' networks, and > most vendors are still shipping equipment with (W)RED, concern is that > obsoleting 2309 would discourage research on trying to find good > configurations to make (W)RED work. > > We had previously given a presentation at the ICCRG on why RED can still > provide value to operators > (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a > paper at Globecom 2014 that explains this study much better, but I cannot > share a link to it until the proceedings are available. My problem with the above preso and no doubt the resulting study is that it doesn't appear cover the classic, most basic, bufferbloat scenario, which is "1 stream up, 1 stream down, one ping (or some form of voip-like traffic)" and usually on an edge network with asymmetric bandwidth. SA: We tried to cover the typical expected traffic over the Internet. Most of the traffic is now HAS traffic (as per the sandvine report), so if only a single stream is present, it is likely to be HAS. The closest approximation of a continuous TCP stream, as you mention, would be a progressive download which can last long enough to look continuous. These were modeled together with other types of traffic. It's not clear from the study that this is a 8mbit down 1mbit up DSL network (?), SA: In the study presented, It was 8M down and 1.6M up - slide 9 nor is it clear if RED is being applied in both directions or only one direction onl? SA: AQMs (including RED) were only applied in downstream direction - slide 9 (and the results you get from an asymmetric network are quite interesting, particularly in the face of any cross traffic at all) SA: I am not sure what you mean by cross-traffic, the DSL link only goes to one residence (or business). The typical traffic to that was modeled. And I do keep hoping that someone will do a study of how prevalent fq is on dsl devices, I keep accumulating anecdotal data that it's fairly common. > One of the major reasons why operators chose not to deploy (W)RED was a > number of studies and research which gave operators conflicting messages on > the value of (W)RED and appropriate parameters to use. Some of these are > mentioned in the presentation above. > > In it we show that the previous studies which showed low value for RED used > web traffic which had very small file sizes (of the order of 5-10 packets), > which reduces the effectives of all AQMs which work by dropping or ECN > marking of flows to indicate congestion. Today's traffic is composed of > mostly multi-media traffic like HAS or video progressive download which has > much larger file sizes and can be controlled much better with AQMs and in our > research we show that RED can be quite effective with this traffic, with > little tuning needed for typical residential access flows. I tend to disagree with this, (well, not the trendline to big video flows) but my own studies are focused on retaining high performance gaming, voip, and videoconferencing traffic in the face of things like HAS video traffic. I would be much happier about your study had you also run that sort of traffic while testing your video downloads and aqms... and why is it so hard to get folk to try sfq_codel, etc, while they try everything else? SA: We did not model smaller flows (in terms of throughput). Small UDP flows, which I assume all/most of the above would fall in, would benefit significantly with RED - slide 13 shows much lower average queue length with RED. Other studies have shown that small UDP flows with lots of TCP traffic benefit significantly with RED achieving lower packet loss (M. Mays et al, “Reasons not to deploy RED”). > > Prefer John's proposal of updating 2309 rather than obsoleting, but if we can > have some text in Fred's draft acknowledging the large deployment of (W)RED > and the need to still find good configurations - that may work. I can > volunteer to provide that text. > > -Shahid. > > -----Original Message----- > From: aqm [mailto:[email protected]] On Behalf Of Fred Baker (fred) > Sent: Monday, July 14, 2014 2:06 AM > To: John Leslie > Cc: [email protected] > Subject: Re: [aqm] Obsoleting RFC 2309 > > > On Jul 3, 2014, at 10:22 AM, John Leslie <[email protected]> wrote: > >> It would be possible for someone to argue that restating a >> recommendation from another document weakens both statements; but I >> disagree: We should clearly state what we mean in this document, and >> I believe this wording does so. > > The argument for putting it in there started from the fact that we are > obsoleting 2309, as stated in the charter. I would understand a document that > updates 2309 to be in a strange state if 2309 is itself made historic or > obsolete. So we carried the recommendation into this document so it wouldn't > get lost. > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
