Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation
draft-ietf-pcn-sm-edge-behaviour-12

[Ballot comment]
Please include in the document some information about the nature of the experiment.

Some 2119 and like comments:

3.2.1.  Data Collection

  The PCN-egress-node MUST meter the PCN-traffic it receives in order

MUST is wrong here. "needs to"

  Informative note:

What does the word "Informative" add here? I think you should strike it.

3.3

  A compliant Decision Point MUST implement both mechanisms

Why? What is the interoperability problem or damage to the network if I don't implement both?

3.3.3 - I don't understand the interoperability or damage implications of most of the SHOULDs in this section, especially the "notify management" ones. Even the timer ones:

  A centralized Decision Point SHOULD start a timer t-sndFail when it
  sends a request for the estimated value of PCN-sent-rate to a given
  PCN-ingress-node.  If the Decision Point fails to receive a response
  from the PCN-ingress-node before t-sndFail reaches the configurable
  value T-crit, the Decision Point SHOULD repeat the request...

The second SHOULD is probably right. The first SHOULD is at least redundant and I think more likely just misused. The interoperability concern is when to repeat the request, which is when t-sndFail reaches T-crit. That the Decision Point starts the timer on send is either obvious (how else would it know), or it's an implementation choice (it determines resends in some other way), but either way it's not the *starting* of the timer that's the protocol instruction.

[Ballot discuss]
I intend to clear this one on the call, but I wanted to leave it as a reminder to DISCUSS:

What is the "experiment" for this and for the -cl document? Are these competing approaches and the experiment will determine which way to go? Or are both documents simply not ready for prime time and more experimentation is needed? I think this ought to be explained somewhere in the document, or at least in the writeup.

[Ballot comment]
Some 2119 and like comments:


3.2.1.  Data Collection

  The PCN-egress-node MUST meter the PCN-traffic it receives in order

MUST is wrong here. "needs to"

  Informative note:

What does the word "Informative" add here? I think you should strike it.

3.3

  A compliant Decision Point MUST implement both mechanisms

Why? What is the interoperability problem or damage to the network if I don't implement both?

3.3.3 - I don't understand the interoperability or damage implications of most of the SHOULDs in this section, especially the "notify management" ones. Even the timer ones:

  A centralized Decision Point SHOULD start a timer t-sndFail when it
  sends a request for the estimated value of PCN-sent-rate to a given
  PCN-ingress-node.  If the Decision Point fails to receive a response
  from the PCN-ingress-node before t-sndFail reaches the configurable
  value T-crit, the Decision Point SHOULD repeat the request...

The second SHOULD is probably right. The first SHOULD is at least redundant and I think more likely just misused. The interoperability concern is when to repeat the request, which is when t-sndFail reaches T-crit. That the Decision Point starts the timer on send is either obvious (how else would it know), or it's an implementation choice (it determines resends in some other way), but either way it's not the *starting* of the timer that's the protocol instruction.

[Ballot comment]
s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think that adding some text along the lines of "The decision point is considered to be part of a PCN-node; therefore, the decision point is considered to be trusted for truthful decisions."  This makes it clear that s6.3.1 of RFC 5559 applies.

s4.2.1: I find it a little odd that you say you're paraphrasing two sections but there's 2119 language in this draft where there was none in RFC 5559.  Granted it's mostly MAY this and MAY that so it's not that big of a deal, but there is a MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559 in that case?

s1.1: Need to add NOT RECOMMENDED to the key words.

[Ballot discuss]

  The Gen-ART Review by Joel Halpern on 31-Dec-2011 raised several
  issues.  That lead to a significant discussion, but not all of the
  issues have been resolved.

[Ballot comment]
- The security considerations section doesn't note the inherent
vulnerability if the decision point is separated from the enforcement
point(s). That is, the enforcement points (in/egress nodes) have to
have an interface that could be called from some malicious node. Even
if the PDP/PEP protocol is not in scope here, this scheme means that
problem exists and there are clear DoS vectors implicit in that. RFC
5559 which is referenced from this does say that "The signalling
between the PCN-boundary-nodes must be protected from attacks" so I
guess this is not discuss-worthy.

- Total nit: t-recvFail is not a great name for a time - too easy to
mistake for a subtraction, I'd suggest t_recvFail if it makes no
difference. (And same for other names.)

[Ballot comment]
This document contains quite a bit of requirements terminology. Are we sure that
Informational is appropriate? Did the WG consider making this a standards-track
Applicability Statement (Section 3.2 of RFC 2026)?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Single Marking (SM) Mode of
  Operation'
  as an Informational RFC

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
ietf@ietf.org mailing lists by 2012-01-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Pre-congestion notification (PCN) is a means for protecting the
  quality of service for inelastic traffic admitted to a Diffserv
  domain.  The overall PCN architecture is described in RFC 5559.  This
  memo is one of a series describing possible boundary node behaviours
  for a PCN-domain.  The behaviour described here is that for a form of
  measurement-based load control using two PCN marking states, not-
  marked, and excess-traffic-marked.  This behaviour is known
  informally as the Single Marking (SM) PCN-boundary-node behaviour.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Single Marking (SM) Mode of
  Operation'
  as an Informational RFC

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
ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Pre-congestion notification (PCN) is a means for protecting the
  quality of service for inelastic traffic admitted to a Diffserv
  domain.  The overall PCN architecture is described in RFC 5559.  This
  memo is one of a series describing possible boundary node behaviours
  for a PCN-domain.  The behaviour described here is that for a form of
  measurement-based load control using two PCN marking states, not-
  marked, and excess-traffic-marked.  This behaviour is known
  informally as the Single Marking (SM) PCN-boundary-node behaviour.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Single Marking (SM) Mode of
  Operation'
  as an Informational RFC

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
ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


Pre-congestion notification (PCN) is a means for protecting the
quality of service for inelastic traffic admitted to a Diffserv
domain.  The overall PCN architecture is described in RFC 5559.  This
memo is one of a series describing possible boundary node behaviours
for a PCN-domain.  The behaviour described here is that for a form of
measurement-based load control using two PCN marking states, not-
marked, and excess-traffic-marked.  This behaviour is known
informally as the Single Marking (SM) PCN edge behaviour.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-sm-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.

AD Followup for SM -05- and CL -08-

I reviewed SM -05- and found only minor editorial problems.

1) In the last paragraph of section 3, the paragraph about T-fail, the second sentence starts with "As for T-maxsuppress," which seems out of place.

2) At the end of 5.1, the nore to RFC Editor says RFCyyyy = sm-edge-behavior; is this correct? it seems to discuss cl edge behavior.

3) In the discussion of SAR calculation, you changed U from a factor lesser than to a factor greater than. This was deliberate, right?

Please correct these as part of responding to IETF Last Call comments. No need to publish a revision before IETF LC.

---
I compared the common text in CL -08- and SM -05-.
I just want to verify these differences are deliberate:

1) in section 2, the reference rate is set to PCN-supportable for CL, but PCN-admissible for SM.

2) in 3.2.1, the ETM-rate for CL is marked with the EXP codepoint, but ETM-rate for CL is marked with the PM codepoint.
(while the ThM rate for CL i smarked with the PM codepoint)

3) in 5.3, termination SHOULD happen for cl, but termination should happen for SM. (note case)

4) in 5.4, paramaters for each interior node, reference rate "on each link" for CL, and 'on each inward link" for SM

Please verify these were deliberate.

AD Review:

1) As I reviewed both the SM and CL edge behavior documents, I noted
with concern how similar the documents are. I wonder if you wouldn't
be better having one document, with common text in the early chapters,
and then a section for SM and a section for CL. Or even three
documents, to pave the way for addiitonal behavior documents.

The real concern is that when you have so much common text, you need
to work hard to keep them consistent. An additional concern is that
the IETF (in LC) IESG (in IESG Eval) will need to review these docs,
and check that you haven't overlooked anything; the IETF and IESG
basically perform sanity checks. This is made harder when the text is
almost the same in the two documents. If the editorial text is just
slightly different in multiple places, it becomes much harder to find
the important differences between the documents.

My concrn has been realized. There are many unimportant differences
between these two documents, that make comparing the two documents
more difficult than it should be, such as:
  such that PCN keep-alive signalling is redundant.
  such that PCN keep-alive is redundant.

  o  NM-rate: octets per second of PCN-traffic in PCN-packets that
are
      not-marked;
  o  NM-rate: octets per second of PCN-traffic in PCN-packets that
are
      not PCN-Marked;

  egress-node, and the Decision Point (which may be collocated with
the
  egress-node and the Decision Point (which may be collocated with
the

  The PCN-egress-node collects the rates of not-marked, threshold-
  marked, and excess-traffic-marked PCN-traffic for each ingress-
  egress-aggregate and reports them to the Decision Point.  It may
also
  The PCN-egress-node collects and reports the rates of not-marked
and
  excess-traffic-marked PCN-traffic to the Decision Point.
** the sentence structure is unnecssarily different, which makes it
just a little bit harder to read what the technical difference is.

  PCN was that recovery from overloads through the use of flow
  termination should happen within 1-3 seconds.  PCN probably
performs
  better than that.
  PCN was that recovery from overloads by flow termination should
  happen within 1-3 seconds.  PCN probably does better than this.

  o  The marking rules for re-marking PCN-traffic leaving the PCN
  o  The marking rules for re-marking PCN traffic leaving the PCN


  The PCN SM per-domain behaviour may interfere with the use of
end-to-
  end ECN due to reuse of ECN bits for PCN marking.  See Appendix B
of
  [RFC5696] for details.
  The PCN CL per-domain behaviour may interfere with the use of
end-to-
  end ECN due to reuse of ECN bits for PCN marking.  See the
applicable
  PCN marking specifications for details.
dbh: is [5696] the applicable specs? or are there others? How does a
reader determine which specs are applicable?

  quality of service of inelastic flows within a Diffserv domain, in
a
  quality of service (QoS) of inelastic flows within a Diffserv
domain,

  allows decisions to be made on whether to admit or terminate PCN-
  decisions to be made about whether to admit or terminate individual

This editorial inconsistency could hide small, potentially important
technical differences, such as:
  o  ETM-rate: octets per second of PCN-traffic in PCN-packets that
are
      excess-traffic-marked.
  o  ETM-rate: octets per second of PCN traffic in PCN-Marked
packets.

  2.  The amount of traffic that should be terminated is the
      difference:
  2.  The amount of traffic that must be terminated is the
difference:

  choose to complete its selection of PCN-flows to terminate in a
  single round of decisions.
  choose to complete its selection of flows to terminate in a single
  round of decisions.

  node SHOULD cease to admit PCN-flows to the
ingress-egress-aggregate
  node SHOULD cease to admit flows to the ingress-egress-aggregate

  T-maxsuppress if report suppression is enabled, and of the order of
3
  T-maxsuppress if report suppression is activated, and of the order
of

  about incipient overloads before any congestion occurs (hence the
  about overloads before any congestion occurs (hence the "pre" part
of

  o  on each link the reference rate for the excess-traffic-meter is
      configured with a PCN-excess-rate to be equal to the PCN-
      admissible-rate for the link;
  o  on each link the reference rate for the excess traffic meter is
      configured to be equal to the PCN-supportable-rate for the link;
  o  on each link the reference rate for the threshold-meter is
      configured to be equal to the PCN-admissible-rate for the link;

if you are going to have two documents with so much common text, I
will expect the editorial text to be consistent, so the technical
differences are clear.

2) Why are individual flow identifiers reported for
excess-traffic-marked PCN-traffic for CL but not for SM? Wouldn't this
be useful for both?

3) From Acknowledgements:    The authors thank Ruediger Geib for his
useful comments.  The acknowledgements in the CL boundary node
behaviour draft really apply here, too.
dbh: the CL draft is likely to be an RFC. If you want the
acknowledgement in both places, put it in both places.

4) I would be careful referencing other works-in-porgress, just in
case anything slows down the other document(s). No sense holding up
the publication of this document because another document runs into a
delay.

5) please check all lower-case RFC2119 keywords. The IESG prefers that
they be uppercased to make it clear they are normative. I recommend
using "might" rather than "may" for non-normative, and re-wording
musts, shoulds, and recommends to avoid using lowercased reserved
words.

6) section 3.2 and section 3.3.2 both present the formula for CLE, but
they present it differently. Just a style issue, but I recommend
presenting it consistently.

7) section 3.3 "The Decision Point MUST"; I recommend saying "A
compliant Decision Point MUST"

8) "PCN traffic" is used here, but where that term is defined is not
mentioned. Since this is used in formulae, that could be important to
understand correctly.

9) in 3.5, do we really need both t-meas and T-meas, etc.? The chart
would be easier to read if you eliminated one of the redundant
columns.

10) in Table 1, some word breaks are missing from the Action on Expiry
column. Put a space between conditionally and CLE, and between each
and IEA.

11) The acronym IEA is not defined before being used.

12) t-maxsuppress has discussion of the value to use for an unreliable
transport; what is the recommended value for a reliable transport?

13) section 4 title has extra spaces.

Document shepherd write-up for                                  2010-10-20
draft-ietf-pcn-sm-edge-behaviour-04

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

>      Steven Blake, PCN co-chair
 
        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? 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.
       
>      Not applicable
       
        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

  (1.e) How solid is the WG consensus behind this document? 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? 

>      The primary working group contributors have all indicated
>      approval for the document.  There were few comments on this
>      document during WGLC.  There are no vocal dissenters.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? 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.)

>      No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

>      The document fails ID-nits with one error and one comment:
>
>      Error) There are 2 instances of lines with control characters in
>          the document. [TAB characters in line 89 and 623]
>
>      Comment) The document date (September 14, 2010) is 37 days in the past.
>          Is this intentional?  [Yes; blame the shepherd's forgetfullness].

  (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?  If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

>      All normative references in the document are RFCs.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?
       
>      An IANA Considerations section exists, but no requests are
>      made to IANA.
       
        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. 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?

>      Not applicable

  (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?

>      Not applicable

  (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 possible boundary node behaviour
>      for a PCN-domain (as defined in RFC 5559), known informally as
>      the Single Marking (SM) PCN-boundary-node behaviour.
>      The behaviour described here is a form of measurement-based
>      load control using two PCN marking states: not-marked, and
>      excess-traffic-marked.

    Working Group Summary

>      The document was subject to thorough review by the PCN working
>      group, and strong consensus for publication was reached.

    Document Quality

>      The document was reviewed by the document shephard (Steven Blake).