Re: [aqm] [gautamramk/FQ-PIE-for-Linux-Kernel] max_prob & ecn (#2)

Somehow our naive attempt at putting ecn into pie became part of the standard. This project is making that more configurable. I'd like it if more pie folk took a look at it. https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2 Gautam Ramakrishnan writes: > I have added this

Re: [aqm] [Bloat] [Cake] paper: per flow fairness in a data center network

switch I can buy? (or beg, borrow, or steal?) I do need a 10GigE-40GigE capable switch in the lab, and BOY oh boy oh boy would I love to test this one. Has this tech made it into their routing products? > > On Thu, Dec 6, 2018 at 4:19 AM Dave Taht wrote: > > While I strongly

[aqm] paper: per flow fairness in a data center network

While I strongly agree with their premise: "Multi-tenant DCNs cannot rely on specialized protocols and mechanisms that assume single ownership and end-system compliance. It is necessary rather to implement general, well-understood mechanisms provided as a network service that require as few

[aqm] sch_cake and sch_tbs now in linux 4.19

Of possible interest to the members of this (former) working group, is that sch_cake (our all singing, all dancing shaper + per host fq + revised codel qdisc) is now in the Linux mainline. Of other possible interest is the new sch_tbs scheduler which allows for time based packet releases and

[aqm] upstreamed sqm sch_cake in openwrt-18.06-rc2

hopefully the identical version of sch_cake that will also be in linux 4.19 (presently in net-next) is now in openwrt's 18.06-rc2 release. It would be good for tons more folk to beat it up thoroughly over the next several weeks before it is formally released. Come on, don't you remember back when

Re: [aqm] CoDel: After much ado ...

t importantly, I want to personally thank the fq_codel authors for sending > me > Yerba Mate, Dave Taht for sending me delicious freshly-baked cookies, and Paul > McKenney for sending me a ton of organic green tea to help me move on the > document. I will say that you all managed t

[aqm] I am setting up a per holiday cron job

the template: For [INSERT HOLIDAY], I'd really love to see a codel & fq_codel RFC published. -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ aqm mailing list aqm@ietf.org

[aqm] make-wifi-fast linuxplumbers talk summary on lwn.net

and available here: https://lwn.net/SubscriberLink/705884/1bdb9c4aa048b0d5/ After the talk I discussed with several folk about applying the same debloating techniques to other chipsets. I don't remember, unfortunately, who all those folk were, nor the candidate chipsets! We are still wrestling

[aqm] "Globally, the average loss rates on policed flows are over 20%"

And while I'm catching up on my academic backlog (scholar.google.com has a ton of newer things on it about bufferbloat), this report on the effects of policing was pretty good: http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45411.pdf On Wed, Aug 3, 2016 at 3:37

[aqm] transport protocols in userspace

good discussion of a new feature for linux, proposed by facebook, that will make it much easier to write protocols in userspace, the positives, and negatives. https://lwn.net/SubscriberLink/691887/9388e53741d4c93e/ Please don't discuss on this list, I've had a bad morning already. -- Dave Täht

[aqm] A bit of history on RFC970 and RFC896 from john nagle

-- Forwarded message -- From: John Nagle Date: Thu, Apr 14, 2016 at 7:14 PM Subject: Re: Bufferbloat and FQ and you To: Dave Taht <dave.t...@gmail.com> Cc: ro...@cisco.com On 04/14/2016 03:33 PM, Dave Taht wrote: > > https://www.rfc-editor.org/rfc/rfc7806.txt was pub

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

this point are behaviors below ~2mbit sans tuning, and the ecn support, for which we have research ongoing in cake that we can easily fold back into fq_codel if we need to. > > > Bob > > > > On 22/03/16 04:41, Dave Taht wrote: >> >> I don't even know where to start b

Re: [aqm] Alia Atlas' No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

On Thu, Mar 17, 2016 at 10:13 AM, Toke Høiland-Jørgensen wrote: > "Alia Atlas" writes: > >> -- >> COMMENT: >> -- >> >> I think

Re: [aqm] working group last call on CoDel drafts

In just about every benchmark we have created to date, the linux version of the codel implementation wins over dozens of attempted alternatives. We have one that is mildly better at a 10ms RTT, but not as good at 80ms, but that's it. This doesn't mean that more experimentation isn't called for

Re: [aqm] CoDel's control law that determines drop frequency

seen to not be adequately affecting traffic, and the pre-calculated > 1/sqrt(count) can then be divided by sqrt(2) (i.e., do not rely on the newton > step approximation for this modification of count). > > Cheers, > --Jeff > > > > > /dev/jeff_weeks.x2936

[aqm] Catching up on diffserv markings

I unsubscribed from rmcat and rtcweb groups a while back after I got overloaded, and appear.in started working so well, (for both ipv6 and ipv4! I use it all day long now!), to focus on finishing up the new "cake" qdisc/shaper/aqm/QoS system, among other things.

[aqm] one way to truly screw up ecn - is to mark CE on all packets

https://forums.developer.apple.com/thread/16699 Unitymedia sets “CE” on all packets. And totally messes up a vpn that adheres to bob's guidelines regarding encapsulation. Sigh. Can someone call those guys and straighten them out? -- Dave Täht Do you want faster, better, wifi?

[aqm] Last call for signatures to the FCC on the wifi lockdown issue

?usp=sharing The principal signers (Dave Taht and Vint Cerf), are joined by many network researchers, open source developers, and dozens of developers of aftermarket firmware projects like OpenWrt. Prominent signers currently include: Jonathan Corbet, David P. Reed, Dan Geer, Jim Gettys, Phil

[aqm] FCC vs Wifi: The cerowrt letter to the FCC about the wifi firmware lockdown issue is nearly final

We go into a lot of bufferbloat and homenet stuff... it is my hope others involved in these efforts would be willing to add their voice to the mix, either by signing, commenting, or producing your own letters. For your comments, please see the current draft, and especially the 5 mandates at the

Re: [aqm] CoDel's control law that determines drop frequency

On Wed, Sep 30, 2015 at 1:50 AM, Bob Briscoe wrote: > Andrew, > > I am also not so interested in an AQM dealing directly with unresponsive > traffic - I prefer to keep policing and AQM as separately deployable > functions, because AQM should be policy-neutral, whereas

Re: [aqm] WGLC on draft-ietf-aqm-eval-guidelines

On Tue, Aug 18, 2015 at 3:03 PM, Roland Bless roland.bl...@kit.edu wrote: Hi, Am 10.08.2015 um 15:43 schrieb Wesley Eddy: As chairs, Richard and I would like to start a 2-week working group last call on the AQM characterization guidelines:

[aqm] cake status ( was Codel's count variable and re-entering dropping state at small time intervals)

I would like to stress that cake is a work in progress, taking place with very limited resources - jonathon's funding ran out last month and we've had to scramble to keep a floor under him F/T, toke is contributing his testbed and test scripts that he used for The good the bad and the wifi,

Re: [aqm] [tsvwg] New Liaison Statement, Explicit Congestion Notification for Lower Layer Protocols

Is there anyone doing ECN outreach also to IEEE 802.11? On Tue, Jul 21, 2015 at 10:42 AM, Liaison Statement Management Tool l...@ietf.org wrote: Title: Explicit Congestion Notification for Lower Layer Protocols Submission Date: 2015-07-20 URL of the IETF Web page:

[aqm] quick comment on aqm-eval-guidelines

From each of these sets of measurements, the 10th and 90th percentiles and the median value SHOULD be computed. For each scenario, a graph can be generated, with the x-axis showing the end- to-end delay and the y-axis the goodput. This graph provides part of a better understanding

Re: [aqm] FQ-PIE kernel module implementation

On Fri, Jul 3, 2015 at 11:22 AM, Fred Baker (fred) f...@cisco.com wrote: On Jul 3, 2015, at 10:56 AM, Dave Taht dave.t...@gmail.com wrote: There are also weighted FQ systems (like qfq+ + pie or codel) under development. Actually, A WFQ system has been in Cisco product for 20 years, and I

Re: [aqm] FQ-PIE kernel module implementation

On Fri, Jul 3, 2015 at 2:52 AM, Fred Baker f...@cisco.com wrote: On Jul 3, 2015, at 2:45 AM, Polina Goltsman uu...@student.kit.edu wrote: As I understand the FQ-Codel draft, it seems to be fundamental to FQ-Codel that each queue has separate state variables. So my question is: is it indeed

Re: [aqm] Questioning the goal of a hard delay target

On Fri, Jul 3, 2015 at 10:42 AM, Bob Briscoe i...@bobbriscoe.net wrote: Simon, Y, if you're going to start autoadjusting a hard-coded parameter, you have to first question whether it was right to choose that parameter to hard-code in the first place. In codel, target was never a hardcoded

Re: [aqm] tackling torrent on a 10mbit uplink (100mbit down)

sometimes I pick the wrong week to actually try to benchmark a protocol in the wild. https://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-flood-150619/ On Fri, Jun 19, 2015 at 9:01 AM, Dave Taht dave.t...@gmail.com wrote: I just downloaded and seeded 4 popular torrents

[aqm] loss + ect

After subjecting myself to the cable dslreports.com/speedtest on a 1mbit link,against current implementations of codel and fq_codel (no overload protection), pie and cake (overload protection)... and witnessing the carnage... ...I kind of think transports should treat loss with ect(3) also being

[aqm] tackling torrent on a 10mbit uplink (100mbit down)

I just downloaded and seeded 4 popular torrents overnight using the latest version of the transmission-gtk client. I have not paid much attention to this app or protocol of late (about 2.5 years since last I did this), I got a little sparked by wanting to test cdg, but did not get that far. Some

Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt

for many positive bullet points in the present document I can think of a negative counter-example in the real world that needs to be defeated in detail. Just off the top of my head: 3.2 tinc, when carrying tos, encapsulates the ecn markings also and does not apply them properly according to the

Re: [aqm] CoDel on high-speed links

Taht Cc: Jonathan Morton; aqm@ietf.org; Steven Blake Subject: Re: [aqm] CoDel on high-speed links On 6/14/2015 10:26 PM, Dave Taht wrote: On Sun, Jun 14, 2015 at 4:10 PM, Simon Barber si...@superduper.net wrote: Indeed - I believe that Codel will drop too much to allow maximum bandwidth

Re: [aqm] CoDel on high-speed links

not looked at the very long rtt problem in several years, and since then tcps, in particular have changed muchly (pacing in particular) Thanks, Anil -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Monday, June 15, 2015 7:57 PM To: Agarwal, Anil Cc: Simon Barber

Re: [aqm] CoDel on high-speed links

On Sun, Jun 14, 2015 at 4:10 PM, Simon Barber si...@superduper.net wrote: Indeed - I believe that Codel will drop too much to allow maximum bandwidth utilization, when there are very few flows, and RTT is significantly greater than target. Interval. Not target. Interval defaults to 100ms.

Re: [aqm] CoDel on high-speed links

...@ietf.org] On Behalf Of Steven Blake Sent: Tuesday, June 09, 2015 4:40 PM To: Dave Taht Cc: aqm@ietf.org Subject: Re: [aqm] CoDel on high-speed links On Tue, 2015-06-09 at 12:44 -0700, Dave Taht wrote: The below makes several mis-characterisations of codel in the first place

Re: [aqm] CoDel on high-speed links

On Tue, Jun 9, 2015 at 10:14 AM, Simon Barber si...@superduper.net wrote: My concern with fq_codel is that by putting single flows into single Codel instances you hit the problem with Codel where it limits bandwidth on higher RTT paths. I recently did a bit of work, testing rtt_fairness from

Re: [aqm] CoDel on high-speed links

The below makes several mis-characterisations of codel in the first place, and then attempts to reason from there. On Tue, Jun 9, 2015 at 9:11 AM, Steven Blake slbl...@petri-meat.com wrote: I have a question about how CoDel (as defined in draft-ietf-aqm-codel-01) behaves on high-speed (e.g., =

Re: [aqm] FQ-PIE kernel module implementation

On Thu, Jun 4, 2015 at 3:06 PM, Hironori Okano -X (hokano - AAP3 INC at Cisco) hok...@cisco.com wrote: Hi all, I’m Hironori Okano and Fred’s intern. I’d like to let you know that I have implemented FQ-PIE as a linux kernel module “fq-pie and iproute2 for fq-pie. This was done in

[aqm] big science discovers sch_fq and pacing

https://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/ -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast ___ aqm mailing list aqm@ietf.org

Re: [aqm] AQM hurts utilization with a single TCP stream?

On Fri, May 22, 2015 at 11:42 PM, Jonathan Morton chromati...@gmail.com wrote: In practice, I haven't noticed any loss of throughput due to using Codel on 100ms+ RTTs. Probably most servers now use CUBIC, which contributes to that impression. There are only slight differences between these

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

On Thu, May 21, 2015 at 10:18 PM, Simon Barber si...@superduper.net wrote: On 5/18/2015 10:00 AM, Dave Taht wrote: LEDBAT was probably my first concern and area of research before entering this project full time. I *knew* we were going to break ledbat, but the two questions were: how badly

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

On Mon, May 18, 2015 at 8:54 AM, Jonathan Morton chromati...@gmail.com wrote: On 18 May, 2015, at 18:27, Simon Barber si...@superduper.net wrote: Apparently a significant chunk of bittorrent traffic and Windows updates use these techniques to deprioritise their traffic. Widespread adoption

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

On Mon, May 18, 2015 at 8:27 AM, Simon Barber si...@superduper.net wrote: Thank you Mikeal, these are useful observations about the choice of exact DSCP value and various potential impacts. I agree that ultimately without operator agreement non of this matters. I do think that an important step

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

On Tue, May 12, 2015 at 9:17 PM, Simon Barber si...@superduper.net wrote: Hi Wesley, Thanks for considering my comments, and apologies for being so late in the process - I've only recently been able to put time into this area, and I understand it may be too late in the process to hack things

Re: [aqm] splat start?

://www.bell-labs.com/researchers/537/ thesis here. But I will need a spare weekend to read it. http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf I guess he can further comment on this own (cc’ed). Mirja Am 10.05.2015 um 04:18 schrieb Dave Taht dave.t...@gmail.com

[aqm] splat start?

One of the things bugging me lately is that we actually have a lot of forms of slow start on the table - HyStart, Initial Spreading, reno vs cubic, dctcp, IW2, IW4, IW10, TSO offloads, the effect of GRO on it, etc. I dont know what is in QUIC, either. I would love a comprehensive guide to exactly

Re: [aqm] ECN AQM parameters

On Sat, May 9, 2015 at 10:20 AM, Bob Briscoe bob.bris...@bt.com wrote: Dave, As promised, here's my thoughts on what PIE (and CoDel) should do when ECN is enabled. There's also new info in here that I think is important: CoDel uses an RTT estimate in two different places. One has to be the

Re: [aqm] ECN AQM parameters

I am looking over the rest of your email. It is a lot to absorb... but: I have no interest in solving this problem, because I wouldn't start from CoDel in the first place - I would never design an AQM that switches between discrete modes, and CoDel's control law assumes that the e2e congestion

Re: [aqm] draft-ietf-aqm-pie-01: review

Dear Bob: I now understand the linux codebase for pie a lot better, as well as some of the experimental data I have. It looks like I could make several of the changes you describe and put them in my next series of tests, and based on your parameters I should be able to exercise some edge cases

[aqm] bob's summary of ecn and aqm use cases

I thought every bullet point here was marvelous: http://www.ietf.org/mail-archive/web/aqm/current/msg01118.html and would like to see it captured in a formal document somewhere if it is not captured in the ecn advocacy document. I have only three quibbles, one kind of major. re: #5

Re: [aqm] [homenet] IEEE 1905.1 and 1905.1a

up until this moment I had never heard of http://en.wikipedia.org/wiki/IEEE_1905 this spec, and it does sound useful. +10 on more open access to it. +100 on anyone working on open source code for it. I would certainly like closer relationships between the IEEE and IETF one day, perhaps even a

[aqm] comcast research funding tracks

http://techfund.comcast.com/ has quite a few topics on it that might be of interest to those working on networking and bufferbloat. I am going to put in for a bit of funding from there myself, but certainly others here have the right interests, but not the time or money to pursue their interests,

[aqm] fixing bufferbloat on bigpond cable...

I was very pleased to see this tweet go by today: https://twitter.com/mnot/status/575581792650018816 where Mark Nottingham fixed his bufferbloat on bigpond cable using a very simple htb + fq_codel script. (I note ubnt edgerouters also have a nice gui for that, as does openwrt) But: he does

Re: [aqm] fixing bufferbloat on bigpond cable...

out a bit. Thx for all the work on http/2! How about some ecn? ;) On Wed, Mar 11, 2015 at 7:14 PM, Mark Nottingham m...@mnot.net wrote: Hi, Just to clarify -- the credit goes to 'saltspork' on that thread, not I :) Cheers, On 12 Mar 2015, at 1:11 pm, Dave Taht dave.t...@gmail.com wrote: I

Re: [aqm] fixing bufferbloat on bigpond cable...

? On Wed, Mar 11, 2015 at 7:23 PM, Dave Taht dave.t...@gmail.com wrote: Sorry, didn't read the thread closely. I made a few suggestions on that person's gist, as you probably also have downstream bufferbloat as well, which you can fix (on the edgerouter and openwrt) at speeds up to 60mbit on those

Re: [aqm] a test post on a thread that disappeared

On Sat, Mar 7, 2015 at 12:14 PM, Dave Taht dave.t...@gmail.com wrote: I was wondering why a certain thread did not show up in the ietf aqm archive, http://www.ietf.org/mail-archive/web/aqm/current/maillist.html and now, stripping out the urls with an invalid cert, also as a test. Sorry

Re: [aqm] [Cerowrt-devel] ping loss considered harmful

I had spoken to someone at nznog that promised to combine mrtg + smokeping or cacti + smokeping so as to be able to get long term latency and bandwidth numbers on one graph. cc added. On Thu, Mar 5, 2015 at 12:38 PM, Matt Taggart m...@lackof.org wrote: Dave Taht writes: wow. It never

Re: [aqm] the cisco pie patent and IETF IPR filing

Disaster report: https://www.youtube.com/watch?v=6Rwcbsn19c0 -Vishal -- http://www.cs.columbia.edu/~misra/ On Mar 4, 2015, at 1:07 AM, Dave Taht dave.t...@gmail.com wrote: Two items: A) The IETF IPR filing http://datatracker.ietf.org/ipr/2187/ points to the wrong patent: 13/874,500. A google

Re: [aqm] the cisco pie patent and IETF IPR filing

On Wed, Mar 4, 2015 at 2:08 PM, Rong Pan (ropan) ro...@cisco.com wrote: The correct Cisco IPR is http://datatracker.ietf.org/ipr/2540/. Thank you very much for the pointer to the correct IPR filing. I apologize for being grumpy. -- Dave Täht Let's make wifi fast, less jittery and reliable

Re: [aqm] [Bloat] ping loss considered harmful

On Tue, Mar 3, 2015 at 10:00 AM, Fred Baker (fred) f...@cisco.com wrote: On Mar 3, 2015, at 9:29 AM, Wesley Eddy w...@mti-systems.com wrote: On 3/3/2015 12:20 PM, Fred Baker (fred) wrote: On Mar 1, 2015, at 7:57 PM, Dave Taht dave.t...@gmail.com mailto:dave.t...@gmail.com wrote: How can

[aqm] speedtest-like results for 3g and 4g at ofcom

Anybody know anybody here that could ask them to run a valid latency under load test? http://media.ofcom.org.uk/news/2014/3g-4g-bb-speeds/ -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [aqm] Gathering Queue Length Statistics

On Wed, Feb 25, 2015 at 9:53 AM, Ryan Doyle rpdo...@live.unc.edu wrote: Hello, I am a senior undergraduate student at the University of North Carolina at Chapel Hill and am studying the effectiveness of AQMs. I have set up a lab network and plan on running different sets of experiments with

Re: [aqm] PIE implementation on NS2

pie, codel, sfq_codel, codel-dt and other variants are all part of the upcoming ns2 release. A release candidate is here: http://nsnam.isi.edu/nsnam/index.php/Roadmap codel ended up in the september release of ns3-21, the fq_codel variant is being merged (hopefully) in the 3.22 release, present

[aqm] incorrect defaults for RED in ns2 cross check

I am curious if those of you fiddling with RED have been setting q_weight in your simulations and papers, overriding the incorrect ns2 default? Similarly, those of you testing ARED, making sure the adaptive parameter is really on? ... and if someone can come up with a way of a validating correct

Re: [aqm] RED implementation on Linux 3.14.22

haven't been following the evolution of the implementation, I would like to ask about your experience with the code on Linux 3.14 (and newer). I know that Dave Taht ran into bugs in RED a while back, which I believe have been fixed for quite a while. The power of git to answer questions

Re: [aqm] RED implementation on Linux 3.14.22

On Mon, Dec 15, 2014 at 7:54 AM, Dave Taht dave.t...@gmail.com wrote: On Mon, Dec 15, 2014 at 5:41 AM, Jim Gettys j...@freedesktop.org wrote: On Mon, Dec 15, 2014 at 2:51 AM, Simone Ferlin-Oliveira fer...@simula.no wrote: All, I am doing some work with shared bottleneck detection

Re: [aqm] analysis paper on PIE...

On Wed, Nov 12, 2014 at 4:03 PM, Scheffenegger, Richard r...@netapp.com wrote: Hi Martin, I believe these papers may qualify that requirement: http://ipv6.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf This documents the docsis-pie implementation which has rather a few basic

Re: [aqm] adoption call: draft-welzl-ecn-benefits

, but if it's going to talk about something like ECN I believe it will have to include a summary of the main items on such a roadmap to be concrete. more inline... At 00:38 12/08/2014, John Leslie wrote: (I have read Michael's reply to this, but I'll respond here.) Dave Taht dave.t...@gmail.com

[aqm] Sane analysis of typical traffic

and/or fun, can both wreck the couch potatoes' internet experience, and have his own, wrecked also. Additional inline clarifications below. -Shahid. -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Monday, July 14, 2014 2:00 PM To: Akhtar, Shahid (Shahid) Cc

Re: [aqm] Obsoleting RFC 2309

On Mon, Jul 14, 2014 at 11:23 AM, Fred Baker (fred) f...@cisco.com wrote: On Jul 14, 2014, at 11:08 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Hi Fred, All, Let me an additional thought to this issue. Given that (W)RED has been deployed extensively in operators'

Re: [aqm] [iccrg] Fwd: New Version Notification for draft-irtf-iccrg-tcpeval-01.txt

I like what I see here. I will have a few suggestions for the text after the (USA) holiday... On Jul 4, 2014 5:11 AM, David Ros d...@simula.no wrote: Dear all, After a long hiatus, we have finally posted an update to the TCP evaluation suite. Comments are welcome. Besides mostly editorial

[aqm] aqm conference call results?

there some slides presented that I'd like to refer to as to the aqm evaluation guide's directions that I'd like to see again. Link? As it is being broken up into an overview and a second document detailing tests, I'd like people to look over the tests proposed in

Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt

On Tue, Jun 24, 2014 at 1:01 PM, Fred Baker (fred) f...@cisco.com wrote: On Jun 24, 2014, at 12:45 PM, Daniel Havey dha...@yahoo.com wrote: So IMHO it really doesn't matter except in the weird corner case where a a running flow has already bloated the queue and then we switch on the AQM.

Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt

On Tue, Jun 24, 2014 at 1:48 PM, Fred Baker (fred) f...@cisco.com wrote: On Jun 24, 2014, at 1:33 PM, Daniel Havey dha...@yahoo.com wrote: There may be scenarios where the interaction of the interval, the RTT and the bandwidth cause this to happen recurringly constantly underflowing the

[aqm] AQM in every buffer?

In the other long thread, gorry said something that didn't quite ring true with me: Our goal should be AQM in every buffer. Well, that's somewhat desirable but not doable (at least in my world) - 1) The device has sufficient buffering to get at least one packet out. 2) There's a tx ring which

Re: [aqm] AQM conference call - June 24

On Mon, Jun 2, 2014 at 8:19 AM, Wesley Eddy w...@mti-systems.com wrote: Hello, we're planning on holding an AQM conference call on June 24 at 1PM US/Eastern time. We'll publish webex/telecon coordinates closer to the day. This is just a notification for calendar planning purposes. I don't

Re: [aqm] last call results on draft-ietf-aqm-recommendation

I agree with the complement language. I don't mind if they are separable. Integration, however, is highly advantagous. I started another thread on the backlog issue. Because scheduling requires policy and AQM doesn't. Machine gunning down packets randomly until the flows start to behave

Re: [aqm] chrome web page benchmarker fixed

Doug Orr recommended to us that we give http://www.chromium.org/developers/telemetry a shot in generating reproducible web traffic models. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] the side effects of 330ms lag in the real world

On Tue, Apr 29, 2014 at 12:56 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Tue, 29 Apr 2014, Fred Baker (fred) wrote: A couple points here. 1) The video went viral, and garnered over 600,000 new hits in the 12 hours since I posted it here. there is pent up demand for less latency. While

Re: [aqm] [Bloat] the side effects of 330ms lag in the real world

On Tue, Apr 29, 2014 at 9:44 AM, Jim Gettys j...@freedesktop.org wrote: On Tue, Apr 29, 2014 at 3:56 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Tue, 29 Apr 2014, Fred Baker (fred) wrote: Well, we could discuss international communications. I happen to be at Infocom in Toronto,

Re: [aqm] [Bloat] the side effects of 330ms lag in the real world

On Tue, Apr 29, 2014 at 10:01 AM, Toke Høiland-Jørgensen t...@toke.dk wrote: Jim Gettys j...@freedesktop.org writes: Now, if someone gives me real fiber to the home, with a real switch fabric upstream, rather than gpon life might be somewhat better (if the switches aren't themselves

[aqm] the side effects of 330ms lag in the real world

pretty wonderful experiment and video http://livingwithlag.com/ -- Dave Täht ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] chrome web page benchmarker fixed

On Fri, Apr 18, 2014 at 1:41 PM, Greg White g.wh...@cablelabs.com wrote: On 4/18/14, 1:05 PM, Dave Taht dave.t...@gmail.com wrote: On Fri, Apr 18, 2014 at 11:15 AM, Greg White g.wh...@cablelabs.com wrote: The choice of RTTs also came from the web traffic captures. I saw RTTmin=16ms, RTTmean

Re: [aqm] chrome web page benchmarker fixed

On Fri, Apr 18, 2014 at 11:15 AM, Greg White g.wh...@cablelabs.com wrote: Dave, We used the 25k object size for a short time back in 2012 until we had resources to build a more advanced model (appendix A). I did a bunch of captures of real web pages back in 2011 and compared the object size

[aqm] The Effect of Network and Infrastructural Variables on SPDY's Performance

Last night's reading was quite good: http://arxiv.org/pdf/1401.6508.pdf As RTT goes up, it becomes increasingly expensive for HTTPS to establish separate connections for each resource. Each HTTPS connection costs one round trip on TCP handshaking and a further two on negotiating SSL setup. SPDY

Re: [aqm] chrome web page benchmarker fixed

to be able to have a simple load generator that exercises the browsers and generates some results, however dubious. Cheers. On Thu, Apr 17, 2014 at 10:49 AM, Dave Taht dave.t...@gmail.com wrote: Getting a grip on real web page load time behavior in an age of sharded websites, dozens of dns lookups

Re: [aqm] [AQM Evaluation Guidelines]

On Tue, Apr 15, 2014 at 6:57 AM, Nicolas KUHN nicolas.k...@telecom-bretagne.eu wrote: Thank you for detailing the content of the Cable Labs document and where these 700kB come from. Concerning your last point: As such I would be strongly in favour of changing the draft to actually describe

Re: [aqm] working group LAST CALL on recommendations draft

I still don't support wglc. a) Nit: Network Working Group? b) I have given up on using the term AQM to describe anything other than Active Queue Length Management algorithms. What I wrote about SQM is mostly outside the scope of the AQM guidelines document, but it's here:

Re: [aqm] packet loss (and therefore ECN) might not happen much actually

I'd be very interest in DNS request/reply analysis of that traffic. On Fri, Mar 21, 2014 at 9:27 PM, Fred Baker (fred) f...@cisco.com wrote: On Mar 4, 2014, at 9:12 AM, Eggert, Lars l...@netapp.com wrote: it looks like (in japan at least) TCP is very rarely controlled by packet loss (dupack

[aqm] stochastic hashing in hardware with a limited number of queues

The thread on netdev starting here: http://comments.gmane.org/gmane.linux.network/307532 was pretty interesting, where a research group at suny looked hard at the behavior of a 64 hw queue system running giant flows: http://www.fsl.cs.sunysb.edu/~mchen/fast14poster-hashcast-portrait.pdf They

Re: [aqm] Notes

and comments transcribed? The technology exists... Dave Taht: Care a lot about inter-flow packet loss. Bursty is really bad. Like to have a metric on inter flow loss This reminds me of an old far side joke. http://hubpages.com/hub/Gary-Larson#slide209782 Substitute Packet loss for Ginger here. What

Re: [aqm] Draft Agenda for IETF89

On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl mich...@ifi.uio.no wrote: 14:40 draft-fairhurst-ecn-motivation Gorry Fairhurst 15 min This is apparently not a published draft yet. It's draft-welzl-ecn-benefits, http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 It describes the

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-02.txt

On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) f...@cisco.com wrote: Gorry and I have posted a second update to the AQM Recommendations draft discussed at IETF 88. This update mostly picks up nit-level matters. We, of course, invite review, and would suggest that reviews look at this

[aqm] some comments I'd made on the cablelabs study privately

Since that study and test design were highly influential on the AQM requirements draft, I am going to publish now here what my comments were at the time, with a couple updates here and there I am not sure if any of the ns2 code from the last round made it out to the public. ? * Executive

Re: [aqm] Prefatory comments re draft-aqm-reccommendation and -evaluation, and a question

On Thu, Jan 23, 2014 at 1:10 AM, Fred Baker (fred) f...@cisco.com wrote: No, you're not blowing smoke. I'm not sure I would compare the behavior to PMTUD, as in that the endpoint is given a magic number and manages to it, where in this case, it is given the results of its behavior, and it

Re: [aqm] Prefatory comments re draft-aqm-reccommendation and -evaluation, and a question

On Thu, Jan 23, 2014 at 1:15 AM, Dave Taht dave.t...@gmail.com wrote: On Thu, Jan 23, 2014 at 1:10 AM, Fred Baker (fred) f...@cisco.com wrote: No, you're not blowing smoke. I'm not sure I would compare the behavior to PMTUD, as in that the endpoint is given a magic number and manages

Re: [aqm] Text for aqm-recommendation on independent ECN config

scheduling systems. On Thu, Dec 12, 2013 at 4:05 PM, Bob Briscoe bob.bris...@bt.com wrote: Dave, At 22:11 12/12/2013, Dave Taht wrote: but quickly... Bob, I object to your characterization of users links being busy 1-3% of the time. That's an average. I said it was an average. You're