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

"Benoit Claise" <bclaise@cisco.com> Thu, 19 May 2016 12:30 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: aqm@ietf.org
Delivered-To: aqm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADA212B069; Thu, 19 May 2016 05:30:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160519123034.17334.51236.idtracker@ietfa.amsl.com>
Date: Thu, 19 May 2016 05:30:34 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/-3BIV3wIbj4WIQALNdiZiWLY87M>
Cc: wes@mti-systems.com, mahesh Jethanandani <mjethanandani@gmail.com>, draft-ietf-aqm-pie@ietf.org, aqm-chairs@ietf.org, aqm@ietf.org
Subject: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-pie-07: (with COMMENT)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2016 12:30:34 -0000

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
(--).