Subject: Re: [tsvwg] 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: t.petch <[email-masked]>
Date: Thu, 7 Mar 2013 17:56:33 +0000

----- Original Message -----
From: "John Leslie" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 06, 2013 9:15 AM
> present), but I do not find it to have been discussed on-list at all.

John

I agree that minutes for IETF81 appear not to have been circulated but
they are available at

http://tools.ietf.org/wg/tsvwg/minutes?item=minutes81.html

and do record the discussion and its outcome.

The agreement of the change in status to BCP was reported to the list in
passing, 7 Sep 2011, and provoked no comment, no discussion.

And the WGLC last call clearly stated BCP as did Bob's summary of the
updates.

So we knew about it, if we wanted to, and did not comment.

Tom Petch

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Mar 2013 18:48:20 +0000

Tom,

Tx for the forensics on the request to switch to BCP from INF, which 
are correct.

I just want to add that the change from INF to BCP required a 
complete re-write to itemise the recommendations clearly and briefly.

On length:

         The average size of all the IETFs BCPs is 41905 Bytes
         (Source: <http://www.rfc-editor.org/bcp-index.html>)

         draft-ietf-tsvwg-byte-pkt-congest-09.txt is 47528 Bytes
         (including the appendix listing all the draft deltas, which 
will be removed by the RFC editor)

Jukka did a great job of cutting down the doc to 26pp (without the 
appendices). The recommendations are all pulled together into the 
first major section, p8-11. Then the second major section justifies 
them in p12-16.

The rest is critique of past advice, which the WG decided to keep, 
because if people in the past thought differently, people in the 
present will jump to the same conclusions and believe they are still 
right, unless we document why ideas changed.

John's point about academic style criticises a sentence in the 
abstract for being too vague. An abstract says what the document is 
about. Most people understand that they have to read a little further 
than the abstract to get to the specific advice.

Bob

> > folks don't spend their time trying to interpret its "advice".

________________________________________________________________
Bob Briscoe,                                                  BT