On Mon, Jul 14, 2014 at 11:23 AM, Fred Baker (fred) <[email protected]> wrote: > > On 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. > > Well, note that we’re not saying to pull RED out of the network; we’re saying > to not make it the default. Note that even in the networks you mention, > (W)RED is not the default configuration; you have to give it several > parameters, and therefore have to actively turn it on. > >> 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. >> >> 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. >> >> 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. > > The existing draft doesn’t mention any specific AQM algorithms. It seems to > me that the more consistent approach would be to write a short draft > documenting WRED, that the WG could pass along as informational or > experimental on the basis of not meeting the requirements of being > self-configuring/tuning, at the same time as it passes along others as PS or > whatever.
I strongly support a good, consistent set of recommendations for how, when, and where to use and not use WRED. > >> -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 > > > _______________________________________________ > 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
