Subject: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-pie-07: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 19 May 2016 05:30:34 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-aqm-pie-07: No Objection

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-pie/

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

- Support Ben's comment:

It would be nice to see some text about the nature of the "experiment". 
That is, why is this experimental? Do you expect to promote this to a 
standard in the future? (The shepherd's report speaks of this; the draft

should, too)

ex: https://tools.ietf.org/html/rfc6614#section-1.3

- Minor personal preference: delay variation instead of jitter.
See https://tools.ietf.org/html/rfc5481#section-1 for a justification.
Btw, same comment for draft-ietf-aqm-eval-guidelines-11, which I forgot
to mention.

- Section 1
RFC2309 is obsolete:

   RFC 2309[RFC2309]
   strongly recommends the adoption of AQM schemes in the network to
   improve the performance of the Internet. 

Not sure why [RFC2309] is different than [IETF-AQM], which is now
RFC7567. So maybe using [RFC2309] was used on purpose.

- it seems that you sometimes interchange queueing latency, latency,
delay, queue delay
For an example, review section 3 and section 4 first paragraph.
You should really use consistent terms, for example queueing latency,
throughout the document.

OLD:

As illustrated in Fig. 1, PIE conceptually comprises three simple MUST
components: a) random dropping at enqueueing; b) periodic drop
probability update; c) latency calculation. When a packet arrives, a
random decision is made regarding whether to drop the packet. The drop
probability is updated periodically based on how far the current delay
is away from the target and whether the queueing delay is currently
trending up or down. The queueing delay can be obtained using direct
measurements or using estimations calculated from the queue length and
the dequeue rate.

NEW:
As illustrated in Fig. 1, PIE conceptually comprises three simple MUST
components: a) random dropping at enqueueing; b) periodic drop
probability update; c) queueing latency calculation. When a packet
arrives, a
random decision is made regarding whether to drop the packet. The drop
probability is updated periodically based on how far the current queueing
latency
is away from the target and whether the queueing latency is currently
trending up or down. The queueing latency can be obtained using direct
measurements or using estimations calculated from the queue length and
the dequeue rate.

NEW:

        Random Drop
             /               --------------
     -------/  -------------->    | | | | | -------------->
            /|\                   | | | | |
             |               --------------
             |             Queue Buffer   \
             |                     |       \
             |                     |queue   \
             |                     |length   \
             |                     |          \
             |                    \|/         \/
             |          -----------------    -------------------
             |          |     Drop      |    | Queueing        |
             -----<-----|  Probability  |<---| Latency         |
                        |  Calculation  |    | Calculation     |
                        -----------------    -------------------

- terminology: dequeue_rate or departure?
    Section 4.2 =>"dequeue rate"
    Section 4.3

        current_qdelay = queue_.byte_length()/dequeue_rate;

    Section 5.2 Departure Rate Estimation
    Section 5.2 typo "Upon a packet deque:"  (this one could fine if you
speak about the
                                                                     
deque(Packet packet) function, but that's not clear)
Again, be consistent across the entire doc.

- editorial: missing reference links

   CBQ has been a standard feature in most network devices today[CBQ].

    The controller parameters, alpha and beta(in the unit of hz) are
    designed using feedback loop analysis where TCP's behaviors are
modeled
    using the results from well-studied prior art[TCP-Models].

- editorial:

   This draft separates the PIE design into the basic elements that are
   MUST to be implemented and optional SHOULD/MAY enhancement elements.

NEW:
   This draft separates the PIE design into the basic elements that 
   MUST to be implemented and optional SHOULD/MAY enhancement elements.

Below is Mahesh's OPS DIR review:
I have reviewed the following document as part of the Operational
directorate’s ongoing effort to review all IETF documents being processed
by the IESG.  These comments were written with the intent of improving
the operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the IESG
review.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Document reviewed:  draft-ietf-aqm-pie-06

Summary: Ready with nits.

    The document is on an Experimental Track. Perhaps because of it there
is little discussion of either operational or management considerations.
If the document progresses towards a standardization effort, the
following are (only a partial list of) suggestions or areas that can be
explored.
    From a deployment consideration perspective
        The document could talk about how the technology is going to be
deployed or managed.
        It would help if the authors documented any scaling issues that
they have run into.
        How would this AQM co-exist with other methods?
    From an installation and initial setup perspective
        The document could talk about how PIE would be configured. For
the parameters that are configurable, what are the ranges and what is the
default value.
        Are the parameters going to be configured by configuration
manager, or will the device pull the configuration from a configuration
server?
    From a network operations perspective
        The document could talk about the impact of PIE on existing
networks, with or without other AQM.
        While PIE attempts to reduce latency and jitter, what is the
impact on throughput when it is deployed, specially for non-real time
traffic?
    From a verifying correct operations perspective
        How does one verify that the network is behaving as expected once
PIE is applied?
        Other than latency and jitter, are there any other parameters of
interest?
        Will the test in itself have an impact on the network or the
protocol?
    From a management interoperability perspective
        The document can talk about any standard YANG models that might
need to be enhanced or developed for manageability across vendors.
    From a fault or threshold conditions perspective
        The document could talk about any notifications that need to be
reported for any events generated because of the algorithm. Should the
events be polled or could they be pushed? Would notifications have to be
throttled?

A run of idnits has revealed a few issues that will need to addressed.

tmp/draft-ietf-aqm-pie-06.txt:
tmp/draft-ietf-aqm-pie-06.txt(17): Found control character TAB in
position 1.
tmp/draft-ietf-aqm-pie-06.txt(383): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(469): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(471): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(941): Line is too long: the offending
characters are '.'
tmp/draft-ietf-aqm-pie-06.txt(978): Found control character TAB in
position 8.
tmp/draft-ietf-aqm-pie-06.txt(982): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1099): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1101): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1112): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1126): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1128): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1182): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1187): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1189): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1253): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1254): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1257): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1258): Found control character TAB in
position 13.
tmp/draft-ietf-aqm-pie-06.txt(1259): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1260): Found control character TAB in
position 13.
tmp/draft-ietf-aqm-pie-06.txt(1261): Found control character TAB in
position 13.
tmp/draft-ietf-aqm-pie-06.txt(1263): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1306): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1325): Found control character TAB in
position 7.
tmp/draft-ietf-aqm-pie-06.txt(1327): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1328): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1330): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1352): Found control character TAB in
position 4.
tmp/draft-ietf-aqm-pie-06.txt(1386): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1391): Found control character TAB in
position 9.
tmp/draft-ietf-aqm-pie-06.txt(1393): Found control character TAB in
position 9.

[Stuff deleted]

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to
http://www.ietf.org/id-info/1id-guidelines.txt:
 
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
 
----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest
one
     being 1 character in excess of 72.

  ** There are 31 instances of lines with control characters in the
document.

  Miscellaneous warnings:
 
----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does
not
     match the current year

  Checking references for intended status: Experimental
 
----------------------------------------------------------------------------

  == Missing Reference: 'IETF-AQM' is mentioned on line 748, but not
     defined
     '[IETF-AQM]     Baker, F. and Fairhurst, G., "IETF
Recommendations...'

  == Missing Reference: 'CoDel' is mentioned on line 730, but not
     defined
     '[CoDel]        Nichols, K., Jacobson, V., "Controlling Queue
Dela...'

  == Missing Reference: 'CBQ' is mentioned on line 727, but not
     defined
'[CBQ]          Cisco White Paper,...'

  == Missing Reference: 'FQ-Implement' is mentioned on line 739, but not
     defined
     '[FQ-Implement] Baker, F. and Pan, R. "On Queueing, Marking and...'

  == Missing Reference: 'DOCSIS-PIE' is mentioned on line 736, but not
     defined
     '[DOCSIS-PIE]   White, G. and Pan, R., "A PIE-Based AQM for
DOCSIS...'

  == Missing Reference: 'HPSR-PIE' is mentioned on line 742, but not
     defined
     '[HPSR-PIE]     Pan, R., Natarajan, P. Piglione, C., Prabhu,
M.S.,...'

  == Missing Reference: 'PI' is mentioned on line 755, but not defined
     '[PI]	          Hollot, C.V., Misra, V., Towsley, D. and Gong,
W.,...'

  == Missing Reference: 'QCN' is mentioned on line 759, but not
     defined
'[QCN]	  "Data Center Bridging - Congestion Notification",...'

  == Missing Reference: 'TCP-Models' is mentioned on line 762, but not
     defined
     '[TCP-Models]   Misra, V., Gong, W., and Towsley, D.,
"Fluid-base...'

  == Missing Reference: 'IETF-ECN' is mentioned on line 751, but not
     defined
'[IETF-ECN]     Briscoe, B. Kaippallimalil, J and Phaler, P.,...'

  -- Obsolete informational reference (is this intentional?): RFC 2309
     (Obsoleted by RFC 7567)

     Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments
(--).

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 May 2016 16:33:20 +0100

Adding a note as a TSVWG Co-Chair regarding RFC7567.

Comment below,

Gorry

> https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/
The ID present text says:

   "Active queue management (AQM) schemes, such as Random Early Detection
    (RED), have been around for well over a decade. AQM schemes could
    potentially solve the aforementioned problem. RFC 2309[RFC2309]
    strongly recommends the adoption of AQM schemes in the network to
    improve the performance of the Internet. RED is implemented in a wide
    variety of network devices, both in hardware and software.
    Unfortunately, due to the fact that RED needs careful tuning of its
    parameters for various network conditions, most network operators
    don't turn RED on. In addition, RED is designed to control the queue
    length which would affect delay implicitly. It does not control
    latency directly. Hence, the Internet today still lacks an effective
    design that can control buffer latency to improve the quality of
    experience to latency-sensitive applications. Notably, a recent IETF
    AQM working group draft [IETF-AQM] calls for new methods of
    controlling network latency."

This certainly needs to recognize that RFC7567 has been published and 
that when published, this obsoleted the RFC2309, explicitly revoking 
the recommendation to use RED in RFC2309.

I actually think the whole of this para needs reworked - there's no 
reference to RED itself, which seems necessary. Most of the points seem 
similar to points already made in RFC7567, and it would seem wiser to 
refer to these by section (if needed) than to write something slightly 
different here. I suspect this is just a result of the AQM WG work 
proceeding in parallel with the work in TSVWG, and could be easily resolved.

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Tue, 24 May 2016 01:06:20 +0000

Please see inline.

Thanks,

Rong

Waiting for Chair¹s comments...

>RFC7567. So maybe using [RFC2309] was used on purpose.

RFC2309 is mentioned as it highly recommends AQM like RED, which is why
RED has
found wide-adoption. It is mentioned to indicate the history of AQM
designs.
Changed IETF-AQM to RFC7567.

>measurements or using estimations calculated from the queue length and

Done. 

>Again, be consistent across the entire doc.

I have changed departure to dequeue to be clear.

>   CBQ has been a standard feature in most network devices today[CBQ]
>

These are in? [CBQ] Cisco White Paper,
"http://www.cisco.com/en/US/docs/12_0t/12_0tfeature/guide/cbwfq.html".

  [TCP-Models] Misra, V., Gong, W., and Towsley, D., "Fluid-base
Analysis of a Network of AQM Routers Supporting TCP Flows with an
Application to RED", SIGCOMM 2000

Maybe because of special control characters (that I need to fix), they
don¹t show up? I will look into these.

>   MUST to be implemented and optional SHOULD/MAY enhancement elements.

Done.

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Tue, 24 May 2016 01:49:45 +0000

>proceeding in parallel with the work in TSVWG, and could be easily

This paragraph intends to give a brief history of AQM, in which RFC2309 has
played a very important role. I do think we think we should include it
here. I will change its reference as the following,
³Back in 1998, RFC 2309[RFC2309]
    strongly recommended the adoption of AQM schemes in the network to
    improve the performance of the Internet."

I changed IETF-AQM to RFC7567 and added a reference to RED.

Thanks,

Rong

---

From: Benoit Claise <[email-masked]>
Date: Tue, 24 May 2016 08:41:25 +0200

Dear Rong,
>> proceeding in parallel with the work in TSVWG, and could be easily
I agree with Gory.
> I changed IETF-AQM to RFC7567 and added a reference to RED.
I believe you missed the most important point, i.e. explaining in the 
text that the RFC2309 is obsolete.
For example:

     "Back in 1998, RFC 2309[RFC2309], now obsoleted by RFC7567,
     strongly recommended the adoption of AQM schemes in the network to
     improve the performance of the Internet."

Regards, Benoit

> .

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Tue, 24 May 2016 17:47:29 +0000

Got it and included the following to draft version 08.

Thanks,

Rong