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