Re: [aqm] [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1

> On Mar 2, 2016, at 12:53 PM, Alan Jenkins > wrote: > > Google avoid the bursts you describe, using pacing. I have been an advocate of pacing during the first transmission burst (including after an idle period) for quite some time, and also for

Re: [aqm] [Bloat] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1

> On Feb 27, 2016, at 11:04 AM, Dave Täht wrote: > > https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs244-14-confused-timid-and-unstable-picking-a-video-streaming-rate-is-hard/ > >> o the results are very poor with a particular popular AQM > > Define "very poor".

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

On Jan 22, 2016, at 10:47 AM, Wesley Eddy wrote: > I do also (personally) think that if there's a desire to go standards-track > (rather than just experimental) with AQM algorithms, that having a fairly > explicit evaluation of the algorithms with regard to the guidelines

[aqm] Fwd: New Version Notification for draft-ietf-aqm-fq-implementation-05.txt

FYI. I posted -04 in response to the GEN-ART review, and a nit was pointed out. This fixes a reference. > Begin forwarded message: > > From: > Subject: New Version Notification for draft-ietf-aqm-fq-implementation-05.txt > Date: November 2, 2015 at 4:07:33 PM GMT+9 >

Re: [aqm] Alia Atlas' Yes on draft-ietf-aqm-fq-implementation-03: (with COMMENT)

> On Oct 21, 2015, at 6:22 PM, Alia Atlas wrote: > > Alia Atlas has entered the following ballot position for > draft-ietf-aqm-fq-implementation-03: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC

Re: [aqm] Alia Atlas' Yes on draft-ietf-aqm-fq-implementation-03: (with COMMENT)

l to the point of the draft (or it would have > been > a Discuss), but I still would strongly prefer accuracy. I can include a link to http://www.isi.edu/nsnam/ns/doc/node643.html#Brow88:Calendar <http://www.isi.edu/nsnam/ns/doc/node643.html#Brow88:Calendar> if that helps. > Regar

Re: [aqm] ACK Suppression

> On Oct 8, 2015, at 11:34 AM, David Lang wrote: > >> If ack reductions are so very valuable, what's the chance of doing that on >> an end to end basis instead of in the network? > > a little less than the chance of shutting off IPv4 :-) Hey, we can dream, can't we? :-) >

Re: [aqm] ACK Suppression

I'm not sure why this discussion is happening on aqm@ instead of tcpm@... I have added cpm to the cc line, and would recommend that anyone responding to this thread do the same and remove aqm@. On Oct 7, 2015, at 2:13 PM, David Lang wrote: > So things that reduce the flow of

Re: [aqm] FQ-PIE kernel module implementation

On Jul 3, 2015, at 11:25 AM, Dave Taht dave.t...@gmail.com wrote: yep! Sorry! What is the current limit on number of queues, however? At what point do we declare this a rathole and return to the algorithm? signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [aqm] FQ-PIE kernel module implementation

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 wrote one at a different company four years earlier. having FQ systems be

Re: [aqm] FQ-PIE kernel module implementation

On Jul 2, 2015, at 4:21 PM, Toke Høiland-Jørgensen t...@toke.dk wrote: This is, as far as I can tell from your explanation, different than what fq_pie does. OK, apologies for the misinformation. In any event, the matter is not fundamental to fair queuing. signature.asc Description:

Re: [aqm] FQ-PIE kernel module implementation

On Jun 10, 2015, at 1:56 AM, Polina Goltsman uu...@student.kit.edu wrote: Hello all, If I understood the code correctly, in fq_pie there is a single PIE instance that controls all fq queues. In contrast in fq_codel there is a separate instance of codel for each queue. Is this the case?

Re: [aqm] [Bloat] FQ-PIE kernel module implementation

On Jun 5, 2015, at 11:02 AM, Simon Barber si...@superduper.net wrote: Very cool. Does this mean that Cisco are not planning on enforcing any IP rights over PIE? I think Cisco stands by its IPR statement on the topic. Simon On 6/4/2015 3:06 PM, Hironori Okano -X (hokano - AAP3 INC at

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

On May 24, 2015, at 11:02 AM, Simon Barber si...@superduper.net wrote: Hi Roland, My recent attention to DSCP has come from looking at what correct mappings to 802.1D (now 802.1Q) would be. I have also run across a couple of comments that legacy IP Precedence maps CS1 - higher priority

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

On May 18, 2015, at 8:27 AM, Simon Barber si...@superduper.net wrote: Shortly, our investigation confirms the negative interference: while AQM fixes the bufferbloat, it destroys the relative priority among Cc protocols. I think I would phrase that a little differently. The concept of

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

On May 12, 2015, at 9:06 PM, Simon Barber si...@superduper.net wrote: Where would be the best place to see if it would be possible to get agreement on a global low priority DSCP? I’d suggest https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines for DiffServ Service Classes. J.

Re: [aqm] PIE (and CoDel) drafts: proposed standard vs informational?

On Apr 29, 2015, at 9:42 AM, Bob Briscoe bob.bris...@bt.com wrote: I volunteered to do a thorough review of the PIE draft, which I'm just writing up. One of the problems is that it says 'Proposed Standard' at the top, but it's written in an informational style. There is no normative

Re: [aqm] WGLC for draft-ietf-aqm-ecn-benefits

I similarly support the document. One comment, for Mikael. On Apr 24, 2015, at 2:25 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 24 Apr 2015, Wesley Eddy wrote: To keep moving forward with the set of documents, we'd like to start a Working Group Last Call on:

Re: [aqm] AQM and ECN in draft-ietf-aqm-recommendation-11

Bob/Gorry: Didn’t we have essentially the same comment a week or two ago? What was our resolution? I think it was a minor rewording that included a little more than s/threshold/parameters/, and which I worried was heading in the direction of a much bigger question - what parameters. Fred

Re: [aqm] Gathering Queue Length Statistics

I'd suggest looking at netperf. It doesn't measure the queue directly; it measures the latency that queue occupancy induces. However, at least in commercial equipment, this thing we call the queue may not be all in the same place... From: aqm

Re: [aqm] Gen-art LC review of draft-ietf-aqm-recommendation-08

in line. Regards, Elwyn On 05/01/15 20:32, Fred Baker (fred) wrote: On Jan 5, 2015, at 1:13 AM, go...@erg.abdn.ac.uk wrote: Fred, I've applied the minor edits. I have questions to you on the comments blow (see GF:) before I proceed. Gorry Adding Elwyn, as the discussion of his

Re: [aqm] Obsoleting RFC 2309

the requirements of being self-configuring/tuning, at the same time as it passes along others as PS or whatever. -Shahid. -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, July 14, 2014 2:06 AM To: John Leslie Cc: aqm@ietf.org

Re: [aqm] Obsoleting RFC 2309

On Jul 2, 2014, at 9:07 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Hi Wes, Can you share the update/text that John Leslie had suggested which Fred mentions in his comment. Thanks, -Shahid. I have attached the text John sent yesterday. It is derived from

Re: [aqm] Obsoleting RFC 2309

On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) f...@cisco.com wrote: On Jul 1, 2014, at 2:27 PM, Wesley Eddy w...@mti-systems.com wrote: John Leslie noticed that some of the things Bob Briscoe had mentioned stem from trying to work from RFC 2309 as the starting point. We have been planning

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

On Jun 23, 2014, at 6:32 AM, Scheffenegger, Richard r...@netapp.com wrote: as individual Hi Fred, thank you for writing this down; one aspect that gets referred to, but not made completely explicit in sections 3.2 and 3.3 is the interaction of the AQM / Queue signals with the

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

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 bandwidth. To be honest, the real concern is very long delay paths, and it

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

I’d be interested in comments on this. From: internet-dra...@ietf.org Subject: New Version Notification for draft-baker-aqm-sfq-implementation-00.txt Date: June 13, 2014 at 2:52:07 PM PDT To: Fred Baker f...@cisco.com, Rong Pan ro...@cisco.com, Fred Baker f...@cisco.com, Rong Pan

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

On Apr 29, 2014, at 3:08 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 28 Apr 2014, Dave Taht wrote: pretty wonderful experiment and video http://livingwithlag.com/ Just so that everybody realises that this is an advertisement. Also, what access method has 300 ms access

Re: [aqm] publishing algorithms

Makes sense to me. I do have one question. Per charter, in December we are supposed to Submit first algorithm specification to IESG for publication as Proposed Standard”. Would this be a change of direction for the charter? Note that I’m not pushing a given algorithm, nor am I convinced that

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

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 manages to improve that. But this is what I have rambled on about in threads

Re: [aqm] AQM schemes: Queue length vs. delay based

On Nov 13, 2013, at 2:43 PM, Anoop Ghanwani an...@alumni.duke.edu wrote: On Wed, Nov 13, 2013 at 12:14 PM, Naeem Khademi naeem.khad...@gmail.com wrote: Agreed only in general terms -- but what would be considered as packet burst and how would it be defined? This will probably have a

Re: [aqm] [tsvwg] Immediate ECN: Autotuning AQM for RTT

On Nov 13, 2013, at 10:48 AM, Fred Baker (fred) f...@cisco.com wrote: With CoDel, the key issue is the sqrt. As the algorithm is described, it happens in the data path - upon interval expiration, a packet is dropped, and a new interval is calculated in inverse proportion to the square root

Re: [aqm] IETF88 Fri 08Nov13 - 12:30 Regency B

On Nov 8, 2013, at 5:56 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: One of the the objectives of newer AQMs being defined here should be to minimize tuning, but we should recognize that likely tuning or some configuration cannot be eliminated altogether. FB:

[aqm] Recommendations Draft discussion

On Nov 5, 2013, at 3:02 PM, Scheffenegger, Richard r...@netapp.com wrote: As the mechanism update presentations took quite a bit longer than we had expected - and we appreciate the discussion these presentations have sparked - we agreed with Fred to have his presentation as the first agenda

Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

On Nov 4, 2013, at 2:03 PM, Bob Briscoe bob.bris...@bt.com wrote: Folks, Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest. And don't respond if we don't support it? :-) I have a very