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

[Greg Skinner]

Nico,

The table in the Summary section (section 13) retains the RFC 2119 normative 
language, but in the sections the table refers to, the normative keywords were 
uncapitalized.  Is this intentional?  This issue was raised by Alissa Cooper a 
few days ago.

Greg

On Jun 10, 2016, at 08:03 AM, Kuhn Nicolas  wrote:

All, 


Following the last discussions, please find an updated version of the AQM 
characterization guidelines.
The modifications are shown in the diff attached. 


Cheers

Nico

-Message d'origine-
De : aqm [mailto:aqm-boun...@ietf.org] De la part de internet-dra...@ietf.org
Envoyé : vendredi 10 juin 2016 16:59
À : i-d-annou...@ietf.org
Cc : aqm@ietf.org
Objet : [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Active Queue Management and Packet Scheduling 
of the IETF.

Title : AQM Characterization Guidelines
Authors : Nicolas Kuhn
Preethi Natarajan
Naeem Khademi
David Ros
   Filename : draft-ietf-aqm-eval-guidelines-12.txt
 Pages : 36
   Date : 2016-06-10

Abstract:
Unmanaged large buffers in today's networks have given rise to a slew
of performance issues. These performance issues can be addressed by
some form of Active Queue Management (AQM) mechanism, optionally in
combination with a packet scheduling scheme such as fair queuing.
This document describes various criteria for performing
characterizations of AQM schemes, that can be used in lab testing
during development, prior to deployment.


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

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

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


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
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11: (with DISCUSS and COMMENT)

[Mirja Kühlewind]

Hi Al,

I believe, we agree here. However, I’m not really sure what needs to be 
changed/added in the draft now. The only concrete item I have is replacing 
"application-level“ by "transport-layer payload“. Anything else?

Mirja

 
> 
> Am 10.06.2016 um 19:16 schrieb MORTON, ALFRED C (AL) :
> 
> more below, thanks for the clarifications, Mirja!
> Al
> 
>> -Original Message-
>> From: Mirja Kühlewind [mailto:mirja.kuehlew...@tik.ee.ethz.ch]
>> Sent: Friday, June 10, 2016 12:55 PM
>> To: MORTON, ALFRED C (AL); Mirja Kühlewind; Benoit Claise
>> Cc: w...@mti-systems.com; aqm-cha...@ietf.org; The IESG; draft-ietf-aqm-
>> eval-guideli...@ietf.org; Schulthess Nicolas (F); aqm@ietf.org
>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>> guidelines-11: (with DISCUSS and COMMENT)
>> 
>> Hi Al,
>> 
>> see below.
>> 
>> On 10.06.2016 18:41, MORTON, ALFRED C (AL) wrote:
>>> Hi, see below,
>>> 
 -Original Message-
 From: Mirja Kühlewind [mailto:i...@kuehlewind.net]
 Sent: Friday, June 10, 2016 9:15 AM
 To: Benoit Claise; MORTON, ALFRED C (AL)
 Cc: w...@mti-systems.com; aqm-cha...@ietf.org; The IESG; draft-ietf-
>> aqm-
 eval-guideli...@ietf.org; Schulthess Nicolas (F); aqm@ietf.org
 Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
 guidelines-11: (with DISCUSS and COMMENT)
 
 Benoit,
 
 waiting for Al. But in the mean time see below.
 
 On 10.06.2016 11:57, Benoit Claise wrote:
> Al, assuming that someone would like to register this metric in a
 registry
> (RFC6390), are they any grey areas in the performance metric
 definitions in
> the draft?
>  From what I understand, a point such this one (from Al) is:
> 
> Because we are using Goodput, G, I take as given that there
> must be a protocol with retransmission capability.
> Otherwise, further simplification is possible (with dummy
 traffic).
 
 Not really if you have not retransmission, simply your
 goodout=throughput.
 Don't see a problem here.
>>> [ACM]
>>> Although Goodput == Throughput for UDP, you can make a
>>> simpler measurement, you don't have to check for uniqueness.
>> 
>> 
>> That's the view from someone measuring in the network. But if you do
>> simulations or have a controlled testbed, the easiest things is to
>> measure in
>> the application (and you automatically get the right thing). As we don't
>> know
>> what exactly people do in the end, I think it is right to leave this
>> open
>> (and leave it as simple as possible in the description text).
> [ACM] 
> Ok, but what layer of the application?  The raw media stream(s)?
> Or everything in the TCP/UDP payload?
> 
> In lab benchmarking, it's sometimes about measuring at 
> link speed x number of ports, so every operation makes a difference!
> 
>> 
>> 
>>> 
 
> 
> But yes, Fs and G need to be reported on payload
> at the same layer, so the protocol layer chosen is
> an input parameter for this metric.
 
 Yes, it need to be the same layer for all your tests; but the goal is
 not be
 compatible with other tests. So it's your decision. It's guidance how
 you
 would test AQMs to decide if you want to deploy them in the future
>> (or
 to
 show that your AQM has benefits compared to other AQMs such that
>> another
 guy
 might deploy this in future).
>>> [ACM]
>>> 
>>> The current text mentions the "application layer" but needs to add the
>> note
>>> that the layer chosen needs to be specified/included in with the
>> results, so that
>>> someone reading results later will know what was tested.
>> 
>> There actually is now a sentence saying:
>> 
>> "Where flow size is the size of the application-level flow in bits and
>> goodput is the application-level transfer time (described in
>> Section 2.5)."
>> 
>> Is this sufficient?
> [ACM] 
> 
> I don't mean to prolong this, but I haven't been clear:
> The term "application-level" is ambiguous, it could be
> RTP, or some other container layer, or one of the MPEG layers,
> or the raw media/program stream (with our without meta data).
> 
> If by saying "application-level", the transport-layer payload 
> is meant, I suggest to say that.
> 
> are we there yet? I know I am :-), it's 19:15 down the road in Geneva!
> Al
> 
>> 
>> Mirja
>> 
>> 
>>> 
>>> Al
>>> 
>>> 
>>> ___
>>> aqm mailing list
>>> aqm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/aqm
>>> 
> ___
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

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

Re: [aqm] working group status and rechartering vs. closing

[Bob Briscoe]

Dave,

On 02/06/16 17:54, Dave Täht wrote:


On 6/1/16 7:10 AM, Wesley Eddy wrote:

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.

What remains to be done? (I've lost track). Can we focus on it and
finish the darn thing?

It is sad that the algorithm that essentially spawned the formation of
this working group remains un-rfc'd.

It's had influence elsewhere, also - outside of networking. The thinking
behind it has just had a rather nice patch set arrive for
making background disk writeback more invisible to foreground applications:

https://lwn.net/Articles/685894/



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?

My own desire is to see more link layers - wifi, 5g, 6lowpan, homeplug,
especially, explored with more implementations. There is also new stuff
like threads, wifi direct/p2p, and this new ieee effort,
http://standards.ieee.org/develop/corpchan/sfocus/index.html#std1c

These are the growth nodes of the internet today, with special problems
(non-duplex shared media with exponential backoff, handoff issues for
mobility, packet aggregation (wifi, 5g), offloads (ethernet), that are
only partially addressed by the aqm/fq technologies developed to date.

To me this also requires tighter interfacing with the IEEE especially on
new stuff like 802.11ad0, as well as 3gpp (5g)

Strongly agree.
I've been dealing with liaison correspondence with IEEE and 3GPP on 
behalf of the IETF (tsvwg) about misunderstandings in the implementation 
of ECN (which obviously requires an AQM). The general summary is:

* IEEE: no activity on this at all at the moment.
* 3GPP: 21 3GPP specs recommend ECN and therefore AQM (initially for 
voice over LTE). See slide 5 of my update to tsvwg 
 at 
the April'16 IETF. Two of these 3GPP docs specify the radio access 
network part. In them, the IETF's specs have been misunderstood, because 
the word "congestion" has been misunderstood as something that is 
binary, so when there is radio "congestion", it is assumed you have to 
do 100% marking and 0% when there is no "congestion".


However, the upside is that implementations are rare or non-existent :(
We need to somehow impress on implementers of radio network equipment 
how significant the improvements are from AQM, and explain AQM as 
something that is for all applications, not just one. Interactions with 
power control and radio resource control are hard - a group of us have 
started working on this, because it's very hard for RAN equipment 
designers to translate current AQM designs to address their scenario.




Other stuff - hardware multiqueue for multicore cpus, bql-like answers
at lower levels, and exactly how much should/must be pushed into
hardware logic rather than handled in software needs to start getting
resolved.

Ways for isps and vendors to more easily push out proper configs
(tr-069) for their link layers (dsl's variety of such is particularly
problematic)...

So my most important issues for future work tend to cross layers and wgs
and standards orgs.
Agree. In order to make this possible, we are going to need to work out 
the factors that are common to many L2 technologies, and which ones are 
specific. Otherwise we will just burn our time for ever trying to design 
and implement for each different technology.


Should we ensure that a significant part of the AQM's charter/agenda is 
about explanation/liaison/socialisation?

I'm