From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 DADE321F260 for ; Thu, 26 Feb 2015 04:58:07 -0800 (PST) Received: by labgq15 with SMTP id gq15so10799830lab.3 for ; Thu, 26 Feb 2015 04:58:05 -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 :content-type; bh=qUk19EN2O+CqMroluGtNRjwaQFf3bxComHauTJeAMh0=; b=TQCqSv1oMghJ1tUHovVN8tMo3fu0zSm6DrD1p96H4AnOQd/ti7HDVALjAt26zm5HjR bOxXY/EgCdITSazi9Zgd5UU01CfaD5xzF6y6Am4Q5WQKyiZEUboJf5z6OAEYB1+ON5By ns67ZmKlVjF24icdezb17pJ8XstCmIAn17nscojzlM6X2PaiLL1DijMe5T5tLeCECJwA 21SEnio1ZU6IkcpGoD8yZ9wKl+PeWYBYsgsqF6J6sr1EddU2yiMWs8nlMLDmOyZbPbxC rjtnnRaP69R0CAr7ogsZxdo3ZhX4eaxUHCgK0omb5JpB8dknFbkDPuDNlvtBzAkjiu3g JX8A== MIME-Version: 1.0 X-Received: by 10.112.170.100 with SMTP id al4mr7490469lbc.42.1424955485212; Thu, 26 Feb 2015 04:58:05 -0800 (PST) Received: by 10.25.147.75 with HTTP; Thu, 26 Feb 2015 04:58:05 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2015 18:28:05 +0530 Message-ID: From: sahil grover To: Jonathan Morton , Richard Scheffenegger , codel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a11c23686845621050ffd4d76 Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 12:58:36 -0000 --001a11c23686845621050ffd4d76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi again, Jonathan Morton,Richard Scheffenegger and anyone please reply: As explained by Jonathan Morton,Richard Scheffenegger in above posts that one of the advantage of codel over RED is that codel does its work(drop/mark) at dequeue stage. But i am not still getting it like how?? How does it make difference whether packet is dropped/marked at enqueue stage or dequeue stage? Lets first talk about packet is marked(forget about dropping),then whether it is marked at enqueue stage ,the marked packet have to go through that buffer. Then what makes the difference? On Wed, Feb 25, 2015 at 11:40 PM, Dave Taht wrote: > no prob. > > On Wed, Feb 25, 2015 at 9:34 AM, sahil grover > wrote: > > Thanks for sharing > > :) > > > > On Tue, Feb 24, 2015 at 11:45 PM, Dave Taht wrote= : > >> > >> and I meant to mention my other big kvetch... > >> > >> Nearly no paper tests an asymmetric network, where upload speeds are a > >> fraction of the download speeds. This leads to acks dominating > >> upstream traffic, and A) a big upload is starved, or B) that upload > >> acks starves the download by a providers desparate attempts to > >> optimize - the combination of any traffic accros sthat link gets > >> subject to crazy ideas like ack prioritization and other scenarios > >> that break other forms of traffic. > >> > >> As this is actually how the edge of the internet is deployed - DSL has > >> ratios of 6 and even 20 to 1, cable modems are in the range of 6 and > >> 10 to 1, the only technology that is symmetric is fiber - it totally > >> boggles my mind that this is not also the standard benchmark test of > >> an aqm or fq algorithm. > >> > >> The lack of an asymmetric network test should also be a fundamental > >> bar to publication of any new paper on the AQM or FQ subjects. > >> > >> So we fixed that, in creating ns3 tests as well. It turned out to be > >> hard to do, we had a ton of bugs to sort out in the code (now mostly > >> done except for getting fq_codel itself mainlined) and I have no idea > >> if ns2 has the same problems or not, but it certainly explains why so > >> little in the liturature actually sees the real problems. > >> > >> And lastly - on another subject entirely - no aqm we know of yet is > >> correctly structured to deal with the taxi-stand topology half duplex > >> nature of wifi and wireless, and no sim I have yet tried looks > >> anything like measured reality. > >> > >> we're working on it. > >> > >> On Tue, Feb 24, 2015 at 10:00 AM, Dave Taht > wrote: > >> > On Tue, Feb 24, 2015 at 8:32 AM, Jonathan Morton < > chromatix99@gmail.com> > >> > wrote: > >> >> Most of us on this list believe that to be true, in many cases afte= r > >> >> performing experiments ourselves, or at least looking through data > >> >> generated > >> >> by others' experiments. > >> >> > >> >> However, if as I suspect you are investigating various AQM algorith= ms > >> >> as > >> >> part of your education, you should probably examine the data > yourselves > >> >> and > >> >> come to your own conclusions. You may even get extra credit for bei= ng > >> >> able > >> >> to describe the difference between AQM and Fair Queuing, and how th= ey > >> >> can be > >> >> combined (as in fq_codel) to give the benefits of both types in one > go. > >> >> But > >> >> for that, you ARE going to need to read some boring papers like "RE= D > in > >> >> a > >> >> different light". > >> > > >> > It is not particularly easy to keep up with the onslought of AQM > >> > literature since the bufferbloat effort started, but a review of stu= ff > >> > since 2011, or even as late at 2013 via google scholar should be > >> > illuminating. Many papers use RED as a reference, but nearly all of > >> > them miss the major points in the original bufferbloat experiments. > >> > Those experiment, long ago documented on Jim=C2=B4s earliest writing= s on > >> > the subject, available in video form, in various papers etc. One > >> > example: > >> > > >> > > >> > > https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstration-videos/ > >> > > >> > where jim performed an upload and a ping, at the same time, on a > >> > network optimized for downloads and and obviously not tested for > >> > uploads. The later rrul test suite (in netperf-wrapper, open source, > >> > anybody can use it, and I really wish they did) was designed to > >> > exercise both directions of the link with tcp data, and do a latency > >> > measurement, at the same time. > >> > > >> > Either experiment is consistently not replicated by experimenters *t= o > >> > date*, it frustrates me, and the only thing that gives hope is the > >> > slow progress in science of resolving the problems in this experimen= t: > >> > > >> > > >> > > http://en.wikipedia.org/wiki/Oil_drop_experiment#Millikan.27s_experiment_= as_an_example_of_psychological_effects_in_scientific_methodology > >> > > >> > But I am not willing to wait 70 years to get it all sorted out! > >> > > >> > The core observation I have is : > >> > > >> > Drop tail queues and AQMs do not do well in the face of cross traffi= c, > >> > (a mixture of small ack packets and larger data packets at saturatin= g > >> > loads). This is apparently one of those problems that most aqm-ers > >> > (but not van and kathie!) wish to sweep under the rug, as if having = a > >> > car that can steer on a downhill run only, was acceptable and safe t= o > >> > society at large. > >> > > >> > I made for-damn-sure that there was a rrul-like test for that scenar= io > >> > in the ns3 code now being mainlined, in the hope that new > >> > experimenters and designers of new algorithms would rigorously test > >> > for circumstances with cross traffic. I think I should also have got > >> > around to doing one in ns2. > >> > > >> > Moving on, codel was co-designed by the RED guy - van jacobson - and > >> > if you don=C2=B4t believe him when he explains how RED was flawed, = please > >> > stay away from my networks. > >> > > >> > http://www.pollere.net/Pdfdocs/QrantJul06.pdf > >> > > >> > There is no information in average queue length. > >> > > >> > The whole story about red in a different light, is sad and amusing a= t > >> > the same time, when someone finds he has made a mistake, and tries t= o > >> > retract it, and cant get published, and the pile on and noise level > >> > since by folk since writing RED related papers, even since we manage= d > >> > to get the correctly contradictory information on RED out there, is > >> > annoying. > >> > > >> > If *all* future aqm oriented papers made sure to address the > >> > cross-traffic problem - that mixture of big and small packets under > >> > saturating loads - with their latest-aqm-idea-de-jure as part of the= ir > >> > *core criteria for worthiness* - it would be a better world. > >> > > >> > While I certainly believe that you can make an AQM that works better > >> > with cross traffic - and actually have some revisions for codel that > >> > do so - > >> > > >> > You cannot predict the traffic load or traffic types going in either > >> > direction in most environments and thus you *must* handle it at peak > >> > load in both directions, well, in order to have a deployable solutio= n. > >> > For all the aqm-related papers of DASH and web traffic down, there a= re > >> > nearly none that test torrent/scp/dropbox or videoconferencing traff= ic > >> > up, at the same time. I would like to be in a world where I could > >> > refuse to read any paper that did not address the cross traffic > >> > problem, AND such papers were summarily rejected before publication. > >> > > >> > So, thus, codel is a AQM that combines well with FQ, unlike all othe= r > >> > AQMs published to date - and nearly nobody that uses it, uses it > >> > without also doing FQ. > >> > > >> > As it is, fq_codel is deploying rapidly across the edge where it was > >> > designed to go, and I see nearly no implementations of RED in the > >> > field from extensive talks with operators and firmware makers around > >> > the world. *None*, in my last poll at the New Zealand network > >> > operators group meeting. > >> > > >> > Some form of fair queuing, on the other hand, was deployed by over 1= /3 > >> > the network operators there. (Convincing advocates of FQ that AQM is > >> > also needed, has often been a frustrating exercise as well!) > >> > > >> > Lastly, if you have trouble reading english, there is always google > >> > translate. > >> > > >> > > >> >> - Jonathan Morton > >> >> > >> >> > >> >> _______________________________________________ > >> >> Codel mailing list > >> >> Codel@lists.bufferbloat.net > >> >> https://lists.bufferbloat.net/listinfo/codel > >> >> > >> > > >> > > >> > > >> > -- > >> > Dave T=C3=A4ht > >> > Let's make wifi fast, less jittery and reliable again! > >> > > >> > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > >> > >> > >> > >> -- > >> Dave T=C3=A4ht > >> Let's make wifi fast, less jittery and reliable again! > >> > >> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > > > > > > > > -- > Dave T=C3=A4ht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > --001a11c23686845621050ffd4d76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi again,
Jonathan Morton,Richard Scheffenegger and an= yone please reply:
As explained by Jonathan Morton,Richard Scheff= enegger in above posts that one of the advantage of codel over RED is that = codel does its work(drop/mark) at dequeue stage.
But i am not sti= ll getting it like how??
How does it make difference whether pack= et is dropped/marked at enqueue stage or dequeue stage?

Lets first talk about packet is marked(forget about dropping),then wh= ether =C2=A0it is marked at enqueue stage ,the marked packet have to go thr= ough that =C2=A0buffer.
Then what makes the difference?

On Wed, Feb 25,= 2015 at 11:40 PM, Dave Taht <dave.taht@gmail.com> wrote:<= br>
no prob.

On Wed, Feb 25, 2015 at 9:34 AM, sahil grover <sahilgrover013@gmail.com> wrote:
> Thanks for sharing
> :)
>
> On Tue, Feb 24, 2015 at 11:45 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> and I meant to mention my other big kvetch...
>>
>> Nearly no paper tests an asymmetric network, where upload speeds a= re a
>> fraction of the download speeds. This leads to acks dominating
>> upstream traffic, and A) a big upload is starved, or B) that uploa= d
>> acks starves the download by a providers desparate attempts to
>> optimize - the combination of any traffic accros sthat link gets >> subject to crazy ideas like ack prioritization and other scenarios=
>> that break other forms of traffic.
>>
>> As this is actually how the edge of the internet is deployed - DSL= has
>> ratios of 6 and even 20 to 1, cable modems are in the range of 6 a= nd
>> 10 to 1, the only technology that is symmetric is fiber - it total= ly
>> boggles my mind that this is not also the standard benchmark test = of
>> an aqm or fq algorithm.
>>
>> The lack of an asymmetric network test should also be a fundamenta= l
>> bar to publication of any new paper on the AQM or FQ subjects.
>>
>> So we fixed that, in creating ns3 tests as well. It turned out to = be
>> hard to do, we had a ton of bugs to sort out in the code (now most= ly
>> done except for getting fq_codel itself mainlined) and I have no i= dea
>> if ns2 has the same problems or not, but it certainly explains why= so
>> little in the liturature actually sees the real problems.
>>
>> And lastly - on another subject entirely - no aqm we know of yet i= s
>> correctly structured to deal with the taxi-stand topology half dup= lex
>> nature of wifi and wireless, and no sim I have yet tried looks
>> anything like measured reality.
>>
>> we're working on it.
>>
>> On Tue, Feb 24, 2015 at 10:00 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> > On Tue, Feb 24, 2015 at 8:32 AM, Jonathan Morton <chromatix99@gmail.com>
>> > wrote:
>> >> Most of us on this list believe that to be true, in many = cases after
>> >> performing experiments ourselves, or at least looking thr= ough data
>> >> generated
>> >> by others' experiments.
>> >>
>> >> However, if as I suspect you are investigating various AQ= M algorithms
>> >> as
>> >> part of your education, you should probably examine the d= ata yourselves
>> >> and
>> >> come to your own conclusions. You may even get extra cred= it for being
>> >> able
>> >> to describe the difference between AQM and Fair Queuing, = and how they
>> >> can be
>> >> combined (as in fq_codel) to give the benefits of both ty= pes in one go.
>> >> But
>> >> for that, you ARE going to need to read some boring paper= s like "RED in
>> >> a
>> >> different light".
>> >
>> > It is not particularly easy to keep up with the onslought of = AQM
>> > literature since the bufferbloat effort started, but a review= of stuff
>> > since 2011, or even as late at 2013 via google scholar should= be
>> > illuminating. Many papers use RED as a reference, but nearly = all of
>> > them miss the major points in the original bufferbloat experi= ments.
>> > Those experiment, long ago documented on Jim=C2=B4s earliest = writings on
>> > the subject, available in video form, in various papers etc. = One
>> > example:
>> >
>> >
>> > https://gettys.wordpress.com/201= 2/02/01/bufferbloat-demonstration-videos/
>> >
>> > where jim performed an upload and a ping, at the same time, o= n a
>> > network optimized for downloads and and obviously not tested = for
>> > uploads. The later rrul test suite (in netperf-wrapper, open = source,
>> > anybody can use it, and I really wish they did) was designed = to
>> > exercise both directions of the link with tcp data, and do a = latency
>> > measurement, at the same time.
>> >
>> > Either experiment is consistently not replicated by experimen= ters *to
>> > date*, it frustrates me, and the only thing that gives hope i= s the
>> > slow progress in science of resolving the problems in this ex= periment:
>> >
>> >
>> > http://en.wikipedia.org/wiki/Oil_drop_exper= iment#Millikan.27s_experiment_as_an_example_of_psychological_effects_in_sci= entific_methodology
>> >
>> > But I am not willing to wait 70 years to get it all sorted ou= t!
>> >
>> > The core observation I have is :
>> >
>> > Drop tail queues and AQMs do not do well in the face of cross= traffic,
>> > (a mixture of small ack packets and larger data packets at sa= turating
>> > loads). This is apparently one of those problems that most aq= m-ers
>> > (but not van and kathie!) wish to sweep under the rug, as if = having a
>> > car that can steer on a downhill run only, was acceptable and= safe to
>> > society at large.
>> >
>> > I made for-damn-sure that there was a rrul-like test for that= scenario
>> > in the ns3 code now being mainlined, in the hope that new
>> > experimenters and designers of new algorithms would rigorousl= y test
>> > for circumstances with cross traffic. I think I should also h= ave got
>> > around to doing one in ns2.
>> >
>> > Moving on, codel was co-designed by the RED guy - van jacobso= n - and
>> > if you don=C2=B4t=C2=A0 believe him when he explains how RED = was flawed, please
>> > stay away from my networks.
>> >
>> > http://www.pollere.net/Pdfdocs/QrantJul06.pdf
>> >
>> > There is no information in average queue length.
>> >
>> > The whole story about red in a different light, is sad and am= using at
>> > the same time, when someone finds he has made a mistake, and = tries to
>> > retract it, and cant get published, and the pile on and noise= level
>> > since by folk since writing RED related papers, even since we= managed
>> > to get the correctly contradictory information on RED out the= re, is
>> > annoying.
>> >
>> > If *all* future aqm oriented papers made sure to address the<= br> >> > cross-traffic problem - that=C2=A0 mixture of big and small p= ackets under
>> > saturating loads - with their latest-aqm-idea-de-jure as part= of their
>> > *core criteria for worthiness* - it would be a better world.<= br> >> >
>> > While I certainly believe that you can make an AQM that works= better
>> > with cross traffic - and actually have some revisions for cod= el that
>> > do so -
>> >
>> > You cannot predict the traffic load or traffic types going in= either
>> > direction in most environments and thus you *must* handle it = at peak
>> > load in both directions, well, in order to have a deployable = solution.
>> > For all the aqm-related papers of DASH and web traffic down, = there are
>> > nearly none that test torrent/scp/dropbox or videoconferencin= g traffic
>> > up, at the same time. I would like to be in a world where I c= ould
>> > refuse to read any paper that did not address the cross traff= ic
>> > problem, AND such papers were summarily rejected before publi= cation.
>> >
>> > So, thus, codel is a AQM that combines well with FQ, unlike a= ll other
>> > AQMs published to date - and nearly nobody that uses it, uses= it
>> > without also doing FQ.
>> >
>> > As it is, fq_codel is deploying rapidly across the edge where= it was
>> > designed to go, and I see nearly no implementations of RED in= the
>> > field from extensive talks with operators and firmware makers= around
>> > the world. *None*, in my last poll at the New Zealand network=
>> > operators group meeting.
>> >
>> > Some form of fair queuing, on the other hand, was deployed by= over 1/3
>> > the network operators there. (Convincing advocates of FQ that= AQM is
>> > also needed, has often been a frustrating exercise as well!)<= br> >> >
>> > Lastly, if you have trouble reading english, there is always = google
>> > translate.
>> >
>> >
>> >> - Jonathan Morton
>> >>
>> >>
>> >> _______________________________________________
>> >> Codel mailing list
>> >> Codel@list= s.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/codel
>> >>
>> >
>> >
>> >
>> > --
>> > Dave T=C3=A4ht
>> > Let's make wifi fast, less jittery and reliable again! >> >
>> > https://plus.google.com/u/0/1079421756= 15993706558/posts/TVX3o84jjmb
>>
>>
>>
>> --
>> Dave T=C3=A4ht
>> Let's make wifi fast, less jittery and reliable again!
>>
>> https://plus.google.com/u/0/107942175615993= 706558/posts/TVX3o84jjmb
>
>



--
Dave T=C3=A4ht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/po= sts/TVX3o84jjmb

--001a11c23686845621050ffd4d76--