Pre-Congestion Notification (PCN) Architecture
RFC 5559

[Ballot comment]
Clearing my Discuss now I have found Section 12.3.

Can I suggest that you rebrand sections 12 and 13 not as appendixes. Also that you so not use the first person plural in the text of secition 12. I think the RFC is supposed to represent at least WG consensus and so the first person is a little ambiguous.

[Ballot discuss]
I'm going to carry on with Dave Ward's Discuss at least until I have heard an answer from the authors. I think the Discuss could be addressed by a short paragraph caveating the applicability and mentioning avalanche scenarios.

[Ballot discuss]
This document is extremely difficult to follow. On the telechat, Lars told us that it is difficult to follow because there are significant portions of the solution that are out of scope for the WG. Everybody in the WG understands what those things are, so they understand the document. But the document is incomprehensible to an outsider.

I recommend that you reorganize the document as follows:

- a brief description of he problem statement
- a brief overview of the solution, including the parts that are out of scope
- a detailed description of the parts that are in scope.

                                    Ron

[Ballot discuss]
This document is extremely difficult to follow. On the telechat, Lars told us that it is difficult to follow because there are significant portions of the solution that are out of scope for the WG. Everybody in the WG understands what those things are, so they understand the document. But the document is incomprehensible to an outsider.

I recommend that you reorganize the document as follows:

- a brief description of he problem statement
- a brief overview of the solution, including the parts that are out of scope
- a detailed description of the parts that are in scope.

                                    Ron

[Ballot discuss]
As its currently written, it's quite difficult to actually
understand the architecture by reading this document. We had
a useful discussion during the IESG telechat (where Lars explained
some of these things), but some of that needs to be in the document.

The beginning of section 6 should mention two other parts of the
high-level approach: signalling protocol between PCN-egress-nodes and
PCN-ingress nodes, and "some kind of protocol/interface" between
PCN-ingress-nodes and "something" (how PCN-ingress node gets the
information about flows -- five-tuples/agreed rate/flowspec).

Also, the document needs some more clarity about the latter interface
(how PCN-ingress-nodes get the flowspecs etc.) and what the
architecture expects about this interface. It seems different
environments might use different protocols for this interface, but
there seem to be architectural aspects (independent of the concrete
protocol) that should be discussed in this document.

[Ballot discuss]
This is sort a "holding" discuss, which I intend to either clear or update within a couple of weeks. I would like to get routing directorate review of this document, as it clearly has significant implications on routers.

[Ballot discuss]
The beginning of section 6 should mention two other parts of the
high-level approach: signalling protocol between PCN-egress-nodes and
PCN-ingress nodes, and "some kind of protocol/interface" between
PCN-ingress-nodes and "something" (how PCN-ingress node gets the
information about flows -- five-tuples/agreed rate/flowspec).

Also, the document needs some more clarity about the latter interface
(how PCN-ingress-nodes get the flowspecs etc.) and what the
architecture expects about this interface. It seems different
environments might use different protocols for this interface, but
there seem to be architectural aspects (independent of the concrete
protocol) that should be discussed in this document.

[Ballot discuss]
Although never expanded in the document, the acronym OAM is widely used in Section 9 as short for Operations and Management.

There is an ongoing inconsistency in the industry and the IETF about what OAM is supposed to mean. An I-D draft-andersson-mpls-tp-oam-def tries to put some order, and OAM is meant to be expanded differently then in this document. It would be very useful if this document would not deepen the inconsistency. For this purpose I suggest that all occurences of 'OAM' be replaced by 'Operations and Management' all over this document.

[Ballot discuss]
This idea appears to have the issue that if the variance introduced by new sessions coming on exceeds the tolerance in the marking zone (eg, if there is plenty of capacity for one HDTV stream but not enough for two, and someone turns on a second TV while the first is watching a show), that can impact the application in the existing channel. The simulations have tested the ability of the system to operate when properly operated and properly configured; they have not seriously considered avalanche scenarios.

Avalanche scenarios are a variation of the "mother's day" problem, on a millisecond time scale; in real time applications such as voice and especially video it is possible to outrun an essentially infinite bandwidth pool during short time scales. Consider concerns with realtime video conferencing and the very careful planning  to ensure that the network can handle that class of traffic - on a 45 MBPS link with three data streams that nominally run 5 MBPS standing and ~12 MBPS at peaks (I-frame). There are demonstrated issues in picture quality due to conniption fits in the network and as a result force  more careful traffic pacing.

I think this is fine in parts of the network where avalanche scenarios are unusual but, that has to be clearly stated and that the idea does not work in other use cases.

(1.a) Who is the Document Shepherd for this document?

Scott Bradner

Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

yes & yes

(1.b) Has the document had adequate review both from key WG members and from
key non-WG members?

WG members - yes

Does the Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

no

(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization or XML?

no

(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be aware
of?

no

For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it.

no

In any event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

n/a

Has an IPR disclosure related to this document been filed? If so, please include a
reference to the disclosure and summarize the WG discussion and conclusion on this
issue.

no IPR disclosure on this document, none on the PCN WG


(1.e) How solid is the WG consensus behind this document?

strong

Does it represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

I think the active members of the WG agree with the document

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

no

If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is entered into the ID Tracker.)

n/a

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this
check needs to be thorough.

1/ it passed ID nits when posted
2/ I see no other issues

Has the document met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

n/a

(1.h) Has the document split its references into normative and informative?

yes

Are there normative references to documents that are not ready for advancement or
are otherwise in an unclear state?

no

If such normative references exist, what is the strategy for their completion?

n/a

Are there normative references that are downward references, as described in
[RFC3967]?

no

If so, list these downward references to support the Area Director in the Last
Call procedure for them [RFC3967].

n/a

(1.i) Has the Document Shepherd verified that the document IANA consideration
section exists and is consistent with the body of the document?

yes

If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries? Are the IANA registries clearly identified?

n/a

If the document creates a new registry, does it define the proposed initial
contents of the registry and an allocation procedure for future registrations?

n/a

Does it suggest a reasonable name for the new registry? See [RFC5226].

n/a

If the document describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed Expert during
the IESG Evaluation?

n/a

(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB definitions,
etc., validate correctly in an automated checker?

n/a

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes a general architecture for flow admission and termination
based on pre-congestion information in order to protect the quality of service of
established inelastic flows within a single DiffServ domain. This document is a
product of the PCN working group

Working Group Summary

This document was the subject of good discussion in the working group and a good
consensus was reached that this document describes the PCN architecture

Document Quality

This document was reviewed by the PCN working group in multiple meetings and by
the Document Shepherd (Scott Bradner).