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

[Mirja Kuehlewind (IETF)]

Thanks! Will approve now! Finally! Yeah!

> Am 14.10.2017 um 08:31 schrieb Jana Iyengar :
> 
> Hi Mirja,
> 
> I've posted -10 of the draft, see more below.
>  
> > 2) Did you see Alia’s comments on mircoflows? I think it is true that in 
> > some cases you may also want to use additional information like the flow 
> > label or DSCP and not just the 5-tuple, while the text explicitly talks 
> > about 5-tuples. Do you want to add something here, or did you on purpose 
> > decide to only restrict to 5-tuples? I thinks this may be an unnecessary 
> > restriction and probably was not meant to be one.
> >
> > We fixed the draft to remove mentions of 5-tuples. (This was already done 
> > in -08.)
> 
> Okay. I was wondering if you want to explain more explicitly what flow means, 
> by e.g. saying something like it can be not only a 5-tuple but e.g. could 
> also include DSCP but that is implementation dependent…?
> 
> I really do not want to get into defining a flow; I think this works for any 
> definition of flow, since that's ultimately implementation dependent. Any 
> implementation can (as they do) assume whatever they want in terms of 
> defining a flow.
>  
> > 3) Did you see this comment from Ekr:
> > "Following up on the above point, you must be able to
> >   drop packets when the queue is entirely full, but S
> >   4.4 doesn't seem to contemplate this. What is the impact
> >   of this? You just drop and ignore?“
> > Can you explain how this was addressed? Maybe I just missed that but it 
> > seems important.
> >
> > There's nothing to be done if a packet arrives at a full buffer besides 
> > dropping it... we've added a sentence now that says "Packets arriving at a 
> > full buffer SHOULD be dropped." Hopefully that should clarify things.
> 
> The point here was rather the question if you count these as drop or not in 
> your algorithm. I believe you don’t count them but only those packets that 
> actually get dropped by CoDel directly, right?
> 
> However, I don’t think using normative language in the sentences you’ve added 
> makes sense because, as you say, drop is the only thing you can do. I guess 
> you’d need to say something like this instead:
> 
> "Packets arriving at a full buffer will be dropped. These packets are not 
> counted for the calculation of the CoDel algorithm.“
> 
> Or something similar…
> 
> I've removed normative language (Dave Taht also didn't like it) and replaced 
> it with some text about how it's not really used for CoDel computations. I've 
> also moved it to later in the draft where it fits better. 
> 
> I've also taken in some other editorial nits that I received from Lixia Zhang 
> in the meanwhile (Thanks, Lixia!). 
> 
> Thanks all!
> - jana

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

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

[Mirja Kuehlewind (IETF)]

Hi Jana,

thanks see below.

> Am 30.09.2017 um 03:01 schrieb Jana Iyengar :
> 
> Mirja,
> 
> Thanks for you review -- apologies for not addressing everything. I had left 
> a few things out as not necessary to change the draft, but we've now made the 
> following changes in draft-ietf-aqm-codel-09.
> 
> 1) Did you also check the sec-art and gen-art review. Both, as well as some 
> ADs, suggested to (better) define such terms as Sojourn time, estimator, or 
> Interval. Would it make sense to add something to the terminology section, or 
> did you decide this is not needed?
> 
> We've added these definitons now in Section 2.

Thanks!

>  
> 2) Did you see Alia’s comments on mircoflows? I think it is true that in some 
> cases you may also want to use additional information like the flow label or 
> DSCP and not just the 5-tuple, while the text explicitly talks about 
> 5-tuples. Do you want to add something here, or did you on purpose decide to 
> only restrict to 5-tuples? I thinks this may be an unnecessary restriction 
> and probably was not meant to be one.
> 
> We fixed the draft to remove mentions of 5-tuples. (This was already done in 
> -08.)

Okay. I was wondering if you want to explain more explicitly what flow means, 
by e.g. saying something like it can be not only a 5-tuple but e.g. could also 
include DSCP but that is implementation dependent…?

>  
> 3) Did you see this comment from Ekr:
> "Following up on the above point, you must be able to
>   drop packets when the queue is entirely full, but S
>   4.4 doesn't seem to contemplate this. What is the impact
>   of this? You just drop and ignore?“
> Can you explain how this was addressed? Maybe I just missed that but it seems 
> important.
> 
> There's nothing to be done if a packet arrives at a full buffer besides 
> dropping it... we've added a sentence now that says "Packets arriving at a 
> full buffer SHOULD be dropped." Hopefully that should clarify things.

The point here was rather the question if you count these as drop or not in 
your algorithm. I believe you don’t count them but only those packets that 
actually get dropped by CoDel directly, right? 

However, I don’t think using normative language in the sentences you’ve added 
makes sense because, as you say, drop is the only thing you can do. I guess 
you’d need to say something like this instead:

"Packets arriving at a full buffer will be dropped. These packets are not 
counted for the calculation of the CoDel algorithm.“

Or something similar…

Please let me know what you think and either update the draft, or we can also 
just add an RFC Editor not if that’s easier…

Mirja

 

> 
> Hope this covers everything that's pending -- let me know if I've missed 
> anything.
> 
> (I received jim-jam biscuits/cookies from Jim Gettys which helped with this 
> round -- thanks Jim :-))
> 
> 
> 
> - jana
> 
> Thanks!
> Mirja
> 
> 
> 
> 
> > Am 12.09.2017 um 02:27 schrieb Jana Iyengar :
> >
> > ... draft-ietf-aqm-codel-08 is finally posted. This new version addresses 
> > all IESG comments during IESG review, in addition to review comments by 
> > Patrick Timmons and Yoav Nir. We thank everyone for their help with reviews.
> >
> > Most importantly, I want to personally thank the fq_codel authors for 
> > sending me Yerba Mate, Dave Taht for sending me delicious freshly-baked 
> > cookies, and Paul McKenney for sending me a ton of organic green tea to 
> > help me move on the document. I will say that you all managed to do 
> > something nobody has managed so far: you successfully shamed me into 
> > getting this work done.
> >
> > I also received bungee cords from the fq_codel authors to tie myself to my 
> > chair with, which I put to good use: I would like to share here evidence of 
> > my atonement. (Cookies are not in the picture, because they were delicious. 
> > Thanks, Dave!)
> >
> > - jana
> >
> > (P.S.: I now look forward to receiving thank you gifts. Oh, and I'm 
> > caffeine-free and vegetarian, just in case.)
> >
> 
> 

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

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

[Mirja Kuehlewind (IETF)]

Hi Jana again,

I really don’t want to hold up the doc any further but... I had a quick look at 
the changes and the comments, and have a few more questions to you how or if 
those points where address. I hope this is really quick.

1) Did you also check the sec-art and gen-art review. Both, as well as some 
ADs, suggested to (better) define such terms as Sojourn time, estimator, or 
Interval. Would it make sense to add something to the terminology section, or 
did you decide this is not needed?

2) Did you see Alia’s comments on mircoflows? I think it is true that in some 
cases you may also want to use additional information like the flow label or 
DSCP and not just the 5-tuple, while the text explicitly talks about 5-tuples. 
Do you want to add something here, or did you on purpose decide to only 
restrict to 5-tuples? I thinks this may be an unnecessary restriction and 
probably was not meant to be one.

3) Did you see this comment from Ekr:
"Following up on the above point, you must be able to
  drop packets when the queue is entirely full, but S
  4.4 doesn't seem to contemplate this. What is the impact
  of this? You just drop and ignore?“
Can you explain how this was addressed? Maybe I just missed that but it seems 
important.

Thanks!
Mirja




> Am 12.09.2017 um 02:27 schrieb Jana Iyengar :
> 
> ... draft-ietf-aqm-codel-08 is finally posted. This new version addresses all 
> IESG comments during IESG review, in addition to review comments by Patrick 
> Timmons and Yoav Nir. We thank everyone for their help with reviews. 
> 
> Most importantly, I want to personally thank the fq_codel authors for sending 
> me Yerba Mate, Dave Taht for sending me delicious freshly-baked cookies, and 
> Paul McKenney for sending me a ton of organic green tea to help me move on 
> the document. I will say that you all managed to do something nobody has 
> managed so far: you successfully shamed me into getting this work done.
> 
> I also received bungee cords from the fq_codel authors to tie myself to my 
> chair with, which I put to good use: I would like to share here evidence of 
> my atonement. (Cookies are not in the picture, because they were delicious. 
> Thanks, Dave!)
> 
> - jana
> 
> (P.S.: I now look forward to receiving thank you gifts. Oh, and I'm 
> caffeine-free and vegetarian, just in case.)
> 

___
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 Kuehlewind (IETF)]

Yes, already contacted the authors!

Thanks all!

> Am 14.06.2016 um 08:42 schrieb Benoit Claise :
> 
> 
>>> -Original Message-
>>> From: Mirja Kühlewind [mailto:mirja.kuehlew...@tik.ee.ethz.ch]
>>> Sent: Monday, June 13, 2016 3:41 PM
>> ...
>>> 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
>> [ACM]
>> Thanks, that would resolve the biggest ambiguity for me.
>> Like I said last week, I think we're done (with that change).
> Thank you Al and Mirja.
> I'll clear the DISCUSS on that basis, trusting the AD that the addition will 
> be introduced.
> 
> Regards, Benoit
>> 
>> Al
>> 
>>> 
 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 

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

[Mirja Kuehlewind (IETF)]

Actually, it really doesn't matter that much in this case, I’d say. As we are 
talking about a lab environment, you might use dummy traffic that has some 
headers or not, that you might take into account of not, mostly depending on 
which information can be more easily accessed. What is important is that you do 
the same thing for all schemes that you compare.

I guess one could add a note that there are different ways to measure this and 
that it is important to measure G at the same layer. Does that make sense?

Mirja


> Am 08.06.2016 um 13:03 schrieb MORTON, ALFRED C (AL) <acmor...@att.com>:
> 
> Here's one area which could use more detail:
> 
>   ...The Flow Completion Time (FCT) is
>   related to the flow size (Fs) and the goodput for the flow (G) as
>   follows:
> 
>   FCT [s] = Fs [Byte] / ( G [Bit/s] / 8 [Bit/Byte] )
> 
> What protocol layers are included and excluded from Fs?
> 
> Also, G needs to be measured at the same layer, and the 
> definition in RFC 2647 is a bit vague about layers, too.
> It would be good to clarify which bytes to count here.
> 
> Al
> 
>> -Original Message-
>> From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
>> Sent: Wednesday, June 08, 2016 5:40 AM
>> To: MORTON, ALFRED C (AL)
>> Cc: Benoit Claise; w...@mti-systems.com; aqm-cha...@ietf.org;
>> aqm@ietf.org; draft-ietf-aqm-eval-guideli...@ietf.org; The IESG
>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>> guidelines-11: (with DISCUSS and COMMENT)
>> 
>> Hi Al,
>> 
>> what kind of detail are you looking for? Because I thought with the
>> given equation this one was pretty clear.
>> 
>> Do you have a reference to the benchmarking work?
>> 
>> Mirja
>> 
>> 
>>> Am 08.06.2016 um 11:18 schrieb MORTON, ALFRED C (AL)
>> <acmor...@att.com>:
>>> 
>>> Hi Mirja,
>>> 
>>> That sounds fairly reasonable to me.
>>> Would it be possible to ask the authors provide a bit more
>>> detail on Flow Completion Time?
>>> 
>>>>>> Flow Completion Time is close to a definition for a new metric,
>>>>>> and could benefit from more attention, perhaps a few more details.
>>>>>> RFC6390 will provide some areas for improvement.
>>> 
>>> I imagine that related benchmarking efforts may wish to measure this
>>> metric, and there would be independent implementations based on
>>> the description provided here.
>>> 
>>> regards from Geneve'
>>> Al
>>> 
>>>> -Original Message-
>>>> From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
>>>> Sent: Wednesday, June 08, 2016 4:46 AM
>>>> To: MORTON, ALFRED C (AL); Benoit Claise
>>>> Cc: w...@mti-systems.com; aqm@ietf.org; The IESG; draft-ietf-aqm-eval-
>>>> guideli...@ietf.org; aqm-cha...@ietf.org
>>>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>>>> guidelines-11: (with DISCUSS and COMMENT)
>>>> 
>>>> Hi Benoit,
>>>> 
>>>> I finally had another look at the document as well as at RFC6390. I
>>>> guess the metrics in question are Flow completion time (sec 2.1.),
>> Flow
>>>> start up time (2.2.) and Packet loss synchronization (2.4.). And you
>> are
>>>> right that these metric could be see as Application-Specific
>> Performance
>>>> Metric as defined in RFC6390. However, I agree with Al that given the
>>>> scope of this document is providing
>>>> "a generic list of scenarios against which an
>>>>  AQM proposal should be evaluated, considering both potential
>>>>  performance gain and safety of deployment.“,
>>>> I don’t think these metric need to be defined and registered this
>> way.
>>>> 
>>>> I guess as soon as we have a registry, maybe there is someone
>> interest
>>>> in IPPM to catch up these metrics again and provide a RFC6390
>> definition
>>>> but I would rather not like this document doing it.
>>>> 
>>>> Is that acceptable for you?
>>>> 
>>>> We could add one more sentence in the abstract to make the scope on
>> lab
>>>> testing during development and before deployment clear. Would that
>> help?
>>>> 
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>>> Am 25.05.2016 um 14:22 schrieb Mirja Kuehlewind (IETF)
>>>> <i...@kuehlewind.net>:
>>>>> 
>>>>

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

[Mirja Kuehlewind (IETF)]

Hi Al,

what kind of detail are you looking for? Because I thought with the given 
equation this one was pretty clear. 

Do you have a reference to the benchmarking work?

Mirja


> Am 08.06.2016 um 11:18 schrieb MORTON, ALFRED C (AL) <acmor...@att.com>:
> 
> Hi Mirja,
> 
> That sounds fairly reasonable to me.
> Would it be possible to ask the authors provide a bit more 
> detail on Flow Completion Time?
> 
>>>> Flow Completion Time is close to a definition for a new metric,
>>>> and could benefit from more attention, perhaps a few more details.
>>>> RFC6390 will provide some areas for improvement.
> 
> I imagine that related benchmarking efforts may wish to measure this 
> metric, and there would be independent implementations based on
> the description provided here.
> 
> regards from Geneve'
> Al
> 
>> -Original Message-
>> From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
>> Sent: Wednesday, June 08, 2016 4:46 AM
>> To: MORTON, ALFRED C (AL); Benoit Claise
>> Cc: w...@mti-systems.com; aqm@ietf.org; The IESG; draft-ietf-aqm-eval-
>> guideli...@ietf.org; aqm-cha...@ietf.org
>> Subject: Re: [aqm] Benoit Claise's Discuss on draft-ietf-aqm-eval-
>> guidelines-11: (with DISCUSS and COMMENT)
>> 
>> Hi Benoit,
>> 
>> I finally had another look at the document as well as at RFC6390. I
>> guess the metrics in question are Flow completion time (sec 2.1.), Flow
>> start up time (2.2.) and Packet loss synchronization (2.4.). And you are
>> right that these metric could be see as Application-Specific Performance
>> Metric as defined in RFC6390. However, I agree with Al that given the
>> scope of this document is providing
>> "a generic list of scenarios against which an
>>   AQM proposal should be evaluated, considering both potential
>>   performance gain and safety of deployment.“,
>> I don’t think these metric need to be defined and registered this way.
>> 
>> I guess as soon as we have a registry, maybe there is someone interest
>> in IPPM to catch up these metrics again and provide a RFC6390 definition
>> but I would rather not like this document doing it.
>> 
>> Is that acceptable for you?
>> 
>> We could add one more sentence in the abstract to make the scope on lab
>> testing during development and before deployment clear. Would that help?
>> 
>> Mirja
>> 
>> 
>> 
>>> Am 25.05.2016 um 14:22 schrieb Mirja Kuehlewind (IETF)
>> <i...@kuehlewind.net>:
>>> 
>>> Hi Al, Benoit, hi all,
>>> 
>>> thanks for the feedback. Sorry for me delaying this maybe a little but
>> I need t have another look at the document which will be next week at
>> this point. In general I agree that this does not need to only rely on
>> registered metrics because is mostly for lab tests; further this might
>> probably not the right doc to register new metrics. However, I would
>> still like to have another look at the doc and see if we can improve
>> anything or figure out if any of the ’new’/non-registed metrics
>> should/could be taken up by e.g. ippm.
>>> 
>>> Mirja
>>> 
>>> 
>>> 
>>>> Am 20.05.2016 um 14:53 schrieb MORTON, ALFRED C (AL)
>> <acmor...@att.com>:
>>>> 
>>>> All,
>>>> a few replies in-line below,
>>>> Al
>>>> 
>>>>> -Original Message-
>>>>> From: Benoit Claise [mailto:bcla...@cisco.com]
>>>>> Sent: Thursday, May 19, 2016 5:38 AM
>>>>> To: The IESG
>>>>> Cc: draft-ietf-aqm-eval-guideli...@ietf.org; w...@mti-systems.com;
>> aqm-
>>>>> cha...@ietf.org; w...@mti-systems.com; aqm@ietf.org; linda Dunbar;
>>>>> MORTON, ALFRED C (AL)
>>>>> Subject: Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-
>> 11:
>>>>> (with DISCUSS and COMMENT)
>>>>> 
>>>>> Benoit Claise has entered the following ballot position for
>>>>> draft-ietf-aqm-eval-guidelines-11: Discuss
>>>>> 
>>>> ...
>>>>> 
>> --
>>>>> DISCUSS:
>>>>> 
>> --
>>>>> 
>>>>> Has a RFC6390 performance directorate review done for the 2.X
>> metrics?
>>>>> It
>>>>> should.
>>>> [ACM]
>>>> I reviewed this draft about 18 mon

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

[Mirja Kuehlewind (IETF)]

Hi Al, Benoit, hi all,

thanks for the feedback. Sorry for me delaying this maybe a little but I need t 
have another look at the document which will be next week at this point. In 
general I agree that this does not need to only rely on registered metrics 
because is mostly for lab tests; further this might probably not the right doc 
to register new metrics. However, I would still like to have another look at 
the doc and see if we can improve anything or figure out if any of the 
’new’/non-registed metrics should/could be taken up by e.g. ippm.

Mirja


 
> Am 20.05.2016 um 14:53 schrieb MORTON, ALFRED C (AL) :
> 
> All,
> a few replies in-line below,
> Al
> 
>> -Original Message-
>> From: Benoit Claise [mailto:bcla...@cisco.com]
>> Sent: Thursday, May 19, 2016 5:38 AM
>> To: The IESG
>> Cc: draft-ietf-aqm-eval-guideli...@ietf.org; w...@mti-systems.com; aqm-
>> cha...@ietf.org; w...@mti-systems.com; aqm@ietf.org; linda Dunbar;
>> MORTON, ALFRED C (AL)
>> Subject: Benoit Claise's Discuss on draft-ietf-aqm-eval-guidelines-11:
>> (with DISCUSS and COMMENT)
>> 
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-aqm-eval-guidelines-11: Discuss
>> 
> ...
>> --
>> DISCUSS:
>> --
>> 
>> Has a RFC6390 performance directorate review done for the 2.X metrics?
>> It
>> should.
> [ACM] 
> I reviewed this draft about 18 months ago.
> Mostly, it points to existing RFCs for fundamental metrics,
> and discusses others.  I read this:
>   ...This document provides characterization guidelines that
>   can be used to assess the deployability of an AQM, whether it is
>   candidate for standardization at IETF or not.
> as restricted to lab testing.
> 
>> See http://www.ietf.org/iesg/directorate/performance-metrics.html
>> I guess that the metrics will be recorded in the future (See
>> draft-ietf-ippm-metric-registry-06
>> ), right?
> [ACM] 
> That's up to the authors, they might simply point to 
> metrics in the registry contributed by others 
> (when following these guidelines at a future time).
> 
>> For example, Flow Completion Time and Packet Loss Synchronization are
>> new, I believe.
> [ACM] 
> Flow Completion Time is close to a definition for a new metric,
> and could benefit from more attention, perhaps a few more details.
> RFC6390 will provide some areas for improvement.
> 
> Packet loss sync full methodology is described in [JAY006],
> according to the text. 
> 
>> And some other metrics are already documented in RFC6390 compliant
>> documents. Pointers should be provided.
> [ACM] 
> Most others are discussion sections and provide references.
> 
>> See
>> https://tools.ietf.org/html/draft-ietf-xrblock-independent-burst-gap-
>> discard-01#appendix-A
>> for an example
>> 
>> 
>> --
>> COMMENT:
>> --
>> 
>> - Random Early Detection (RED), BLUE, and Proportional Integral
>> controller (PI)
>> Would you have references?
>> 
>> - BDP is mentioned a few times. Please expand.
>> 
>> - Glossary section = terminology section, right? If we want to be
>> consistent across documents
>> 
>> - section 12.2. Why not a MUST below?
>>   In order to understand an AQM's deployment considerations and
>>   performance under a specific environment, AQM proposals SHOULD
>>   describe the parameters that control the macroscopic AQM behavior,
>>   and identify any parameters that require tuning to operational
>>   conditions.
>> 
> 

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