Subject: Re: Last Call: <draft-ietf-tsvwg-byte-pkt-congest-09.txt> (Byte and Packet Congestion Notification) to Best Current Practice

From: John Leslie <[email-masked]>
Date: Wed, 6 Mar 2013 04:15:10 -0500

The IESG <[email-masked]> wrote:
> 
> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document:
> - 'Byte and Packet Congestion Notification'
>   <draft-ietf-tsvwg-byte-pkt-congest-09.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-03-07. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

   This document has a rather long history in TSVWG, and IMHO deserves
to be published as is, but not as a Best Current Practice.

   Fundamentally, it updates RFC 2309 (an Informational document) to
deprecate a practice which seems essentially unused, and goes into detail
appropriate to an academic paper about the theoretical basis for doing
this.

   According to the document writeup I find in the datatracker:
] 
] This document is intended as BCP. (This was discussed at IETF-81 and that
] the status changed from Informational to BCP, because the draft provides
] guidance to implementors and people configuring routers and hosts).

   I cannot find any minutes for that WG meeting. I am willing to believe
Gorry that such a recommendation happened at that meeting (where I was not
present), but I do not find it to have been discussed on-list at all.

   I do not agree that its major purpose is to provide such advice, nor
do I see how "implementors and people configuring" would be likely to
get clear advice from a 43-page document that reads like an academic
paper. For one example:

> Abstract
>    This document provides recommendations of best current practice for
>    dropping or marking packets using active queue management (AQM) such
>    as random early detection (RED) or pre-congestion notification (PCN).
>    We give three strong recommendations: (1) packet size should be taken
>    into account when transports read and respond to congestion
>    indications...

   "Packet size should be taken into account when transports read and
respond to congestion indications" is simply too vague. There has been
on-list discussion of what this might mean; but it has not resulted in
clear, concise advice to implementors.

   In no sense do I believe it worth holding up this document any longer
to add "clear advice" -- I believe that would only add years to the delay.
The document deserves to be published, but with Informational status so
folks don't spend their time trying to interpret its "advice".

--
John Leslie <[email-masked]>

---

From: [email-masked]
Date: Wed, 6 Mar 2013 09:50:01 -0000

Thanks for the note. I'd like to respond on the question of intended
status. I hope this may allow others to also comment.

The discussion on the proposed milestone was at  IETF-81, Quebec City,
http://tools.ietf.org/wg/tsvwg/minutes?item=minutes81.html.  This was
followed-up with the ADs, with a result that the document milestone
proposed BCP status.

I do note that this updates an Informational draft, and do not know of
other normative dependencies.

Now is the correct time to check the standards status if this needs to be
reviewed.  As I understand, this is an AD decision.

Gorry
(tsvwg Co-Chair)

---

From: SM <[email-masked]>
Date: Fri, 08 Mar 2013 01:37:17 -0800

>followed-up with the ADs, with a result that the document milestone

This is a quick comment.  Although RFC 2309 is informational, it was 
interesting to read.

As a nit about the Abstract, I suggest using "memo" instead of "document".

In Section 4:

  "This section is informative, not normative."

I read "informative" as providing useful or interesting 
information.  I don't know what "not normative" is.  The section is 
actually narrative.  It explains why the intended status of the memo 
should be BCP (note that I have not read the minutes).

The memo is basically recommendations about RED in byte mode or 
packet mode.  I did not fully appreciate the writing style on my 
first reading of the memo.

In summary, the answers for whether this memo should be a BCP are 'it 
depends', 'no' and 'yes'.

Regards,
-sm