Re: [aqm] Status of the GSP AQM?

[Wesley Eddy]

On 12/14/2017 4:35 PM, Roland Bless wrote:

Hi folks,

I was wondering what happened to the GSP AQM proposal
(draft-lauten-aqm-gsp see
(https://tools.ietf.org/html/draft-lauten-aqm-gsp).
Discussion seems to have ended after IETF 93 and we probably
missed the point of discussing WG adoption.
IMHO this AQM should also be documented as RFC. It performs extremely
well in some settings (better than CoDel or PIE) and its implementation
complexity is also lower. Wolfram, are you interested in finishing this?
Should we continue in tsvwg?



I mentioned GSP as a possible work item, back when we were discussing 
rechartering, but apparently it was not compelling to the group at that 
time.


When we did the AQM algorithm adoption call ~2014, GSP appeared to be 
basically viable technically, but there wasn't evidence that multiple 
parties were interested in working with it enough to go forward (not 
just working the document, but implementing, simulating, testing, 
analyzing, deploying, etc).   There is a thread in the archives with 
subject "[aqm] adoption call: algorithm drafts".


I haven't noticed a change in activity around GSP since then, but 
apologize if I'm just ignorant of it!



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WG status

[Wesley Eddy]

I think there are no surprises here, but as there is an IETF meeting 
coming up, I wanted to make sure the AQM WG status is clear.


The final working group document (on CoDel) is now in IETF Last Call, on 
the main IETF list.


AQM does not plan to meet in Chicago, and should be closed down as the 
CoDel draft becomes published.  HOWEVER, the work on L4S and DualQ that 
has been discussed here is continuing in the TSVWG.  People that are 
interested in this should definitely be joining the TSVWG list and 
discussing it there:


https://www.ietf.org/mailman/listinfo/tsvwg

TSVWG has agenda time planned in Chicago for L4S, so you may wish to 
participate there.


For any additional or future work on AQM algorithms, implementation, 
etc., I think there will be several possible options that can apply 
depending on what the work is, including: ICCRG, TSVWG, AD-sponsoring, 
individual submissions, etc.  As usual, ask the ADs when in doubt :)




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Wesley Eddy]

In my opinion, point 1 would be a research topic to mention in section 9 
(or other suitable place).  Since we want to encourage wide 
experimentation, it's a good idea to be explicit about what some of the 
open questions/topics are.




On 9/29/2016 12:29 PM, Jana Iyengar wrote:

Hi Wes, Roland,

There are two issues in that email:
1. The importance of reentering state. This is clearly a matter for 
evaluation, and further evaluation will surely yield more results. We 
cannot and won't be perfect in this draft, but I encourage further 
evaluation and work that can perhaps even lead to a future update to 
this draft. We don't intend to address this point in the draft.
2. Consistency of drop_next_. We should be consistent, this was an 
oversight. We'll fix the algorithm to be consistent with the text.


We'll send out a revised draft early next week.
- jana

On Wed, Sep 21, 2016 at 12:55 AM, Bless, Roland (TM) 
<roland.bl...@kit.edu <mailto:roland.bl...@kit.edu>> wrote:


Hi Wes and all,

Am 14.09.2016 um 15:26 schrieb Wesley Eddy:
> Hi, for awhile, the CoDel draft was in working group last call. Some
> comments were received, and the authors made an update some time
ago.
> There hasn't been much follow-up discussion.  I assume this
means the
> current draft meets people's expectations?  If not, now is a
good time
> to shout, because I'm working on the shepherd write-up so that
it can be
> submitted to the IESG soon.

No, still some issues that were raised here:
https://mailarchive.ietf.org/arch/msg/aqm/ENA1VZmcFVXCJWrMIbmey4wAYnw
<https://mailarchive.ietf.org/arch/msg/aqm/ENA1VZmcFVXCJWrMIbmey4wAYnw>

that are not fixed yet.
I pointed that out at the mic within the AQM session @IETF96.
Andrew said that they need to do the changes and then resubmit.

Regards,
 Roland


___
aqm mailing list
aqm@ietf.org <mailto:aqm@ietf.org>
https://www.ietf.org/mailman/listinfo/aqm
<https://www.ietf.org/mailman/listinfo/aqm>




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Wesley Eddy]

The idnits issues link should have been: 
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-aqm-codel-04.txt


Apologies for the copy-paste error.


On 9/14/2016 9:26 AM, Wesley Eddy wrote:
Hi, for awhile, the CoDel draft was in working group last call. Some 
comments were received, and the authors made an update some time ago.  
There hasn't been much follow-up discussion.  I assume this means the 
current draft meets people's expectations?  If not, now is a good time 
to shout, because I'm working on the shepherd write-up so that it can 
be submitted to the IESG soon.


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There are a few small things I noticed while doing the shepherd write-up:

1) I thought the ADs and WG were happy to go Experimental rather than 
Informational 
(https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html ) ... 
was there a reason from the authors that it didn't change?


2) Idnits has some minor issues 
https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html


a) it doesn't like the reference "[CODEL2012]" in the abstract

b) for referencing RFC 896, there's inconsistent "RFC896" vs 
"RFC0896" (use the zero or don't, but it should match)


c) the "[CMNTS]" reference is unused

d) some of the obsolete references should be checked.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of codel WGLC

[Wesley Eddy]

Hi, for awhile, the CoDel draft was in working group last call. Some 
comments were received, and the authors made an update some time ago.  
There hasn't been much follow-up discussion.  I assume this means the 
current draft meets people's expectations?  If not, now is a good time 
to shout, because I'm working on the shepherd write-up so that it can be 
submitted to the IESG soon.


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There are a few small things I noticed while doing the shepherd write-up:

1) I thought the ADs and WG were happy to go Experimental rather than 
Informational 
(https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html ) ... 
was there a reason from the authors that it didn't change?


2) Idnits has some minor issues 
https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html


a) it doesn't like the reference "[CODEL2012]" in the abstract

b) for referencing RFC 896, there's inconsistent "RFC896" vs 
"RFC0896" (use the zero or don't, but it should match)


c) the "[CMNTS]" reference is unused

d) some of the obsolete references should be checked.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Berlin meeting

[Wesley Eddy]

Thanks to those who provided feedback.

We will plan to go ahead with the face-to-face meeting since several 
people are interested and will post an agenda shortly.


As always, please continue to also discuss topics on the mailing list.  
Several people have shared some thoughts on rechartering topics, though 
it's not clear that there is yet much agreement on specific topics that 
there would be common energy for.




On 6/29/2016 10:06 AM, Wesley Eddy wrote:
Hello, as you might have noticed, for Berlin, the AQM group is 
scheduled to meet on Friday: 
https://datatracker.ietf.org/meeting/96/agenda.html


The main goal of having the in-person meeting is to talk about closing 
the WG or rechartering.


As this is in the last slot, on the last day, and many people are 
likely to be trying to return home, we need to make sure there will be 
a critical mass to meaningfully hold a meeting, and not waste time.  
We are also having trouble getting both WG chairs present, in addition.


To gauge if it will be productive to meet, or if we should pursue 
other options, we created a Doodle poll:


http://doodle.com/poll/tht446xwu25uywat


Your feedback will be appreciated.

Note that more than one option can be selected.

A more verbose explanation of the options is:

1) "In-person meeting in Berlin" - this means we go along with the 
current plan and hold the meeting in Berlin


2) "Webex meeting in August" - this means the chairs would setup a 
webex to discuss rechartering in the month following the IETF meeting


3) "Mailing list only" - means you think we can figure out what to do 
from the mailing list only


4) "Close the WG; no interest to discuss rechartering" - means that 
you don't think we need to talk about this at all, and think the WG 
can spin down



Thanks for your help in this!




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group status and rechartering vs. closing

[Wesley Eddy]

Hello; the AQM list has been mostly quiet recently, other than 
discussion around the IESG comments on our drafts as they progress 
through the IESG review, so I thought it would be a good time to send a 
status snapshot and start more discussion about rechartering.


The datatracker page tells the story well, I believe: 
https://datatracker.ietf.org/wg/aqm/documents/


The main thing we need to work on before closing/rechartering is getting 
the CoDel draft finished.  I believe the editors have the working group 
last call comments and are planning an update to address them.  The goal 
should be to close the loop on these with the reviewers and get this 
into the IESG's queue before the next meeting in July.


We are planning for a 1-hour meeting at the next IETF meeting in July, 
in order to discuss next-steps for the working group, which could be 
either shutting down or rechartering.


We succeeded early on in getting RFC 7567 published and it looks like 
we'll soon have Experimental RFCs for 2 of the algorithms most people 
have worked with to-date.  Both specs became more clear and were 
improved through the WG reviews.  Additionally, we also have RFC 7806, 
the ECN benefits document, the characterization guidelines, FQ-CoDel, 
and DOCSIS-PIE descriptions that were completed.


We should think about what would be needed going forward.  Some 
questions for rechartering might be:


-  What would the group expect to advance algorithms from Experimental 
to Standards Track?  (e.g. more data from real deployments, more 
analysis of edge cases, etc) ... and are there people with time and 
support to meet whatever those expectations are?


- Are the current couple of algorithms all that's needed for the 
Internet, or are there other algorithms building on these, learning from 
experience with them, or making other improvements which we should work 
on?  (e.g. we have the DualQ draft, and recently the GSP draft has been 
updated)


- Are there ongoing field deployments, research projects, and other 
efforts that it will be good to discuss together in the working group, 
towards improving or advancing the current algorithms, or towards new 
algorithms?


- Is there other operations experience or considerations that should be 
documented?


Of course, this is not a complete list, but I thought formulating a few 
questions like this could help in determining if a recharter is 
justified rather than simply closing.  Your thoughts on these and any 
other relevant topics will be useful to hear on the mailing list and in 
Berlin.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 3/24/2016 9:01 AM, Toke Høiland-Jørgensen wrote:

Dave Cridland  writes:


Well, I have to ask why, in this case, it's Experimental and not
Standards-Track?

Heh. Well, I guess the short answer is "because there wasn't WG
consensus to do that". Basically, the working group decided that all the
algorithms we are describing will be experimental rather than standards
track, at least for now. Because they are queueing algorithms and not
protocols (and so do not have the same interoperability requirements),
this was deemed an acceptable way forward, and a way to get it "out
there" without having to have to agree to push for The One True AQM(tm).

(This is my understanding; I'm sure someone will chime in and correct me
if I'm wrong).


Personally, I would have no problem with this being standards track :)





I am one of the WG chairs and document shepherd.  The AQM charter does 
allow for publication on the Standards Track, but at this point in time 
there did not seem to be a consensus that this was necessary, plus given 
some of the open research questions, it seemed like a prudent choice.  
We can always go stronger and make a standard later on.


I think Bob's concerns here, and the disagreement about what happens in 
reality, make it very obvious that Experimental is the right choice!  
The indications so far are that this has a lot of promise to help, but 
there are questions, and it could benefit from even more experience 
deploying in the wild, and watching what happens.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Fwd: Gen-art LC review of draft-ietf-aqm-fq-codel-05

[Wesley Eddy]

FYI - some of Elwyn's comments may be of interest to the working group:


 Forwarded Message 
Subject:Gen-art LC review of draft-ietf-aqm-fq-codel-05
Date:   Wed, 9 Mar 2016 17:12:41 +
From:   Elwyn Davies 
To: General area reviewing team 
CC: draft-ietf-aqm-fq-codel@ietf.org



I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-aqm-fq-codel-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/03/06
IETF LC End Date: 2016/03/17
IESG Telechat date: (if known)  2016/03/17

Summary:
Almost ready.  There are a couple of minor issues that are barely above 
the level of nits plus a fair bit of editorial work.


I notice that the draft is on the IESG agenda on the day that last call 
ends.  If the authors wish to sort out the nits before the end of last 
call, I will be happy to work with them on this.


Major issues:
None.

Minor issues:
Treatment of packets that don't fit into the hashing classification 
scheme:  The default FQ-CoDel hashing mechanism uses the 
protocol/addresses/ports 5-tuple, but there will be packets that don't 
fit this scheme (especially ICMP).  There is no mention of what the 
classification would do with these packets.  I guess that one extra 
queue would probably suffice to hold any such outliers, but it would be 
wise to say something about how the packets from this/these queue(s) 
would be treated by the scheduler.  It might also be useful to say 
something about treatment of outliers in other classification schemes, 
if only to say that the scheme used needs to think about any such outliers.


s6.2, last para:  The proposal to add flow related marking to 
encapsulated packets needs to come with a very well exposed security and 
privacy health warning.. [It occurs to me that it might be possible to 
confine these markings to out of band notifications within the 
originating host which would allow fq_codel or similar to Flow Queue the 
packets getting them into a sensible order on the outgoing link.  Once 
the packets had been ordered in this way, a subsequent box (maybe an 
ADSL modem or suchlike) linking a home environment to the outside world 
could work purely on source address, thereby interspersing the packets 
from different hosts onto the external link but not needing to reorder 
the packets from each individual host.  Not sure if this is a sensible 
idea but it looks like a way to avoid the privacy issues.]


s11:  Internet Drafts are not scientific papers as such and do not 
usually have a Conclusions section.  I think it would be useful to move 
the paragraph in s11 as is to s1.  Since this draft is targeted for 
Experimental RFC status, it would be useful to suggest (maybe in s7) 
that experiments along the lines noted in s7 might be carried out and 
there results reported (where?  AQM WG?).  Given the developments with 
Cake, I am not sure whether the authors expect this version of FQ-CoDel 
to make it onto standards track or BCP, but to set out some sort of 
expected trajectory is desirable.


Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/

Draft Title: The acronym CoDel with an uppercase D is used everywhere 
else in the document - Suggest the title should be FlowQueue-CoDel


Abstract:   Need to expand AQM. [DNS and and CPU are 'well-known' - 
http://www.rfc-editor.org/materials/abbrev.expansion.txt]


General: It would be helpful to capitalize Quantum throughout (or at 
least from s3 onwards)  to emphasise that it is a configured value.  
Likewise Interval and Target parameters.  Maybe also Flow and Queue as 
they a defined terms.


s1, para 1: It would be helpful to give the full title 
(FlowQueue-CoDel), expand AQM (again), provide a refernece explaining 
the term bufferbloat and give references for AQM, basic CoDel, DRR and 
the ns2/ns3 network simulators.


I would think one or both of the following would be useful (long term 
stable) refs for bufferbloat (the first is useful because the article is 
publically available rather than needing a sub to IEEE or ACM):


Jim Gettys. 2011. Bufferbloat: Dark buffers in the Internet. IEEE 
Internet Comput. 15, 3 (2011), 95–96. 
DOI:http://dx.doi.org/10.1109/MIC.2011.56 (freely available at 
http://www.bufferbloat.net/attachments/27/IC-15-03-Backspace.pdf)


and/or
Jim Gettys and Kathleen Nichols. 2012. Bufferbloat:Dark buffers in the 
Internet. Commun. ACM 55, 1 (2012), 1–15. 
DOI:http://dx.doi.org/10.1145/2063176.2063196


Suggest:
OLD:
   The FQ-CoDel algorithm is a combined packet scheduler and AQM
   developed as part of the bufferbloat-fighting community effort.  It
   is based on a modified Deficit Round Robin (DRR) queue 

Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt

[Wesley Eddy]

FYI - I believe this update addresses everything from the working group 
last call, and I plan to complete the shepherd writeup and forward it to 
our AD later this week.




On 3/1/2016 3:16 PM, internet-dra...@ietf.org wrote:

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 
of the IETF.

 Title   : PIE: A Lightweight Control Scheme To Address the 
Bufferbloat Problem
 Authors : Rong Pan
   Preethi Natarajan
   Fred Baker
Filename: draft-ietf-aqm-pie-05.txt
Pages   : 26
Date: 2016-03-01

Abstract:
Bufferbloat is a phenomenon where excess buffers in the network cause
high latency and jitter. As more and more interactive applications
(e.g. voice over IP, real time video streaming and financial
transactions) run in the Internet, high latency and jitter degrade
application performance. There is a pressing need to design
intelligent queue management schemes that can control latency and
jitter; and hence provide desirable quality of service to users.

This document presents a lightweight active queue management design,
called PIE (Proportional Integral controller Enhanced), that can
effectively control the average queueing latency to a target value.
Simulation results, theoretical analysis and Linux testbed results
have shown that PIE can ensure low latency and achieve high link
utilization under various congestion situations. The design does not
require per-packet timestamp, so it incurs very small overhead and is
simple enough to implement in both hardware and software.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-aqm-pie-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-05


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] AQM plans

[Wesley Eddy]

Hi, I'm now sorry that we didn't schedule an AQM meeting slot in Buenos 
Aires.  We can certainly pre-load an agenda for Berlin with these topics 
though.  That is a long way in the future, however, so please use the 
mailing list to discuss tests and metrics, share results, advertise 
papers, etc, in the meantime on these topics!




On 2/26/2016 6:23 AM, De Schepper, Koen (Nokia - BE) wrote:

Hi Wes,

Just to let you know that we are still working on AQMs that support scalable 
(L4S) TCPs.
We could present some of our latest results (if there will be a meeting in 
Buenos Aires, otherwise in Berlin?)

* Performance of HTTP Adaptive Video Streaming (HAS) with different TCP's and 
AQMs
o HAS is currently ~30% of Internet traffic, but no AQM testing so far has 
included it
o the results are very poor with a particular popular AQM
Presenter: Inton Tsang
Duration: 10mins
Draft: Comparative testing of draft-ietf-aqm-pie-01, 
draft-ietf-aqm-fq-codel-04, draft-briscoe-aqm-dualq-coupled

For experiment write-up, see Section 3 of 
https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf

* PI^2: PI simplified with a square
o PIE embeds some auto-tuning and heuristics, which can be removed by 
simple transformation of a variable
o Allows PIE to control also scalable congestion controls (DCTCP, ...)
Presenter: Koen De Schepper
Duration: 15mins
Draft: (probably impacted)  draft-ietf-aqm-pie

* DualQ update
o extensive additional tests, including different RTTs and mixed RTTs, 
better visualization
o using other AQMs than Curvy-RED for 'Classic' traffic, e.g. PI^2
Presenter: Koen De Schepper
Duration: 20min
Draft: draft-briscoe-aqm-dualq-coupled-01

Regards,
Koen.



-Original Message-
From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy
Sent: woensdag 10 februari 2016 20:27
To: aqm@ietf.org
Subject: [aqm] AQM plans

Hello AQMers, this is just a quick note to be clear on working group
status and forward planning.

Currently, all of the active drafts are either in WGLC, or in the
process of shepherd writeups to go the the AD.

Once we get the current set of drafts out for publication, there are a
few things the WG can do:
- close down
- remain open to continue coordinating and advance algorithms (e.g.
within the standards track)
- remain open as a venue for potential new work (e.g. the DualQ Coupled
AQM)

I think we should discuss this and plan to make a decision after the
IETF 96 meeting in Berlin (July 17-22).  We can have a "closing or
re-chartering" meeting in Berlin if it will benefit from face-to-face
discussion.


___
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] AQM plans

[Wesley Eddy]

Hello AQMers, this is just a quick note to be clear on working group 
status and forward planning.


Currently, all of the active drafts are either in WGLC, or in the 
process of shepherd writeups to go the the AD.


Once we get the current set of drafts out for publication, there are a 
few things the WG can do:

- close down
- remain open to continue coordinating and advance algorithms (e.g. 
within the standards track)

- remain open as a venue for potential new work (e.g. the DualQ Coupled AQM)

I think we should discuss this and plan to make a decision after the 
IETF 96 meeting in Berlin (July 17-22).  We can have a "closing or 
re-chartering" meeting in Berlin if it will benefit from face-to-face 
discussion.



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

On 1/22/2016 10:01 AM, Wesley Eddy wrote:
Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo 
Jarvinen, both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.





To be clear also, I think at this stage, the feedback received from the 
working group isn't supporting Proposed Standard, and that the next 
update should be targeted "Experimental".   I can mark it that way in 
the datatracker, but can't edit the document header myself, and these 
need to be consistent before going to the IESG.


I've heard a couple other people seem to agree with going Experimental 
for the CoDel, FQ-CoDel, and PIE drafts and getting all three into the 
RFC Editor's hands sooner rather than later. (DOCSIS-PIE will be 
Informational.)  I've not yet heard folks saying that they really need a 
PS now and that PIE should be a PS now.


Definitely shout and correct me here if I'm wrong here, but I think this 
is the fastest path forward.





___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

On 2/10/2016 3:13 PM, Klatsky, Carl wrote:

Wes,

If the 'algorithm' drafts (CoDel, FQ-CoDel, and PIE) are targeted as Experimental, 
does that mean at some time later their status moves onto either PS (if real-world 
testing & use pans out) or Informational (if no activity further proves it out 
but the authors want to keep the info out there for the community)?  If so, how 
does that occur of the WG closes down?




If there's thrust to go Standards Track this can be done in a number of 
ways, mostly up to the discretion of the Area Directors:

1. done by AQM if it stays open longer-term
2. done by another relevant working group (e.g. TSVWG), if AQM is closed 
down
3. done by a re-incarnation of AQM working group (e.g. a PIE or CODEL 
working group)

4. done by "AD-sponsoring" of an update

In any case, the ADs need to be supportive of the path.

If for some reason any document needed to be deprecated, this could be 
done without the WG, and simply by marking as Obsolete in the RFC Editor 
database.  This would ideally be accompanied and requested by an RFC 
that describes what was found to be wrong, and what the impact is.


So ... in general, I think there's no real limitation imposed on the 
options of what can happen in the future.  However, things are 
definitely easier to do confidently when the working group is open and 
active, because consensus is simpler to judge.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 8:22 PM, Dave Täht wrote:

I do not really understand how this criterion promotes docsis-pie from
experimental to informational (or the reverse: demotes fq_codel from
informational to experimental, which happened this morning...


Hi Dave, I'm not ignoring the rest of your message, but do need to 
correct one misconception first.


There is no higher or lower relationship between Informational and 
Experimental.


There is IESG explanation of the distinction here:
https://www.ietf.org/iesg/informational-vs-experimental.html


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 9:18 PM, Dave Täht wrote:

Pie itself is proposed as standards track, despite the lack of field
data, a 15 page criticism from bob briscoe of the public implementation,
and other open issues like that. Personally I've been waiting for an
actual modem to test on before bothering to explore more deeply results
from pie than we already have. (There is a study starting up soon where
I hope to finally A/B the stuff)


Before going to the IESG, we need to make sure there is consensus on 
that publication track for PIE.  As you have seen, I'm trying to address 
that for each document as all of the technical WGLC comments are 
addressed and closed out.  I think the PIE editors would like Standards 
Track, if I understand correctly.  I do feel like the working group 
needs to speak up about whether they agree, because as a chair, I 
haven't heard much feedback about it.




And:

I've only recently discovered the pain that "experimental" can cause
when other ietf standards are attempted to be layered on top of it (in
the nascent babel wg). It didn't sound like informational would cost the
same pain. Am I wrong in that assumption?


I'm not familiar with this case, but was on the IESG in the past, and am 
not aware of Experimental causing any real issues for layering or 
referencing in other standards.  This is simply called out in the IETF 
Last Call as a downref, recorded in the downref registry, and life goes 
on.  The running code doesn't care how the document is labelled either :)


IMHO, Standards Track carries more weight to say that there are no sharp 
corners, and the IETF is pretty sure this works well. Experimental is 
more cautious saying this looks pretty useful, and you should consider 
trying it out, but it might have some rough edges (e.g. like open 
research questions, identified in several of the AQM drafts).


Just my 2 cents.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

Dave, here is a longer answer to your specific questions; I hope this 
helps calibrate where I'm coming from at least:



On 2/4/2016 8:22 PM, Dave Täht wrote:

I realize now that there was a call as to what status it should be
a while.  I figured silence meant there was consensus on informational,
so I was a bit surprised when it was changed. You got my attention!


I think we had discussed focusing on document quality and collecting 
evaluations, test results, etc., and then when ready to publish each 
algorithm, deciding what document track to go on.


For the DOCSIS one, I'm pretty sure there was never any other option 
than Informational, since it was not something IETF was working on. I 
think it is similar in a way to RFC 6057, and others.




so, what criteria apply for experimental vs informational vs standards
track?


For Informational vs Experimental, there is the IESG statement:
https://www.ietf.org/iesg/informational-vs-experimental.html

For the relation with the standards track, I don't know anything that 
describes Experimental vs Standards Track outside of RFC 2026.


AQM's charter allows us to publish on the Standards Track.  I haven't 
seen very much push to do so, personally, and IMHO the standards track 
is not to be taken lightly.  If a lot of people say "yes, definitely, 
algorithm X should be on standards track, and we're comfortable with 
that", that will be convincing ... but the feedback is really light so far.




What blockers apply later, were, for example, another RFC to rely on an
experimental vs informational fq_codel rfc? For example, right now,
fq_codel is the defacto fq+aqm for homenet...

vs standards track?



I don't think there's really any distinction there.  For the IESG, 
Standards Track (or BCP) is definitely better to normatively reference 
from other documents going onto Standards Track, since otherwise the AD 
has to do explain and catalogue the "downref" for IETF Last Call.  
However, this is not uncommon, or very burdensome. There is a running 
list of downrefs, and once an RFC is on it, that can be referenced for 
future IETF LCs:

https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry




No field data exists for docsis-pie. Most of the data on pie is from
sims.  Outside of the docsis standard I know of no deployments of pie
and no hardware support for it (please, someone? is there a roadmap from
any manufacturer with pie in it?).


I don't know about this, but it sounds like a good reason why 
Informational and Experimental tracks would be preferable at the moment 
to Standards Track.




and conversely, since the fq-codel draft describes what has already been
done in linux, deployed in systemd, openwrt, the edgerouter products (as
what it is), as part of more than a few other products, (rebranded),
inside several major cos, and with at least one well known deployed ISP...

...

I regarded fq_codel as experimental 4 years ago. it has survived the
test of time with no substantial changes. Certainly I'd like it to be
self tuning below 2.5mbits, but pie does badly there also without tuning.

...


I believe the Experimental vs Standards Track decision on FQ-CoDel is 
independent of anything to do with PIE.




As for declaring a "proposed standard", it seems as though pie's
standardization status itself has not yet been discussed on this list,
either.


I also would like to see more discussion of what people want to do with 
these documents.  I've tried to be clear about my own thoughts.  As a 
chair, my default is to NOT go standards track unless there's explicit 
push from the working group.




My vote is for docis-pie, pie and fq_codel to have the same status,
whatever it winds up being. Informational seemed fine, across the board.
I'm all in favor of more deployment experience.



Understood, though I'm doubtful that our publication track will impact 
deployment.  I believe we need to make the proper choice for each 
algorithm on its own merits, and not tie them together, personally.  
However, if the working group wants to keep everything at an even status 
though, please shout and tell us what that status is!





___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Experimental vs informational vs standards track

[Wesley Eddy]

On 2/4/2016 8:26 PM, Wesley Eddy wrote:


There is IESG explanation of the distinction here:
https://www.ietf.org/iesg/informational-vs-experimental.html



Quoting from that, I think this is the criteria that makes it most clear 
Informational is appropriate for DOCSIS-PIE:

"""

1. If it's not going to be changed no matter what the result is, it's
   Informational. This is typically the case with vendor protocols; the
   vendor will publish it for the good of the community, but retains
   full change control, and gives no promises about listening to
   community feedback. Case in point: "Microsoft Point-To-Point
   Encryption (MPPE) Protocol" (RFC 3078).

"""

It's simply what was done elsewhere, and not going to be changed.  Greg 
was kind enough to write it up, and it's useful information for the 
community, so the WG had decided to put it forward as Informational.


Does that make sense?



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of WGLC on fq-codel

[Wesley Eddy]

Hello, we started a working group last call for comments on this draft in 
December:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
(this is the -03 version currently)

Some comments were received since then, and Toke updated the document:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-04.html
(draft -04 version)

I think this update addresses all of the comments received.

I didn't see any feedback about document publication tracks (e.g. Standards Track, 
Informational, Experimental, etc).  We talked to the ADs briefly about this, and I think 
we are comfortable with Experimental for this document.  That is the appropriate track if 
the AQM working group thinks this is safe to deploy widely while experimenting with on 
the Internet (which I think is consistent with what section 7 describes -- it has already 
been widely deployed, though there are some items identified for future enquiry).  So, I 
think version -04 should be labelled with "Intended Status: Experimental".

My plan is to complete the shepherd writeup for this document in the next 
couple weeks, and if the editors push the -04 version of the draft, I think it 
will be ready to proceed for AD review.

Please shout if you have further comments.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of codel WGLC

[Wesley Eddy]

Hi, in December, we started a working group last call on:
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
(the -02 version of the document)

A couple of small comments that I've seen since then, but don't think 
were addressed are in:

https://mailarchive.ietf.org/arch/msg/aqm/0NM0D2PtrF08XzTk5M9TLkkybyc

I think based on Dave's responses in that thread, they might be easy to 
address with simple editorial changes, but would like the editors to 
respond or post an update.


Also, the editors should take a quick look at the "idnits" output and 
fix a few errors/warnings (which should be easy):

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-aqm-codel-02.txt
- need a table of contents
- check the references

I didn't see any feedback about document publication tracks (e.g. 
Standards Track, Informational, Experimental, etc).  We talked to the 
ADs briefly about this, and I think we are comfortable with Experimental 
for this document.  That is the appropriate track if the AQM working 
group thinks this is safe to deploy widely while experimenting with on 
the Internet (which has been happening for quite some time already).  
So, I think version -04 should be labelled with "Intended Status: 
Experimental".


My plan is to complete the shepherd writeup for this document in the 
next couple weeks, and if the editors push the -03 version of the draft, 
I think it will be ready to proceed for AD review.


Please shout if you have further comments.

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of PIE drafts WGLC

[Wesley Eddy]

Since none of the questions outstanding from WGLC seem to impact the 
DOCSIS PIE draft directly, I think that it is ready to move forward:

https://datatracker.ietf.org/doc/draft-ietf-aqm-docsis-pie/

Since it's describing what has already been done in DOCSIS, the 
Informational status seems appropriate, and consistent with other 
similar RFCs, so I think we're good there.


There are some small editorial nits found by "idnits" that we need to 
correct (add a security considerations section, add an IANA 
considerations section, and split references section into 
normative/informative):

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-aqm-docsis-pie-01.txt

I think that is all that needs to be done.




On 1/22/2016 10:01 AM, Wesley Eddy wrote:
Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo 
Jarvinen, both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.




___
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] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Wesley Eddy]

On 1/22/2016 2:17 PM, Fred Baker (fred) wrote:

On Jan 22, 2016, at 10:47 AM, Wesley Eddy <w...@mti-systems.com> 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 would be 
very helpful, exactly as Polina asked about.  But I don't think this has really 
happened, and don't think it's necessary at all for experimental RFCs.

As I recall the discussion, we decided up front that since there is no 
interoperability requirement among AQM algorithms (the requirement is that they 
interoperate well with TCP and UDP based applications; the AQM algorithms don' 
actually talk to each other, and the point is to drop or mark at the right rate 
and with the right pattern to encourage transport layer sessions to behave 
well), we didn't need to recommend a single AQM algorithm for all equipment or 
all uses. What we did need to do was identify some AQM algorithms that actually 
worked, and give guidance to the vendors and operators on their use.


I agree with all of this.  The characterization guidelines are aimed at 
helping to identify the AQM algorithms that actually work, or cases 
where they don't work as well (i.e. where some harmful or unintended 
consequence results).



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 1/22/2016 1:32 PM, Klatsky, Carl wrote:


Wes and all,

My comment is in regard to Polina’s comment “The WG currently has two 
AQMs (dropping/marking policy) in last call. Did someone evaluate 
these AQMs according to the specified guidelines?”.  As I read over 
draft-ietf-aqm-eval-guidelines, I did not think the objective of this 
memo was to arrive at consensus to select one specific AQM.  I thought 
the objective was to publish guidelines for implementers & service 
providers on how they can select an AQM that is best for their 
environment. And further that both AQMs in last call would complete 
the process as valid AQMs for implementers & service providers as 
available to use in their environment, with the guidelines helping 
them to decide which is best for them. Some may chose PIE, some may 
chose FQ_CODEL.  And possibly other future AQMs would go through the 
IETF process for publication, and that would be an additional option 
for implementers & service providers to evaluate according to the 
guidelines as best for their environment.


Is my understand of draft-ietf-aqm-eval-guidelines correct?




Yes, you're correct!  My assumption is that someone like a service 
provider would have an idea of some of the ranges of values (rates, 
delays, asymmetries, etc) appropriate for their environment, and would 
be able to use the evaluation guidelines effectively.


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 would be very helpful, exactly as Polina asked about.  
But I don't think this has really happened, and don't think it's 
necessary at all for experimental RFCs.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] status of PIE drafts WGLC

[Wesley Eddy]

Hello; the working group last call on the PIE drafts generated some 
emails, but I don't think I've seen any response from the editors. 
Specifically, there were a couple of emails with algorithm description 
questoins and technical comments from Rasool Al-Saadi and Ilpo Jarvinen, 
both with specific points that should be addressed.


For the most part, as I understand the comments, these are things that 
can be relatively simply fixed up or the intent clarified, and not 
catastrophic issues that would prevent the PIE docs from being 
publishable.  Please correct me if I misunderstand though.


If the editors can respond and work up a revision that addresses the 
comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
PIE documents moving forward.




___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group last call on CoDel drafts

[Wesley Eddy]

This message is to start a working group last call on the CoDel and 
FQ-CoDel documents:

https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
and:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

Please provide any comments you might be saving up on these by the end 
of December.


These both have the intended status designated as "Informational". 
Similar to the questions asked for PIE, we/chairs need to understand if 
there's consensus on:

- Are these specifications are clear and sufficient quality to publish?
- Should the status of the RFCs be "Experimental", "Proposed Standard", 
or "Informational"?







___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Document Action: 'The Benefits of using Explicit Congestion Notification (ECN)' to Informational RFC (draft-ietf-aqm-ecn-benefits-08.txt)

[Wesley Eddy]

On 12/1/2015 5:22 PM, Steve Baillargeon wrote:

Hi
Sorry to come so late with a comment.
Is it too late to add one more benefit to the draft?

I suspect ECN brings potential and significant savings in CPU cycles and memory usage , 
especially on the "server side" terminating a large number of TCP connections.
Has anyone done any analysis to confirm or contradict this assumption?




Hi Steve, thanks for the comment.

I don't think I've seen anyone analyze that before, and would guess at 
the moment that it's too tenuous to try to work into this particular 
document at its advanced stage.


I would recommend continuing discussion or research on this in AQM, 
TSVWG, ICCRG or other appropriate groups at the moment, but not altering 
the draft.  At the ADs, and editors discretion, and if there seems to be 
working group consensus, it might be noted as a potential benefit for 
future exploration, but that's about the only impact I think might be 
appropriate to this particular document at its advanced stage.


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] is the codel draft ready for last call?

[Wesley Eddy]

Please go ahead and submit the updated draft so we can start a working 
group last call.



On 10/30/2015 12:25 AM, Andrew Mcgregor wrote:

Hi Dave,

Jana and I did the editorial pass over it, but missed the cutoff 
date.  We plan on submitting a last-call version during the meeting, 
so yes, it will be ready for last call next week.


Andrew

On 22 October 2015 at 02:30, Dave Taht > wrote:


https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/

There were a few comments on the fq_codel draft so far but it was
mostly trivial.

I am not planning on making this ietf (have a trip to washington,
DC to make,
as well as purchasing some needed test gear for the make-wifi-fast
project),
but it would be my hope (for someone) to present some "cake" results
at the next ietf. I would have liked to have gone to japan, but...


Dave Täht
I just lost five years of my life to making wifi better. And, now...
the FCC wants to make my work illegal (!?) for people to install.
https://www.gofundme.com/savewifi

___
aqm mailing list
aqm@ietf.org 
https://www.ietf.org/mailman/listinfo/aqm




--
Andrew McGregor | SRE |andrewm...@google.com 
 | +61 4 1071 2221



___
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] Yokohama meeting planning

[Wesley Eddy]

This is a quick poll to ask if people think we need to have a
face-to-face WG meeting in Yokohama.

If so, please identify the topics that you want face-to-face time
to discuss, or whether these could be as easily handled in a webex
or conference call (perhaps as a virtual meeting).

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 8/18/2015 6:07 PM, Dave Taht wrote:
 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:

 https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

 Please make a review of this, and send comments to the list or
 chairs.  Any comments that you might have will be useful to us,
 even if it's just to say that you've read it and have no other
 comments.

 Unfortunately, we (Polina and I) did a thorough review,
 which is attached. TL;DR: from our point-of-view
 the I-D needs a major revision.
 
 I am so tired of this document that I can hardly bear to read it
 again, but I agree with the majority of the comments.
 
 Sometimes I do wish we could do graphics and charts as the IEEE does.
 


We can add any type of graphics that are necessary, they will
just only show up in the PDF version of the RFC, with only
references to the PDF version in the TXT copy.  See, for
instance:
https://tools.ietf.org/pdf/rfc6687.pdf

Are there particular figures that need to be added to this AQM
document to strengthen it?

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 8/18/2015 6:03 PM, Roland Bless 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:

 https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

 Please make a review of this, and send comments to the list or
 chairs.  Any comments that you might have will be useful to us,
 even if it's just to say that you've read it and have no other
 comments.
 
 Unfortunately, we (Polina and I) did a thorough review,
 which is attached. TL;DR: from our point-of-view
 the I-D needs a major revision.
 


Many thanks for the detailed review.

I think a majority of the comments could be addressed in an update, if
the authors agree.

There were only a couple of the major issues that I thought I should
comment on as a co-chair of the WG:


 3) the overall number of tests and parameter combinations is really
   high

Are there particular permutations (or classes of permutations) that you
can suggest to remove?  There's a balancing act between including enough
to satisfy people that want to find edge cases and thoroughly
characterize an algorithm, and the desire for a more easily tractable
suite of tests.


 4) from the discussed end-to-end metrics only latency/goodput metrics
   are used in the scenarios and for some of the scenarios these metrics
   are not suitable to show the desired behavior

It would be easier for the editors to improve this if you could suggest
specific metrics to add to specific scenarios, I think.


 5) some sections in this document (e.g., 7.3, 10, 13) specify requirements
   for an AQM standard(/draft) and not requirements for a performance
   evaluation, so these sections should be moved to
[draft-ietf-aqm-recommendation]

That one is now an RFC (7567), so hopefully they're already reflected
if they were critical requirements.

In any case, I agree with you that requirements themselves should not
be conveyed in this document, but rather it should be just aimed at
characterizing algorithm behavior with regard to the requirements
(for ones that are applicable to verification by testing).

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

As chairs, Richard and I would like to start a 2-week working
group last call on the AQM characterization guidelines:

https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

Please make a review of this, and send comments to the list or
chairs.  Any comments that you might have will be useful to us,
even if it's just to say that you've read it and have no other
comments.

Thanks!

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 6/12/2015 8:46 AM, go...@erg.abdn.ac.uk wrote:
 Since we are already in WGLC, the WG Chairs probably will need to decide
 the scope - if this is changed, I expect will anyway require a new WGLC. 
 Hopefully the new ID will help.


Here are my thoughts, with chair hat on.

It's an Informational document (i.e. not Standards Track or BCP).  It
does have some advice about how not to break ECN, but it's not
altering or changing any previous standards or BCPs about how devices,
hosts, or applications behave.

I think it correctly avoids using the 2119 capitalized words (SHOULD,
MUST, etc.).  There are some non-capitalized must and should words
in section 5 when going through the high-level list of prerequisites
for successful use of ECN, and in my opinion, this is one of the more
useful parts of the document to summarize and bring the advice together.

There's definitely a valid criticism that it isn't particularly
specific about some details in this guidance, but I think that's
probably desirable, as some are still being worked out, and would
ultimately go into Standards Track and BCP documents from TSVWG or
some other working group.

I think as the AQM working group, the level of detail and strength
of recommendations made in -04 are pretty much on the mark for what
we should say.

Certainly people should let us know during this Last Call if they
feel otherwise.  It can be something we explicitly ask the AD to
confirm during their review too.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04

[Wesley Eddy]

On 5/7/2015 5:39 PM, Dave Taht wrote:
 On Thu, May 7, 2015 at 2:31 PM, Michael Welzl mich...@ifi.uio.no wrote:
 Hi,


 On 7. mai 2015, at 22.40, Dave Taht dave.t...@gmail.com wrote:

 I see that during my absence here most mention of the potential
 negative aspects of ecn
 have been nuked from this document.

 Actually I don't think we really removed any - it's just a stylistic change 
 (title, headlines). So: could you be specific about which one there is in a 
 (which?) previous version that is missing in this one?
 
 You are correct. I should have said that few of the negatives I had
 attempted to discuss previously were added to the document.
 


Hi Dave, I'm trying as a co-chair to figure out if we have consensus
on this document to go forward.  If it's easy to point to, or summarize,
a list of negatives that haven't yet been included, I think that would
make it simpler for the editors to incorporate.  I wasn't able to go
back and track every message, but the things that have been most
discussed do seem to be included currently.  If there are some still
missing, I'd like to make sure they get discussed and incorporated as
needed.

There was the topic of gaming ECN, which I thought Bob Briscoe's
message on 4/15/2015 came close to putting to rest, and personally,
I'm not sure if or how to reflect this conversation in the draft, but
maybe others have more clear ideas?


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 5/8/2015 11:42 PM, Simon Barber wrote:
 I have a couple of concerns with the recommendations of this document as
 they stand. Firstly - implementing AQM widely will reduce or even
 possibly completely remove the ability to use delay based congestion
 control in order to provide a low priority or background service. I
 think there should be a recommendation that if you are implementing AQM
 then you should also implement a low priority service using DSCP, e.g.
 CS1. This will enable these low priority applications to continue to
 work in an environment where AQM is increasingly deployed. Unlike DSCPs
 that give higher priority access to the network, a background or low
 priority DSCP is not going to be gamed to get better service!
 
 Secondly, there is a recommendation that AQM be implemented both within
 classes of service, and across all classes of service. This does not
 make sense. If you are implementing AQM across multiple classes of
 service, then you are making marks or drops while ignoring what class
 the data belongs to. This destroys the very unfairness that you wanted
 to achieve by implementing the classes in the first place.
 


Hi Simon, thanks for your comments.

These comments appear to be in response to version -04 of the document,
from around 1 year ago.  The document is currently on version -11, has
past working group last call and IESG evaluation, and is in the RFC
Editor's queue.  I mention this, because it isn't clear to me how
applicable your comments are with regard to the current copy.

The current copy can be found at:
https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/

The current revision does mention the impact to delay-based end-host
algorithms as an area for future research.

While I agree that in a lot of cases it seems like logically a good
idea to have a DiffServ configuration like you mention, I don't think
we have seen data on this yet in the working group.  Looking into this
could be part of that mentioned future work, though not something I'd
want to see hacked into this document today, so late in its publication
process.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 4/29/2015 12:42 PM, Bob Briscoe wrote:
 Richard, Wes,
 
 1) The AQM charter says:
 Dec 2014 - Submit first algorithm specification to IESG for publication
 as Proposed Standard
 


Hi Bob, thanks for raising this, since it probably requires some
clarification and discussion.  I thought we'd outlined this a bit
on the list and through discussion a couple meetings ago, but it
might not have been integrated back into the charter.

I think the intention when chartering was to enable us to put
something on Standards Track, if there is consensus, but not
to limit us to only Standards Track.

It seems apparent that there are drafts which the group has
agreed are worth publishing (the ones we've adopted), and part
of submitting them for publication is deciding on the status
they'll be stamped with.  If the group wants to do Informational
or Experimental and feels those are more appropriate, then
obviously that's what we'll do.

I'm pretty sure our ADs support that, but am happy for them to
jump in and correct it, if not!

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Please review: Benefits and Pitfalls of using ECN

[Wesley Eddy]

On 3/11/2015 4:10 PM, go...@erg.abdn.ac.uk wrote:
 
 Alas, due to a slight technical mistake by me, we missed the ID deadline.
 So I have posted an interim version here:
 
 http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt
 http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml
 


I've reviewed this copy and have some comments, one larger and
the rest smaller.

Large comment:

I (personally) really do not like using the word pitfall in this
document, given that we want people to use ECN, and not scare them
about this list of pitfalls that await them the day they start using
it.

We could call these operational difficulties that have been
encountered or challenges due to misbehaving network devices and
endpoints.

I worry about someone that doesn't have time to carefully read and
consider all the benefits and whether they outweigh the pitfalls,
and may not fully grok that the pitfalls have known mitigations and
will hopefully go away over time.

We *should* be more clear that there are mitigations and that plenty of
nodes are able to use ECN happily today because it is implemented in
the major OSes and network devices.

For instance, there is no mention of things like ECN blackhole
detection, and measurements of this, such as:
http://conferences.sigcomm.org/imc/2011/docs/p171.pdf

We *definitely* need to stress that bleaching, lying, and cheating
behaviors are non-conformant, in some cases may be from legacy code,
and should be expected to go away over time rather than proliferate,
because these behaviors will cause problems for the growing critical
mass of conforming nodes.

So, in summary, I would really suggest that we go through the document
searching for every instance of pitfall and try to be more gentle,
and even change the title just to The Benefits of Using Explicit
Congestion Notification (ECN).  There is way more text in the document
about benefits than pitfalls anyways, and I think we could consider the
section discussing pitfalls as just fairly presenting possible
challenges to successfully using ECN.

That's just my opinion ... I'd be curious what others think.


Small comments:
- In section 1, paragraph 3, I suggest changing the text:
  where the exact combination of AQM/ECN algorithms is generally
   not known by the transport endpoints.
  to:
  where the exact combination of AQM/ECN algorithms does not need
   to be known by the transport endpoints.

  Since the document is for people that might not be familiar with
  this, it seems worth rewording so they don't think it's somehow
  bad or suboptimal that the endpoints don't know if AQM or ECN is
  supported within the network.

- section 1, paragraph 4, I suggest changing:
  that would otherwise have been dropped
  to:
  that would otherwise have been dropped if the application or
   transport did not support ECN

  I think this kind of wording will emphasize that they need to
  make sure they're enabling it at the endpoint.

- section 2, paragraph 3 should be changed:
  Applications that experience congestion in such endpoints
  to:
  Applications that experience congestion in such network devices


Even smaller comments:
- section 1, paragraph 2, forward - forwards
- section 1, paragraph 2, this packet - packets
- section 1, paragraph 3,
  The focus of this document is on usage of ECN
  to:
  The focus of this document is on usage of ECN by transport and
   application flows
- section 2, paragraph 2, I think the ECN RFC (3168) could also be cited
  in addition to 2309bis for the recommended behavior for network
  devices

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] review of CoDel -00 draft

[Wesley Eddy]

I reviewed and have some comments on the CoDel draft:
http://tools.ietf.org/html/draft-ietf-aqm-codel-00

1) I believe it would be a good idea to tie the goals listed in
   section 1 (in the bullet list on page 4) to the AQM guidelines
   from the RFC-to-be of draft-ietf-aqm-recommendation.

   Largely, the CoDel goals were brought into that rather than
   being pulled from it, but it will be good to provide a sentence
   or so that ties the working group documents and material together.

2) In the discussion of sojourn time as a metric (section 3.1) and
   using the minimum time to separate good queue from bad queue,
   it struck me that there is some parallel between this and the
   way that LEDBAT works in using the delta from the minimum as
   indication of queues (and congestion) building.  It may be
   worth noting or expanding on delay-based CC in endpoints and
   in-network.

3) Since the algorithm and pseudocode has been published a few
   places before, it would be good to draw attention to a section
   that notes any changes or differences between what will be
   published in this RFC and any other revisions of the pseudocode
   floating around the net (or clearly note if there aren't any).

In generally, it's very readable and I think it would serve as a
clear basis for implementing the algorithm, so would be happy to
see it go forward quickly through this working group to become an
RFC.


Small / editorial comments:
- The abstract has [TSVBB2011] which doesn't seem to actually
  exist as a reference
- The abstract could really be trimmed to just the 2nd paragraph,
  as the first is just background that's in the Introduction anyways
- The (covered in another draft) at the end of section 1 can be
  replaced with a real reference (there's already one later in the
  draft in 4.6)



-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Pete Resnick's No Objection on draft-ietf-aqm-recommendation-09: (with COMMENT)

[Wesley Eddy]

On 2/19/2015 7:25 AM, Martin Stiemerling wrote:
 Pete,
 
 Good catch!
 
 Authors  doc shepherd: Did the author sign anything?
 
 If not, we need the pre-5378 boiler plate.
 


No they didn't sign anything.  In fact many of them have been
difficult/impossible to reach, and the author list on 2309 was the
entire end-to-end RG at the time, so it's quite long.

It seems to me that we certainly need to use the pre-5378 boilerplate.
Thanks for catching this, Pete!


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group status

[Wesley Eddy]

Hi, to get 2015 started, Richard and I as chairs put together a set of
milestone status notes for the AQM working group items.

Please note, that there are a few relatively short drafts that should
not require much work, but which haven't been very actively discussed
on the list.  Comments on these will be extremely useful in accelerating
them forward.


- WG Milestones:
  - Submit AQM recommendations to IESG for publication, obsoleting
RFC 2309
- http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/
- This has been in IETF Last Call and some notes are being
  discussed from the last call comments

  - Submit AQM algorithm evaluation guidelines to IESG for publication
as Informational
- http://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/
- The editors are updating this based on comments from the last
  (Honolulu) meeting, and after that it may be ready to last call

  - Submit first algorithm specification to IESG for publication as
Proposed Standard
- http://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
- http://datatracker.ietf.org/doc/draft-ietf-aqm-pie/
- These algorithm drafts have been around for some time now, and
  it would be good to get some comments on the present revisions
  posted to the list (following up the Honolulu meeting threads).
  There are some known updates planned for the CoDel draft.

  - Some drafts that we don't have milestones for (but should add):

- Algorithm companion documents:
  - http://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
- adopted after the Honolulu meeting, and now the working
  group draft is available for review

  - http://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/
- This could be put forward for Informational along with the PIE
  algorithm spec.  If the working group commits to it, it could
  come from the AQM WG, or it could be an ISE track document
  otherwise.  ***We'd like to hear from the AQM working group on
  whether to adopt it for Informational.***

  - http://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
- Aiming for a Last Call around Dallas meeting timeframe
- This is a short draft; other than section 2 not being complete
  yet, it should be very easy to get finished soon.  Further
  input and reviews would be really helpful on this.

  - http://datatracker.ietf.org/doc/draft-ietf-aqm-fq-implementation/
- This draft is short and was well-received initially as a
  clarification to how AQM relates to FQ techniques.  Some
  references are to older drafts, but otherwise it seems like
  it may be complete enough to last call.  ***Further input and
  reviews would be really helpful on this.***


- Other items:

  - Other Algorithm Drafts:
- (Expired) https://datatracker.ietf.org/doc/draft-lauten-aqm-gsp/


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

 Original Message 
Subject: Gen-art LC review of draft-ietf-aqm-recommendation-08
Resent-Date: Fri, 19 Dec 2014 14:35:01 -0500
Resent-From: draft-alias-boun...@tools.ietf.org
Resent-To: f...@cisco.com, go...@erg.abdn.ac.uk, mls.i...@gmail.com,
r...@netapp.com, w...@mti-systems.com
Date: Fri, 19 Dec 2014 19:34:39 +
From: Elwyn Davies davie...@scss.tcd.ie
To: General Area Review Team gen-...@ietf.org
CC: draft-ietf-aqm-recommendation@tools.ietf.org,IETF
Discussion i...@ietf.org

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-aqm-recommendation-08.txt
Reviewer: Elwyn Davies
Review Date: 2014/12/19
IETF LC End Date: 2014/12/24
IESG Telechat date: (if known) -

Summary:  Almost ready for BCP.

Possibly missing issues:

Buffer bloat:  The suggestions/discussions are pretty much all about
keeping buffer size
sufficiently large to avoid burst dropping.  It seems to me that it
might be good to
mention the possibility that one can over provision queues, and this
needs to be avoided
as well as under provisioning.

Interaction between boxes using different or the same algorithms: Buffer
bloat seems to
be generally about situations where chains of boxes all have too much
buffer.  One thing
that is not currently mentioned is the possibility that if different AQM
schemes are
implemented in various boxes through which a flow passes, then there
could be inappropriate
interaction between the different algorithms.  The old RFC suggested RED
and nothing else so
that one just had one to make sure multiple RED boxes in series didn't
do anything bad.  With
potentially different algorithms in series, one had better be sure that
the mechanisms don't
interact in a bad way when chained together - another research topic, I
think.

Minor issues:
s3, para after end of bullet 3:
 The projected increase in the fraction of total Internet traffic for
 more aggressive flows in classes 2 and 3 could pose a threat to the
 performance of the future Internet.  There is therefore an urgent
 need for measurements of current conditions and for further research
 into the ways of managing such flows.  This raises many difficult
 issues in finding methods with an acceptable overhead cost that can
 identify and isolate unresponsive flows or flows that are less
 responsive than TCP.

Question: Is there actually any published research into how one would
identify
class 2 or class 3 traffic in a router/middle box? If so it would be
worth noting -
the text call for further research seems to indicate there is
something out there.

s4.2, next to last para: Is it worth saying also that the randomness
should avoid targeting a single flow within a reasonable period to give
a degree of fairness.

s4.2.1, next to last para:
 An AQM algorithm that supports ECN needs to define the threshold and
 algorithm for ECN-marking.  This threshold MAY differ from that used
 for dropping packets that are not marked as ECN-capable, and SHOULD
 be configurable.

Is this suggestion really compatible with recommendation 3 and s4.3 (no
tuning)?

s7:  There is an arguable privacy concern that if schemes are able to
identify class 2 or class 3 flows, then a core device can extract
privacy related info from the identified flows.

Nits/editorial comments:
General: s/e.g./e.g.,/, s/i.e./i.e.,/

s1.2, para 2(?) - top of p4: s/and often necessary/and is often necessary/
s1.2, para 3: s/a  class of technologies that/a class of technologies that/

s2, first bullet 3: s/Large burst of packets/Large bursts of packets/

s2, last para: Probably need to expand POP, IMAP and RDP; maybe provide
refs??

s2.1, last para: s/open a large numbers of short TCP flows/may open a
large number of short duration TCP flows/

s4, last para: s/experience occasional issues that need moderation./can
experience occasional issues that warrant mitigation./

s4.2, para 6, last sentence: s/similarly react/react similarly/

s4.2.1, para 1: s/using AQM to decider when/using AQM to decide when/

s4.7, para 3:
 In 2013,
At the time of writing ?

s4.7, para 3:
 the use of Map/Reduce applications in data centers
I think this needs a reference or a brief explanation.






___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] ADOPTED draft-kuhn-aqm-eval-guidelines

[Wesley Eddy]

Based on the mailing list adoption call feedback and other
comments received during meetings and telecons, we are
adopting:
http://datatracker.ietf.org/doc/draft-kuhn-aqm-eval-guidelines/
as an AQM WG draft towards the charter milestone for an
informational document on algorithm evaluation guidelines.

The editors can submit an updated as:
draft-ietf-aqm-eval-guidelines-00

We got some comments asking for a more direct way to
contribute text changes (e.g. github), and ask the editors
to consider that or interact with the people that would
like to contribute to find some way to work with them.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 8/11/2014 9:45 AM, go...@erg.abdn.ac.uk wrote:
 
 Responsiveness is important, but I believe it is OK for unresponsive
 flows that are small in relative terms to only be responsive at very
 long timescales (even solely at flow set up - self-admission
 control). This even applies to aggregates of unresponsive flows,
 because they will tend to be deployed where even the aggregate is
 small relative to the link capacity.
 See http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf
 (comments to the PWE3 list pls).
 
 +GF: I don’t see this needed in this draft.
 


I agree; this BCP is about AQM behavior, and not the right place to
hide recommendations or requirements on flow sources.


 +GF: I’m also considering replacing /congestive collapse/ by /congestion
 collapse/ which seems a more common term, as noted by John L.


I agree with this too.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] adoption call: draft-baker-aqm-sfq-implementation

[Wesley Eddy]

For reference, the draft is at:
http://tools.ietf.org/html/draft-baker-aqm-sfq-implementation-00

On 8/11/2014 10:25 AM, Wesley Eddy wrote:
 Based on feedback we've seen, it looks like there is significant
 value in progressing draft-baker-aqm-sfq-implementation as a
 working group document.
 
 Assuming there is WG consensus and we have AD-approval, we would
 like to add a milestone to develop this towards an Informational
 RFC within ~6 months.
 
 Please provide any comments, questions, support, or criticism for
 adopting this within the next few weeks.
 


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] IETF 90 minutes posted

[Wesley Eddy]

Please see the IETF 90 AQM meeting minutes posted at:
http://www.ietf.org/proceedings/90/minutes/minutes-90-aqm

Many thanks to Andrew McGregor for taking these down.

There are a couple of names that may need correcting; please
relay these and any other changes to either this list or to
aqm-cha...@tools.ietf.org.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Obsoleting RFC 2309

[Wesley Eddy]

There has been a bit of discussion last week about
draft-ietf-aqm-recommendation and how to improve the text near
the beginning, that leads to and sets context for the actual
recommendations.

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 to Obsolete and replace 2309 with
this document.  John suggested instead to let it live on, and
have this new one only Update it, and has suggested specific
changes that could be edited in, if this were the case.

I think we need to make a conscious on-list decision about this,
and decide to either confirm that Obsoleting 2309 is correct, or
to change course.

Others can amplify or correct these, but I think the points for
each would be:

Obsoleting 2309
- 2309 was an IRTF document from a closed RG, and we now can make
  a stronger statement as an IETF group with a BCP
- 2309 is a bit RED-centric, and we now think that people should
  be looking at things other than RED

Not-Obsoleting 2309 (e.g. Updating 2309)
- 2309 is a snapshot in history of the E2E RG's thinking
- 2309 is mostly oriented towards AQM as a mitigation for congestion
  collapse, whereas now we're more interested in reducing latency

Please share any thoughts you have on this, and what should be done.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] reminder: AQM conference call

[Wesley Eddy]

None of the information below has changed since initially announced,
but this is just a reminder that on Tuesday we'll have a conference
call that everyone is welcome to dial into in order to discuss the
ongoing AQM work and prepare for the Toronto meeting.

Agenda
==

1 - discuss overall WG status quickly
2 - discuss state of the 2309bis / recommendation draft
- if any editors or people with comments are online, this will be
  a chance to discuss any remaining items that haven't converged
  through the mailing list yet
3 - discuss state of evaluation guidelines / scenarios
- if one of the editors is available, we'd like them to share
  plans and status briefly
4 - discuss possibly adopting algorithms, as mentioned on the mailing
list and get some feedback on this
5 - plan agenda for Toronto


Webex and teleconference information



Topic: AQM
Date: Tuesday, June 24, 2014
Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 644 364 555
Meeting Password: 1234


---
To join the online meeting (Now from mobile devices!)
---
1. Go to
https://ietf.webex.com/ietf/j.php?MTID=ma8f0c666476fa3d8dd02ea205a46c036
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click Join.

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=mc8130e6e7792ca3024a9d7769782a4ba

---
To join the audio conference only
---
Call-in toll number (US/Canada): 1-650-479-3208

Access code:644 364 555

---
For assistance
---
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click Support.

You can contact me at:
cmor...@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=m8c5e445ca347986e1d4d6cd7ee8abb3a

The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] AQM conference call - June 24

[Wesley Eddy]

Here are webex and teleconference information for this meeting:


Topic: AQM
Date: Tuesday, June 24, 2014
Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 644 364 555
Meeting Password: 1234


---
To join the online meeting (Now from mobile devices!)
---
1. Go to
https://ietf.webex.com/ietf/j.php?MTID=ma8f0c666476fa3d8dd02ea205a46c036
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click Join.

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=mc8130e6e7792ca3024a9d7769782a4ba

---
To join the audio conference only
---
Call-in toll number (US/Canada): 1-650-479-3208

Access code:644 364 555

---
For assistance
---
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click Support.

You can contact me at:
cmor...@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=m8c5e445ca347986e1d4d6cd7ee8abb3a

The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

On 5/15/2014 5:09 AM, Bob Briscoe wrote:
 Wes,
 
 I assume you also want comments on the new version. Is there a deadline
 for comments?


Absolutely, yes.  There's no deadline at the moment, but it would
be good to get any out sooner rather than later, especially if they're
likely to need more discussion or are asking for major changes.


 I prepared comments on the previous version, but didn't get the time to
 type them up. So I want to try to remedy this with the new version (that
 I haven't read yet).


The diffs aren't huge, so many of your comments on the previous
revision might still be valid.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Wesley Eddy]

Hello AQMers, the WG last call on the 2309bis / AQM
recommendation draft has turned up a couple of reviews that
said the document isn't quite ready.  I think some of the
comments could be resolved relatively easily with an update,
though others might take some discussion to converge on what
really is needed to say or not say in this document.

There haven't been any responses to these yet that I've seen,
nor a solid set of positive comments.  So, we're not going to
advance this quite yet.

We do want to make progress between now and the next meeting.

We thought that perhaps a webex / teleconference side meeting
would give people a chance to talk about next steps and help
to advance this.

If you're interested in participating in this, please respond
to this poll on some possible times:

http://doodle.com/ng3y444te6mbendx

Assuming there's a critical mass of responses, we'll try to
pick a time that's least inconvenient, though guaranteed to
be terrible for some.

Thanks for your feedback on this, and help towards finishing
the document.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] publishing algorithms

[Wesley Eddy]

Hello AQMers.  As chairs, Richard and I had been planning to let
the evaluation guidelines converge and then use those to guide
adoption of algorithm documents.

However, we now think there may be value in not waiting so long,
and getting some algorithm documents moving along more quickly.

We hope you can provide some feedback on the plan below:

1) Starting soon, we may look to adopt a small number of algorithm
   drafts for Experimental, with the goal that by doing so, it will
   increase the number of eyeballs and independent reviews of them, and
   enhance the quality, since people may be implementing to the drafts
   in order to test using the evaluation guidelines.  Each algorithm
   *must* clearly identify which types of use cases / scenarios it is
   targeted for.

2) Adoption of an algorithm spec as a working group draft will require
   working group consensus that the algorithm looks attractive to
   experiment with for the stated scenarios, and multiple parties will
   plan to be looking at it, testing, analyzing, providing feedback,
   etc.

3) The evaluation guidelines / scenarios drafts being worked on
   separately will guide the later selection of one or more Experimental
   algorithms to become Proposed Standards with applicability
   statements for the scenarios they have been evaluated in.

We're interested to know if the working group thinks this sounds like
a good idea, bad idea, or any other thoughts.

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] publishing algorithms

[Wesley Eddy]

n 4/1/2014 12:34 PM, Fred Baker (fred) wrote:
 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?


Yes, it would be a shift in plans, and we'd have to make up some new
milestone targets.  That's why we're looking for feedback before doing
it, because it only makes sense to do if the people actually doing the
work will go along with it :).


 Note that I’m not pushing a given algorithm, nor am I convinced that 
 there should be exactly one. In protocol design, we are worried about
 interoperability, and everyone has to implement the protocol the same
 way. In AQM, the different algorithms, and the ones we think of next,
 have to produce a specific drop or mark rate under a specified
 circumstance (which might be about queue depth, latency in queue, or
 rate through a queue), and the end systems need to respond to that
 predictably. The means by which the mark or drop rate is established
 is semi-irrelevant if the rate itself is maintained. So I’m not
 exactly sure what the terms “Experimental” or “Proposed Standard”
 mean in the context and using the definitions in RFC 2026. It would
 be nice if we had a status that said “recommended for consideration
 for operational use”, and we could put that status on several that
 meet our requirements, whatever we decide those are.


I think (well, I hope) that pretty much everyone agrees on this.

My personal thought is that the Experimental ones may have some warts or
unknowns, and that should be okay with us, as long as they seem to be
promising and there is wide interest in using them and finding out more
about how they work or how they can be tweaked further, but a baseline
is needed/desirable for multiple people to work from.

The Standards Track algorithm(s) should have substantially less warts or
unknowns about them, and people should be able to put them in their code
and products with strong confidence that:

  1) they're implementing from an unambiguous specification
  2) it will perform with well-understood results

For instance, a hypothetical Algorithm X may have been beat to death by
one set of folks for some particular use case like a home gateway cable
router. They speculate that it will do well for some other scenarios
too, and there are other people interested in implementing and trying it
out over a longer term, but nobody is fully sure that it's absolutely
the best algorithm, and maybe there are some downsides like a bit of
minor tuning or a hidden variable that has to be tweaked for other
scenarios. That sounds like a good candidate for Experimental to me.
Maybe people will go play with it, and either learn good things and fix
it up for Standards Track, or learn bad things and drop it or make it
Historic.


-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] WG status

[Wesley Eddy]

Hi, as we've entered 2014 and have charter milestones that we're
working towards, Richard and I thought it would be good to start
periodically sending a status report to the WG mailing list so
that we can all keep up with what's going on, and focus our efforts
together on the things that need work.

Towards that goal, here is a snapshot of where we think the AQM
working group is at today, and what the next steps are that people
can contribute to:


- 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 needs to be updated per comments received, including
feedback on the recommendations from the Vancouver meeting
- 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)
- We need an editor team to step forward and begin work on this;
there was initial work presented in Vancouver, but no draft available or
adopted by the working group yet.
- It will be difficult to make this milestone, and will push other
milestones back, if this work isn't accelerated.
- Please express interest to the chairs or on-list

  - 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 hard to start on without significant progress on the
previous two.
- 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
  - CoDel draft 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


-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [Bloat] [iccrg] AQM deployment status?

[Wesley Eddy]

On 10/14/2013 1:07 PM, Curtis Villamizar wrote:
 So my first question to the AQM WG is what is the scope of AQM WG
 work in terms of where in the network this WG wants to focus?  If the
 answer to that question is everywhere, then we have to be aware that
 conditions in core and conditions in home or enterprise are very
 different.  If the focus is on home, soho, and small business, then
 the charter should say so (I don't think it is).


The charter says:

  It is expected that some classes of algorithms will focus on software
  implementations, while others on existing or new hardware
  deployments, and algorithms may be specific to distinct scenarios.


I would say anywhere that AQM algorithms can have a positive impact
is in scope, and that it's understood and accepted that particular
algorithms or tuning rules may not be ideal across different
environments (or may not be easily implemented in different kinds of
platforms).  There was at least some talk of applicability
statements for things that wind up being recommended by the working
group.

In my opinion, the home broadband router is one well-known case that
may hold a lot of the initial attention in the working group, because
the barriers to implementing/testing/deploying new algorithms for this
case are less than for many others.  We definitely did not want to
limit the charter to this scenario though, and it is intentionally
open to others.

I hope this clears it up!


-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] working group kickoff

[Wesley Eddy]

Congratulations, as you may have seen, the AQM working group was
approved by the IESG!

Richard and I wanted to remind people that the charter is fairly
aggressive in schedule.

We previously had seen strong consensus in the BoF meeting and
on the AQM and TSVAREA mailing lists for making a working group
document of draft-baker-aqm-recommendation.  Richard and I plan
to have the editors submit the next revision of that as a WG item,
but please scream if there is a problem with this.

There is a meeting request in for Vancouver where we hope to spend
the time talking about 2309bis, and any big issues with it, and
about algorithm evaluation (Naeem Khademi et al).  Currently, those
are our agenda priorities, based on the upcoming charter milestones,
but please let Richard and I know if you have other needs for
meeting time.

-- 
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm