Re: [aqm] New I-D: draft-briscoe-aqm-dualq-coupled-00.txt
Hi Yuchung, Bob, (w/o chair hat) Wouldn't be a sensible reaction, in the scenario sketched by Yuchung, to have at least one MSS memory available at all times for L4S queues, and drop from the classic queue if that cann't be guaranteed earlier? Best regards, Richard -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of John Leslie Sent: Samstag, 08. August 2015 13:41 To: Yuchung Cheng Cc: Bob Briscoe; AQM IETF list Subject: Re: [aqm] New I-D: draft-briscoe-aqm-dualq-coupled-00.txt Yuchung Cheng ych...@google.com wrote: Interesting work. Do the queues share the same memory pool? I don't believe the draft says one way or the other; but the concept would seem to call for separate memory. I hypothesize that with current ECN deployment, the bad (reno) guy will take up C_Q. What happens when the nice guy (dctcp) knocks the door when the house is full? the strict priority policy in the doc isn't clear about which butt to boot ... The pseudocode in Appendix A isn't the easiest to read; but it does show that the L4S queue goes out first (with CE marking) before the Classic queue. The draft is also clear that the example applies AQM on exit from the queues. Thus the Classic queue (in this example) could easily fill available memory; so your question is appropriate. The draft is a bit hand-wavy about what happens when there's too much L4S traffic. IMHO, _one_ necessary feature would be to limit the size of the L4S queue and drop L4S traffic that won't fit. -- John Leslie j...@jlc.net ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Minutes of the AQM WG session
Thank you Dave,
I'll update the minutes.
I believe the authors of DualAQM assume that all ECN traffic will have the less
drastic reaction as a default (with the hope of deploying this before
wide-spread use of legacy 3168 style ECN marking takes hold).
Also, thank you for your comments regarding FQ_codel and the reported linux
issue (which, as you note, may be due to an incorrect config setting in the
latest releases).
Regarding the identifier to differentiate legacy ECN (cc reaction on ECN per
RTT = cc reaction to loss in RTT) and the differentiated response (proportional
to the # of CEs per RTT) is an open question.
Perhaps we can start to gather the views of the group on this list already;
There have been other uses for ECT(1) been proposed over time, and it has also
been pointed out that repurposing a DiffServ Codepoint may not be the easierst
to do from a procedural view.
Also, I would like to encourage members of the aqm wg to review the various
versions of http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn (the
technical content did change in each version substancially). Disclaimer, I'm
one of the authors of that draft.
Best regards,
Richard
-Original Message-
From: Dave Taht [mailto:dave.t...@gmail.com]
Sent: Donnerstag, 23. Juli 2015 13:24
To: Scheffenegger, Richard
Cc: aqm@ietf.org
Subject: Re: [aqm] Minutes of the AQM WG session
1) in hard delay targets, I am credited with what matt mathis said (not
that I disagree).
2) In the dual queue thing I had noted that distinguishing between the two
queues based solely on the presence of ecn capability and then using dctcp
was non-sensical as plenty of other things like cubic would also end up
with ecn enabled.
3) and for the record, fq_codel as it exists today works reasonably well
when hammered with dctcp + ecn, cubic + ecn, and and any other stuff
without markings with the defaults. It may not give the desired reduction
in individual queue length - and cubic vs dctcp will do badly against each
other on a hash collision - but it is, at least, mostly safe were some
sysadmin finger foo things and push dctcp (or some other non traditional
cc) out on the world internet against fq_codel'd ecn-enabled systems.
4) If you can't tell, it *really bothers me* when someone reports a bug in
dctcp - at ietf - rather than through proper channels - particularly when
it leads to evil behavior on loss, and yet I have no patches submitted nor
means to reproduce it. PLEASE GET A PATCH OUT to the netdev maintainers,
it will be immediately put into the next release of linux AND backported
to the linux stable releases.
What I see is dctcp_clamp_alpha_on_loss not defaulting to on, which based
on the comments, should default to on. Is there somewhere else this is
busted?
static void dctcp_state(struct sock *sk, u8 new_state)
{
if (dctcp_clamp_alpha_on_loss new_state == TCP_CA_Loss) {
struct dctcp *ca = inet_csk_ca(sk);
/* If this extension is enabled, we clamp dctcp_alpha to
* max on packet loss; the motivation is that dctcp_alpha
* is an indicator to the extend of congestion and packet
* loss is an indicator of extreme congestion; setting
* this in practice turned out to be beneficial, and
* effectively assumes total congestion which reduces the
* window by half.
*/
5) Missing from the preso was the actual dual queue length, just a
comparison (cool demo tho!) - you get what queue length using curvy red?
6) cake, of course, gets to 100s of flows without hash collisions.
7) As I missed the tcp-prague discussion, is the proposal to reserve
ect(1) - the former nonce bit - for dctcp? or some other diffserv or
flowheader marking?
On Thu, Jul 23, 2015 at 8:56 AM, Scheffenegger, Richard r...@netapp.com
wrote:
Hi,
Thanks to David Schinazi for serving as the notes taker;
I've uploaded the minutes
https://www.ietf.org/proceedings/93/minutes/minutes-93-aqm
If you made a statement during the session, please review that the notes
capture the essence of what you wanted to convey!
Also, one name is missing (and I'm unable to replay the meetecho
recording currently) in the minutes, if you know who made that comment
please inform us chairs.
Thanks,
Richard (aqm chair)
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
[aqm] FW: [tsvwg] New Liaison Statement, Explicit Congestion Notification for Lower Layer Protocols
Title: Explicit Congestion Notification for Lower Layer Protocols Submission Date: 2015-07-20 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1424/ Please reply by 2015-10-30 From: Transport Area Working Group (David Black david.bl...@emc.com) To: 3GPP (susanna.koois...@etsi.org) Cc: Gonzalo Camarillo gonzalo.camari...@ericsson.com,Gorry Fairhurst go...@erg.abdn.ac.uk,Martin Stiemerling mls.i...@gmail.com,Spencer Dawkins spencerdawkins.i...@gmail.com,John Kaippallimalil john.kaippallima...@huawei.com,Bob Briscoe i...@bobbriscoe.net,Transport Area Working Group Discussion List ts...@ietf.org Response Contact: David Black david.bl...@emc.com Technical Contact: Bob Briscoe i...@bobbriscoe.net Purpose: For comment Body: To: 3GPP SA, 3GPP CT, 3GPP RAN, 3GPP SA4, 3GPP SA2, 3GPP RAN2 From: IETF TSVWG In 2001, the IETF introduced explicit congestion notification (ECN) to the Internet Protocol as a proposed standard [RFC3168]. The purpose of ECN was to notify congestion without having to drop packets. The IETF originally specified ECN for cases where buffers were IP-aware. However, ECN is now being used in a number of environments including codec selection and rate adaptation, where 3GPP protocols such as PDCP encapsulate IP. As active queue management (AQM) and ECN become widely deployed in 3GPP networks and interconnected IP networks, it could be incompatible with the standardized use of ECN across the end-to-end IP transport [RFC7567]. The IETF is now considering new uses of ECN for low latency [draft-welzl- ecn-benefits] that would be applicable to 5G mobile flows. However, the IETF has realized that it has given little if any guidance on how to add explicit congestion notification to lower layer protocols or interfaces between lower layers and ECN in IP. This liaison statement is to inform 3GPP, in particular those groups including those involved in 3GPP Release-10 work on the work item ECSRA_LA (TR23.860) - SA4, CT4, SA2 and RAN2. Please distribute to all groups that have used or plan to use IETF ECN /AQM RFCs in 3GPP specifications. The IETF has started work on guidelines for adding ECN to protocols that may encapsulate IP and interfacing these protocols with ECN in IP. Then IP may act in its role as an interoperability protocol over multiple forwarding protocols. This activity is led by the IETF's transport services working group (tsvwg). Actions: The IETF tsvwg kindly asks 3GPP: 1) to tell the IETF tsvwg which 3GPP working groups could be affected by this work. 2) To inform the IETF tsvwg of any specific 3GPP specifications affected by this work. 3) to forward this liaison statement to these affected working groups, and to invite them to review the latest draft of the guidelines, available here: http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap- guidelines Review comments are particularly welcome on: - comprehensibility for the 3GPP community - usefulness and applicability - technical feasibility Review comments may be posted directly to the IETF tsvwg mailing list mailto: ts...@ietf.org. Postings from non-subscribers may be delayed by moderation. Alternatively, subscription is open to all at: https://www.ietf.org/mailman/listinfo/tsvwg. The following IETF specifications or drafts are particularly relevant to this activity (the relevance of each of them is explained in the first item below): * draft-ietf-tsvwg-ecn-encap-guidelines * RFC3168 updated by RFC4301, RFC6040 (ECN in respectively: IP/TCP, IPsec IP-in-IP tunnels) * RFC6679 (ECN in RTP) * RFC5129 updated by RFC5462 (ECN in MPLS) * RFC4774 (Specifying alternative semantics for the ECN field) * RFC7567 (Recommendations Regarding Active Queue Management * draft-welzl-ecn-benefits (Benefits to Applications of Using ECN) Yours, --David L. Black (TSVWG co-chair) Attachments: No document has been attached ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] WGLC for draft-ietf-aqm-ecn-benefits
Hi Group, during the WGLC started end of April, the authors have received quite a bit of feedback. It's the chair's understanding that all the raised concerns have Been addressed in the lastest version of this document https://www.ietf.org/internet-drafts/draft-ietf-aqm-ecn-benefits-05.txt Therefore, we would like to start another WGLC overlapping the IETF meeting in Prague to agree that the recent changes did in fact address all the comments. Hopefully we can proceed with the document in the week after the IETF meeting. A short recap will be given during the AQM WG slot on Monday. If you have any concerns please speak up during the meeting, and please post to the list prior to Saturday, 25. July. Thanks, Wes Richard (aqm chairs) -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Freitag, 24. April 2015 06:38 To: aqm@ietf.org Subject: [aqm] WGLC for draft-ietf-aqm-ecn-benefits To keep moving forward with the set of documents, we'd like to start a Working Group Last Call on: http://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ Please send any comments you have on this document to the list by May 8th. Other than those raised in the thread Mirja has just opened with her review, I'm not aware of any other open issues. Thank you to everyone that's been following up on the reviews pledged at the last meeting! -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] agenda for IETF 93 / Prague
Hello AQMers! We have requested and were granted a short slot at IETF 93 in Prague, it's the last 1-hour slot on Monday evening: https://www.ietf.org/proceedings/93/agenda/agenda-93-aqm There has been some behind the scenes discussion on the ordering of the talks, and I'm afraid that this is probably close to where I made everyone equally unhappy. Draft authors and editors, and all others, please read the drafts, comment on this mailing list, and help us to review and complete them: https://datatracker.ietf.org/wg/aqm/documents/ http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf http://www.bobbriscoe.net/projects/latency/draft-briscoe-aqm-dualq-coupled-00.txt Thanks in advance, and see you in Prague! Best regards, Richard Scheffenegger ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] think once to mark, think twice to drop: draft-ietf-aqm-ecn-benefits-02
David, Perhaps you would care to provide some text to address the misconception that you pointed out? (To wait for a 100% fix as a 90% fix appears much less appealing, while the current state of art is at 0%) If you think that aqm-recommendations is not strogly enough worded. I think this particular discussion (to aqm or not) really belongs there. The other document (ecn benefits) has a different target in arguing for going those last 10%... Best regards, Richard Scheffenegger Am 27.03.2015 um 16:17 schrieb David Lang da...@lang.hm: On Fri, 27 Mar 2015, KK wrote: The discussion about adding buffers and the impact of buffers should be considered relative to the time scales when congestion occurs and when it is relieved by the dynamics of the end-system protocols. The reason we have buffering is to handle transients at the points where there is a mismatch in available bandwidth. We don¹t look to just throw buffers in front of a bottleneck for ?long run¹ overload. In theory you are correct. However in practice, you are wrong. throughput benchmarks don't care how long the data sits in buffers, so larger buffers improve the benchmark numbers (up until the point that they cause timeouts) But even if the product folks aren't just trying to maximize throughput, they size the buffers based on the worst case bandwidth/latency. So you have products with buffers that can handle 1Gb links with 200ms speed-of-light induces latency being used for 1.5Mb/768K 20ms DSL lines without any changes. I'm not saying that ECN doesn't provide value, but the statement that without ECN you have the choice of low-latency OR good througput is only true if you ignore what's in place today. It also does a dissservice because it implies that if you use something other than ECN, it's going to hurt your performance. This discourages people from enabling pie or fq_codel because they have read about how bad they are and how they will increase latency because they drop packets. This isn't just a theoretical someone may think this, I've seen this exact argument trotted out a couple times recently. While active queue management undoubtedly seeks to keep the backlog build-up at a manageable level so as to not allow latency to grow and still keep the links busy to the extent possible, the complement that ECN provides is to mitigate the impact of the drop that AQM uses to signal end-points to react to the transient congestion. ECN has the benefit when you have flows that have small windows, where the impact of loss is more significant. As you say, when a packet is lost it causes a 'large' amount of latency as the sender times out and retransmits, but if this is only happening every few thousand packets, it's a minor effect.². But this is the case for flows that are long-lived. If the flows are short-lived (and I believe empirical evidence suggests that they are a significant portion of the flows), then it is not a minor effect any more. Even an occasional lost packet in a short flow is a minor effect compared to the current status quo of high latency on all packets. Yes, many web pages are made up of many different items, fetched from many different locations, so avoiding packet losses on these flows is desirable. But it's even more important to keep latency low while the link is under load, otherwise your connections end up being serialized, which kills performance even more. As an example (just to be sure we are all talking about the same thing) user clicks a link DNS lookup small page fetch N resources to fetch, add to queue for each resource in the queue (up to M in parallel) DNS lookup (may be cached) page fetch (some small, some large, some massive) may trigger more resources to fetch that get added to queue it's common for there to be a few massive resources to fetch in a page that get queued early (UI javascript libraries or background images) If a packet gets lost from one of the large fetches, it doesn't have that big of an effect. If it gets lost from one of the small fetches, it has more of an effect. But if the first resource to be fetch causes latency to go to 500ms (actually a fairly 'clean' network by today's standards), then all of the DNS lookups, TCP handshakes, etc that are needed for all the other resources end up taking far longer than the time that would be lost due to a dropped packet. This is a better vs best argument. Nobody disputes that something like fq_codel/pie/cake/whatever + ECN would be better than just fq_codel/pie/cake/whatever, but the way this is being worded make it sound that static buffer sizes + tail-drop + ECN is better than fq_codel/pie/cake/whaever because these other queueing algorithms will cause packet loss. David Lang ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] adoption of draft-white-aqm-docsis-pie-01
Hi group, as there haven't been any objections, but some indications of support on the list, and based on the responses in the IETF92 meeting in Dallas, we chairs think this document can be adopted as WG-item at this time. Greg, can you please upload the most recent version as draft-ietf-aqm-docsis-pie-00? Also, as mentioned in the meeting, and to make true of my promise, I would like to invite the following individuals to review this draft, once the updated version becomes available. Mikael Abrahamsson Dave Dolson Szilveszter Nádas Mostly everybody else who has commented during the meeting is already assigned to other documents (Nobody will be left out :) Thanks, Richard (co-chair) -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Scheffenegger, Richard Sent: Donnerstag, 26. Februar 2015 08:45 To: Greg White; 'aqm@ietf.org' Cc: Rong Pan (ropan); aqm-cha...@tools.ietf.org Subject: Re: [aqm] adoption of draft-white-aqm-docsis-pie-01 Hi Greg, group, Regarding the adoption call, this is something we can actually (and should) start on the list. We can confirm that during the Dallas meeting in the room, but even before that, we'd like to get responses on the list now... Perhaps we have some volunteers to review this new version as well... Best regards, Richard -Original Message- From: Greg White [mailto:g.wh...@cablelabs.com] Sent: Donnerstag, 26. Februar 2015 01:13 To: aqm-cha...@tools.ietf.org Cc: Rong Pan (ropan) Subject: Re: [aqm] agenda for IETF 92 / Dallas Wes Richard, Unfortunately I will not be at IETF92 in person, but will attend remotely. For draft-white-aqm-docsis-pie, Rong I updated it in January and included a new appendix to give a change log, which reads: === Appendix B. Change Log B.1. Since draft-white-aqm-docsis-pie-01 Added Change Log. Removed discussion of Packet drop de-randomization, Enhanced burst protection, and 16ms update interval, as these are now included in [I-D.ietf-aqm-pie]. === Regarding WG adoption, I saw some support from Lars (and no objections) to adopting it on an Informational track. Will you do an official adoption call at the Dallas meeting? -Greg On 2/23/15, 8:40 PM, Wesley Eddy w...@mti-systems.com wrote: Greetings AQMers! We requested a short AQM meeting slot at the upcoming IETF 92 meeting in Dallas, and we received a 1-hour slot on Tuesday: https://datatracker.ietf.org/meeting/92/agenda.html Since this is not a lot of time, we'll need to prioritize the work that is discussed to what requires the face-to-face time in order to make progress on. For active draft editors, please let us know via this list or aqm-cha...@tools.ietf.org what you think your meeting time needs are, so we can put together an agenda. If you don't need meeting time now, or would like to use an interim telecon to assist in gathering feedback, please also let us know. For others, please read the drafts, comment on this mailing list, and help us to review and complete them: https://datatracker.ietf.org/wg/aqm/documents/ Thanks in advance! -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] IETF 92 slides
Hi, for some unknown reason, the slides are not properly linked here https://datatracker.ietf.org/meeting/92/materials.html#tsv Please find the links in the meantime here: Richard Scheffenegger Storage Infrastructure Architect NetApp Austria GmbH +43 676 6543146 Tel +43 1 3676811-3100 Fax r...@netapp.commailto:r...@netapp.com www.netapp.athttp://www.netapp.at [Unbound Cloud(tm)]http://www.netapp.com/au/campaigns/unboundcloud/index.aspx?ref_source=udf-cld--16113 Die neue Vision des Cloud- Datenmanagementshttp://www.netapp.com/de/campaigns/unboundcloud/index.aspx?ref_source=udf-cld--16117 [Description: Description: Description: Description: Description: Description: Facebook]http://www.facebook.com/NetAppAustria Facebookhttp://www.facebook.com/NetAppAustria [Description: Description: Description: Description: Description: Description: Twitter]http://twitter.com/NetAppAustria Twitterhttp://twitter.com/NetAppAustria [Description: Description: Description: Description: Description: Description: YouTube]http://www.youtube.com/user/NetAppTV YouTubehttp://www.youtube.com/user/NetAppTV [Description: Description: cid:image001.png@01CD2C88.A2795F10]http://www.xing.com/companies/netappaustriagmbh/about ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] IETF 92 slides
And, pressed the wrong button (or the right one too early): Here is the currently working link https://tools.ietf.org/wg/aqm/agenda Best regards, Richard From: Scheffenegger, Richard Sent: Dienstag, 24. März 2015 06:21 To: 'aqm@ietf.org' Subject: IETF 92 slides Hi, for some unknown reason, the slides are not properly linked here https://datatracker.ietf.org/meeting/92/materials.html#tsv Please find the links in the meantime here: Richard Scheffenegger ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] [Bloat] speedtest-like results for 3g and 4g at ofcom
Provided they share the whole set of data collected to the individual participants on their dashboard, they don't seem to be collecting anything other than UDP latency (without background load up or down) Richard -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Livingood, Jason Sent: Montag, 02. März 2015 15:41 To: Dave Taht; bloat; aqm@ietf.org Subject: Re: [aqm] [Bloat] speedtest-like results for 3g and 4g at ofcom This is run by SamKnows. They also run the FCC¹s tests and I asked them some time ago to develop a latency under load test but I am not sure it is deployed on test units. I will send contact info. On 2/28/15, 5:32 PM, Dave Taht dave.t...@gmail.com wrote: 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 ___ Bloat mailing list bl...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] analysis paper on PIE...
Hi Martin, I believe these papers may qualify that requirement: http://ipv6.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6925768 https://www.duo.uio.no/handle/10852/37381 tl;dr - both pie and codel camps did some independent implementations and testing of the respective other algorithm, with discussions and denting out some poorly described aspects in that process. It's my understanding that this lead to a better quality of the drafts in both instances. Richard Scheffenegger -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Martin Stiemerling Sent: Mittwoch, 12. November 2014 13:47 To: aqm@ietf.org Subject: Re: [aqm] analysis paper on PIE... [writing not as AD, but as random IETF participant] Sorry for this blunt question: Is there any other analysis made by an independent source, i.e., where not the PIE authors are running an analysis of PIE? Thanks, Martin Am 10.11.14 um 21:15 schrieb Rong Pan (ropan): Please see our analysis paper on PIE... Thanks, Rong ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] draft-hoeiland-joergensen-aqm-fq-codel
Hi, The chairs would like to confirm that the AQM WG community agrees to * adopt the document draft-hoeiland-joergensen-aqm-fq-codel-01 as an AQM working group item, heading towards publication as informational. Richard Scheffenegger -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Toke Høiland- Jørgensen Sent: Dienstag, 28. Oktober 2014 10:36 To: Scheffenegger, Richard Cc: aqm@ietf.org Subject: Re: [aqm] Draft Agenda for IETF91 Scheffenegger, Richard r...@netapp.com writes: 14:40 draft-hoeiland-joergensen-aqm-fq-codel Toke Hoeiland-Joergensen 20 min I managed to botch the submission process for the update to this, and now the ietf web site is closed for submissions. So until it reopens during the meeting, here is the -01 for this draft for perusal: https://kau.toke.dk/ietf/draft-hoeiland-joergensen-aqm-fq-codel-01.html or https://kau.toke.dk/ietf/draft-hoeiland-joergensen-aqm-fq-codel-01.txt Compared to the previous version this version had minor wording changes throughout, as well as some new references added. In addition, a new section on the algorithm limitations (section 7 in this version) has been added. -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] adoption call: draft-welzl-ecn-benefits
Hi Gorry, Given QUIC includes FEC to hide losses, I guess it is a good example to consider whether ECN still offers sufficient benefits over and above just removing losses. GF: And then, isn't the implication of AQM to significantly increase the number of losses unless we use ECN? Indeed, I have the impression we are confusing many on these points - ECN could change the reaction to congestion signal, and FEC (even opportunistic CC-friendly FEC) can also change the way things react to congestion signals. I don't think that an AQM's implication is automatically to increase the number of losses; that may happen to specific flows (in particular, unresponsive ones), but for responsive (non-ECN) ones, the expectation would be to de-correlate the losses, and for TCP, to only have around 1 loss per window when necessary - instead of a burst loss of one window and the expensive recovery... Perhaps it's that perception that also poses an obstacle to AQM deployment, because of the believe that a dynamic but lower mark/drop threshold will cause more losses? Regards, Richard ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt
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 transport control loop. IMHO, it should be made very clear, when the AQM action is done before the queueing, that the AQM signal is delayed for the outer control loop; obviously in a defensive loss situation, this will always be the case. In comparison, when the Queue prepends the AQM action, the AQM signal is delayed less to the outer control loop. Depending on the depth of the queue / departure rate, that timing difference can be significant... I don't know how to put that into better words that would fit into your draft though. Best regards, Richard Scheffenegger -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Fred Baker (fred) Sent: Freitag, 20. Juni 2014 17:52 To: grenville armitage Cc: aqm@ietf.org Subject: Re: [aqm] New Version Notification for draft-baker-aqm-sfq- implementation-00.txt On Jun 19, 2014, at 8:12 PM, grenville armitage garmit...@swin.edu.au wrote: Fred, Just read it -- clear, easy to comprehend. I'd be happy pointing AQM newcomers at it. One nit: Might be just me, but the Acknowledgements section feels more like an editorial/opinion. For a newcomer to AQM it wouldn't necessarily be clear how the body of the I-D supports the expressed opinion. Fair enough. The second sentence likely belongs in the conclusions. cheers, gja On 06/14/2014 08:07, Fred Baker (fred) wrote: 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 ro...@cisco.com A new version of I-D, draft-baker-aqm-sfq-implementation-00.txt has been successfully submitted by Fred Baker and posted to the IETF repository. Name: draft-baker-aqm-sfq-implementation Revision: 00 Title:On Queuing, Marking, and Dropping Document date:2014-06-13 Group:Individual Submission Pages:14 URL:http://www.ietf.org/internet-drafts/draft-baker-aqm- sfq-implementation-00.txt Status: https://datatracker.ietf.org/doc/draft-baker-aqm-sfq- implementation/ Htmlized: http://tools.ietf.org/html/draft-baker-aqm-sfq- implementation-00 Abstract: This note discusses implementation strategies for coupled queuing and mark/drop algorithms. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm -- Professor Grenville Armitage Director, Centre for Advanced Internet Architectures School of Software and Electrical Engineering Faculty of Science, Engineering and Technology Swinburne University of Technology, Australia http://caia.swin.edu.au ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] questions for draft-welzl-ecn-benefits
[as individual] Hi Lingli, If you mean by „unified deployment” that you need similar AQM schemes with the same parameters/goals, then no; For ECN to achieve its goal (provided the end hosts are reactive), only the marking probability needs to be roughly proportional to the level of congestion. If a path has multiple congestion points at different levels, the ECN marks will indicate the appropriate end-to-end congestion level that path should react upon. So, deploying AQM with entirely different behaviour (ie. one to keep queue sojourn time down, and another that simply tries to keep the queue length slightly below maximum) is just fine. There are other aspects – in the end hosts – that should be improved upon, though. Not all transports feature granular enough feedback mechanisms, and not all transports support granular responses to varying levels of ECN feedback. Having consistency there is important. 3, Deployment considerations, it is somehow related to the first two, do we have to assume a unified deployment of consistent end-to-end ECN behavior in order to achieve the optimal gain? If so, the above issues need to be addressed. Otherwise, how can one choose between end-to-end and hop-by hop? If ECN is ignored by non-supportive systems (as they should), ECN only needs to operate at the bottleneck. This actually makes for a nice deployment situation in principle, given that the bottleneck is often the access link. There are, of course, other deployment issues with ECN, and they are discussed at length in various recent and not-so-recent papers. I think citing them and discussing the current state of things briefly in this draft could be a good idea. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-03.txt
Hi, As discussed this week, we will start a rather short WGLC on this document, as it's the first milestone of the AQM WG. We would like to encourage final reviews, including nits, and will conclude the WGLC period in about 2 weeks time, at 20. March 2014. Richard Scheffenegger AQM WG chair -Original Message- From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of internet- dra...@ietf.org Sent: Freitag, 14. Februar 2014 22:05 To: i-d-annou...@ietf.org Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-recommendation-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF. Title : IETF Recommendations Regarding Active Queue Management Authors : Fred Baker Godred Fairhurst Filename: draft-ietf-aqm-recommendation-03.txt Pages : 23 Date: 2014-02-14 Abstract: This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-aqm-recommendation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Draft Agenda for IETF89
Hi Michael, Gorry, in section 3.2, you state that it exposes the presence of congestion. But ECN (on the IP layer) goes beyond that, and can expose not only the presence, but also the extent of congestion. (It's just that very few transports have ways to carry that extent back to the sender - speaking as co-author of draft-kuehlewind-tcpm-accecn-reqs and draft-kuehlewind-tcpm-accurate-ecn). Do you know about any other disadvantages? I think the biggest issue is the interaction between ECN and non-ECN flows (and packets; for TCP, only data segments are specified to optionally be ECN-enabled, not pure ACKs, and other control segments (some are allowed as experimental, i.e. SYN/ACK). If ECN would have been seen as universally good (back in the day), it is odd that one L4 flow (TCP session) is constituted from both ECN- and non-ECN segments during it's lifetime. The natural conclusion would be to assume that ECN on pure ACK, FIN, RST is detrimental in some way (personally I tend to disagree; there may not be any significant benefit, but it wouldn't break anything either - just the opposite, pure ACKs would serve as probes into the congestion state of the return path, once the data direction within the TCP flow reverses). But these points are transport specific; However, guidance to transport protocol designers on the use of ECN with control segments etc seems like it could be in scope for this document? In any case, to hash out the obvious, the interaction between ECN and non-ECN is complex and seen as potentially problematic. That may account for a real or perceived (depending on the AQM's use of ECN) problem with ECN... Richard Scheffenegger (individual contributor) -Original Message- From: Michael Welzl [mailto:mich...@ifi.uio.no] Sent: Montag, 17. Februar 2014 10:21 To: Dave Taht Cc: Scheffenegger, Richard; aqm@ietf.org Subject: Re: [aqm] Draft Agenda for IETF89 On 16. feb. 2014, at 20:35, Dave Taht wrote: 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 benefits of ECN persuasively and well. Thanks!! I would rather like a section discussing the negatives. We point to one problem in the introduction: Following a recommendation in [RFC3168], which says: for a router, the CE codepoint of an ECN- Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes, it has often been assumed that routers mark packets at the same level of congestion at which they would otherwise drop them (e.g. in [RFC2884]), but there are indications that this configuration is not ideal [KH13]. With this configuration, which is a common default, e.g. also in Linux AFAIK, one sometimes gets more queue growth than without ECN because the very packets that an AQM mechanism marks with ECN don't free queue space (which they would do if they were dropped instead). However, even this disadvantage has to be put against the advantages that we tried to list, some of which can't be measured by looking at the delay of packets on the wire (e.g., head-of-line blocking delay occurs in the receiver buffer). Do you know about any other disadvantages? Cheers, Michael ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Draft Agenda for IETF89
Hi Michael, Thanks for providing the correct draft name; I updated the agenda accordingly. Richard Scheffenegger (co-chair). Charter items - 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 ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] Draft Agenda for IETF89
Hi, The draft agenda for this IETF meeting in London has currently the following points. Please let me know if you disagree with the ordering, length or anything else! Best regards, Richard Scheffenegger (aqm-chair) * AQM Agenda IETF 89 in London, United Kingdom Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign) ** WG status - 14:20 Agenda bashing AQM status Chairs 10 min WG items 14:30 draft-ietf-aqm-recommendation Fred Baker / Gorry Fairhurst 10 min Charter items - 14:40 draft-fairhurst-ecn-motivation Gorry Fairhurst 15 min 14:55 draft-kuhn-aqm-eval-guidelines Nicolas Kuhn et. al. 45 min if time permits: Algorithm Proposals --- 15:40 draft-lauten-aqm-gsp wolfram lautenschlaeger 10 min ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] [AQM Evaluation Guidelines]
Thank you Nicolas, and of course also all the other editors for preparing this document! We will dedicate a significant fraction of the meeting time in London on discussing this document, so I would like to encourage you all to review this version! Best regards, Richard Scheffenegger -Original Message- From: Nicolas KUHN [mailto:nicolas.k...@telecom-bretagne.eu] Sent: Freitag, 07. Februar 2014 12:58 To: Scheffenegger, Richard Cc: aqm@ietf.org Subject: [AQM Evaluation Guidelines] Dear all, On the behalf of the contributors to the AQM Evaluation Guidelines, I encourage active discussion on the draft that we have written. I just submitted the draft as an individual draft to the I-D Submission Tool [0]. Please let us know what you think of the current document. Kind regards, Nicolas KUHN [0] http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/ On Feb 5, 2014, at 10:01 PM, Scheffenegger, Richard r...@netapp.com wrote: Hi, a new month, a new status report. First of all, Wes and I as chairs would like to thank the editors who have stepped forward to work on the AQM Evaluation Guideline draft. We are really thankful for their burst of efforts in the last couple weeks! We expect that that a document will be ready for submission into the I-D repository well before cutoff, as an individual draft, so that the WG can see what the state of thinking is currently. Also, once the document is published on datatracker we'd like to encourage active discussion on it. If the submitted -00 draft is felt to have a fairly complete outline of what the current thinking in the WG is, we may be able to ask the WG for formal adoption during this IETF meeting, or shortly thereafter. - WG Milestones: - Submit AQM recommendations to IESG for publication, obsoleting RFC 2309 (Goal: January 2014) - draft-ietf-aqm-recommendation is accepted towards this milestone - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ - the draft has been updated per comments received - if the authors are comfortable, a WGLC might be made on the next revision - we would like to hear from other authors of RFC 2309 on this document, if anyone has contacts to them. - Submit AQM algorithm evaluation guidelines to IESG for publication as Informational (Goal: July 2014) - An editor team has come forth and is working on this - A draft should be available for discussion in the London IETF - We encourage discussion on the list and during the meeting, if this draft should be adopted by the working group. - Submit first algorithm specification to IESG for publication as Proposed Standard (Goal: December 2014) - Since any Proposed Standard algorithm should be in line with the recommendations and be passable versus the evaluation guidelines, this milestone is dependend on the progress of the two work items above. - Currently the only algorithm spec with a complete and active individual-submission draft is PIE - Other items: - draft-pan-aqm-pie is under active work as a proposed algorithm: http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft has expired and should be refreshed. - draft-nichols-tsvwg-codel is expired; Dave Taht or others may revive it and/or describe pairing with FQ/SFQ algorithms: http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt - Other algorithm specifications are welcome! - Though, we are not planning on adopting algorithms until recommendations and evaluation guidelines are mostly stable Richard Scheffenegger ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] WG status
Hi, a new month, a new status report. First of all, Wes and I as chairs would like to thank the editors who have stepped forward to work on the AQM Evaluation Guideline draft. We are really thankful for their burst of efforts in the last couple weeks! We expect that that a document will be ready for submission into the I-D repository well before cutoff, as an individual draft, so that the WG can see what the state of thinking is currently. Also, once the document is published on datatracker we'd like to encourage active discussion on it. If the submitted -00 draft is felt to have a fairly complete outline of what the current thinking in the WG is, we may be able to ask the WG for formal adoption during this IETF meeting, or shortly thereafter. - WG Milestones: - Submit AQM recommendations to IESG for publication, obsoleting RFC 2309 (Goal: January 2014) - draft-ietf-aqm-recommendation is accepted towards this milestone - http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ - the draft has been updated per comments received - if the authors are comfortable, a WGLC might be made on the next revision - we would like to hear from other authors of RFC 2309 on this document, if anyone has contacts to them. - Submit AQM algorithm evaluation guidelines to IESG for publication as Informational (Goal: July 2014) - An editor team has come forth and is working on this - A draft should be available for discussion in the London IETF - We encourage discussion on the list and during the meeting, if this draft should be adopted by the working group. - Submit first algorithm specification to IESG for publication as Proposed Standard (Goal: December 2014) - Since any Proposed Standard algorithm should be in line with the recommendations and be passable versus the evaluation guidelines, this milestone is dependend on the progress of the two work items above. - Currently the only algorithm spec with a complete and active individual-submission draft is PIE - Other items: - draft-pan-aqm-pie is under active work as a proposed algorithm: http://tools.ietf.org/id/draft-pan-aqm-pie-00.txt, however the draft has expired and should be refreshed. - draft-nichols-tsvwg-codel is expired; Dave Taht or others may revive it and/or describe pairing with FQ/SFQ algorithms: http://tools.ietf.org/id/draft-nichols-tsvwg-codel-01.txt - Other algorithm specifications are welcome! - Though, we are not planning on adopting algorithms until recommendations and evaluation guidelines are mostly stable Richard Scheffenegger ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
[aqm] IETF 88 Agenda
Hi, A tentative agenda has been uploaded to http://www.ietf.org/proceedings/88/agenda/agenda-88-aqm We plan to spend the majority of the 1st session (Tuesday) on the adopted AQM recommendations draft, and the 2nd slot (Friday) mostly on the AQM evaluation criteria discussion. We would also want to highlight the accompanying talks in ICCRG (Tuesday after AQM): * Shahid Akhtar, An Evaluation of Various AQM techniques on Access Networks with Realistic Internet Traffic * Naeem Khademi, Evaluating CoDel, FQ_CoDel and PIE: how good are they really? Please send Additions and Objections to aqm-cha...@ietf.org We could probably also carter for one or two additional presentations, ideally on one of the two subjects above. Richard Scheffenegger ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
