Subject: Re: [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-eval-guidelines-11: (with COMMENT)

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 10 Jun 2016 11:38:01 +0000

Dear Spencer Dawkins, 

Thank you for your review and sorry for the delay of our answer. We will consider your comments as you can see inline.
We will push an updated version including the changes as soon as possible.
Please find attached to this email the diff between v11 and expected v12.

Kind regards, 

The authors

-----Message d'origine-----
De : Spencer Dawkins [mailto:[email-masked]] 
Envoyé : mercredi 18 mai 2016 23:12
À : The IESG
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Spencer Dawkins' Yes on draft-ietf-aqm-eval-guidelines-11: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-aqm-eval-guidelines-11: Yes

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm pretty sure I know what "steady state" means in this text

   The transmission of the non application-limited flow must start
   before the transmission of the application-limited flow and only
   after the steady state has been reached by non application-limited
   flow.
   
but I'm not sure how someone using this specification knows what it means, and it's asking the user to do something specific during evaluation. Is there a reference or definition you could provide?

[NK] By "steady-state" we generally mean that the non application-limited flow is out of slow start. We propose to add : "The steady state can be assumed when the goodput is stable."

(There are other uses of the phrase "steady state" in the document, and they would also benefit, but this is the use that needs the precision)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Jun 2016 08:21:01 -0500

On Fri, Jun 10, 2016 at 6:38 AM, Kuhn Nicolas <[email-masked]> wrote:

> Dear Spencer Dawkins,
>
> Thank you for your review and sorry for the delay of our answer. We will
> consider your comments as you can see inline.
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> but I'm not sure how someone using this specification knows what it means,
> and it's asking the user to do something specific during evaluation. Is
> there a reference or definition you could provide?
>
> [NK] By "steady-state" we generally mean that the non application-limited
> flow is out of slow start. We propose to add : "The steady state can be
> assumed when the goodput is stable."
>
> (There are other uses of the phrase "steady state" in the document, and
> they would also benefit, but this is the use that needs the precision)
>

That works for me, and thanks for considering my comment.

Spencer