[PCN] Explanation of changes in the PCN edge behaviour drafts

[Tom Taylor <[e-mail]>]

All changes apply to both documents except for the change in description 
of the factor U, which is SM-specific.

David, you may not have been aware of the need for item 10. Please 
verify that it is OK.

Hope everyone is happy with the changes. Please note additional fixes 
called out at the end of item 13. I think these can be taken care of in 
AUTH 48.

Changes

1. Added text in the introduction to describe the experiment (requested 
by Pete Resnick).

2. Lower-cased a MUST in the paragraph following the new text, talking 
about the need to fill out a per-hop behaviour template. (Part of an 
attempt to clean out unnecessary RFC 2119 language mentioned by two ADs.)

3. Trivial: replaced all t- and T- names for timers and durations with 
t_ and T_ as suggested by Stephen Farrell to avoid confusion with 
arithmetic operations. (Actually missed a few in the CL draft and will 
have to get them in AUTH 48.)

4. First line of Section 3.2.1: replaced "MUST" with "needs to" for 
metering. Changed "informational note" to "Note" after the bullets (both 
at Pete Resnick's suggestion).

5. Section 3.3, first paragraph, talking about support of flow admission 
and termination mechanisms: changed "A Decision Point MUST support both 
mechanisms, but ..." to "If a Decision Point supports both mechanisms, 
...". (Pete Resnick -- couldn't see any interoperability issue to 
justify the MUST.)

6. Section 3.3.3, talking about failure to receive a response from the 
ingress node. Rewrote in an attempt both to satisfy Pete Resnick's 
concern about over-use of mandatory language and to make the mandatory 
procedures clearer.

OLD

    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 but MAY
    also use ETM-rate as an estimate of the amount of traffic to be
    terminated in place of the quantity

       PCN-sent-rate - SAR

    specified in Section 3.3.2.  Because this will over-estimate the
    amount of traffic to be terminated due to dropping of PCN-packets by
    interior nodes, the Decision Point SHOULD use multiple rounds of
    termination under these circumstances.  If the second request to the
    PCN-ingress-node also fails, the Decision Point SHOULD notify
    management.

       The use of T-crit is an approximation.  A more precise limit would
       be of the order of two round-trip times, plus an allowance for
       processing at each end, plus an allowance for variance in these
       values.

NEW

    If a centralized Decision Point sends a request for the estimated
    value of PCN-sent-rate to a given PCN-ingress-node and fails to
    receive a response in a reasonable amount of time, the Decision Point
    SHOULD repeat the request once.  While waiting after sending this
    second request, the Decision Point MAY begin selecting flows to
    terminate, using ETM-rate as an estimate of the amount of traffic to
    be terminated in place of the quantity

       PCN-sent-rate - SAR

    specified in Section 3.3.2.  Because ETM-rate will over-estimate the
    amount of traffic to be terminated due to dropping of PCN-packets by
    interior nodes, the Decision Point SHOULD terminate less than the
    full amount ETM-rate in the first pass and recalculate the additional
    amount to terminate in additional passes based on subsequent reports
    from the PCN-egress-node.  If the second request to the PCN-ingress-
    node also fails, the Decision Point MUST select flows to terminate
    based on the ETM-rate approximation as just described and should
    notify management.

       The response timer t_sndFail with upper bound T_crit is specified
       in Section 3.5.  The use of T_crit is an approximation.  A more
       precise limit would be of the order of two round-trip times, plus
       an allowance for processing at each end, plus an allowance for
       variance in these values.

7. Section 3.4, note giving an example of how the PCN-ingress-node does 
its estimate: changed the "MAY" to a "can".

8. Section 3.5, action for expiry of t_sndFail: referred back to Section 
3.3.3 instead of the previous inaccurate summary of a fairly complex 
procedure.

9. Removed all RFC 2119 language from Section 4 (the per-hop behaviour 
section). Originally responding to a comment by Sean Turner that Section 
4.2.1 claimed to paraphrase RFC 5559 but had such language where RFC 
5559 did not. Decided that it wasn't necessary elsewhere in the section, 
either.

10. Based on discussion of the 3-in-1 draft, at Bob Briscoe's request, 
changed section 4.2.1 to focus only on the tunneling option and the 
resulting non-problem with use of ECN bits.

OLD

    Packets at the ingress to the domain are classified as either PCN or
    non-PCN.  Non-PCN packets MAY share the network with PCN packets
    within the domain.  Because the encoding specified in [RFC5696] and
    used in this document requires the use of the ECN fields, PCN-
    ingress-nodes MUST prevent ECN-capable traffic that uses the same
    DSCP as PCN from entering the PCN-domain directly.  The PCN-ingress-
    node can accomplish this in three ways.  The choice between these
    depends on local policy.

    o  ECN-capable traffic MAY be dropped.  This policy is NOT
       RECOMMENDED, since it prevents the proper operation of end-to-end
       ECN as a means of controlling congestion.

    o  ECN-capable traffic MAY be assigned a different DSCP from PCN
       traffic.  This could mean that it is relegated to a lower-priority
       behaviour aggregate.

    o  ECN-capable traffic MAY be tunneled across the PCN-domain.  If
       this is done, the PCN-ingress-node MUST mark packets as either
       not-PCN or PCN-not-marked only after the encapsulation of the
       packet, including any initial setting of the ECN field, has been
       completed.

NEW

    Packets at the ingress to the domain are classified as either PCN or
    non-PCN.  Non-PCN packets can share the network with PCN packets
    within the domain.  The encoding specified in [RFC5696] and used in
    this document requires the use of the ECN fields.  PCN-ingress-nodes
    need to prevent ECN-capable traffic that uses the same DSCP as PCN
    from entering the PCN-domain directly.  This is not an issue when
    tunneling of PCN-packets between the PCN-ingress-node and the PCN-
    egress-node is done, as recommended in Section 5.1.2, provided that
    the original ECN markings of arriving packets are preserved in the
    encapsulated headers.

11. In the next paragraph, originally said that PCN packets of 
non-admitted flows are dropped. Replaced this with "blocked" and a 
backward reference to the definition of blocking in Section 1. 
(Follow-through on comments by Brian Carpenter, fixed elsewhere.

12. Section 4.7: originally said PCN use of ECN bits could interfere 
with the end-to-end use of ECN. Replaced with the following text:

    The PCN CL per-domain behaviour could theoretically interfere with
    the use of end-to-end ECN due to reuse of ECN bits for PCN marking.
    However, this is not a problem in practice because of the need to
    tunnel PCN-packets from ingress to egress (see Section 5.1.2).  The
    encapsulated header can retain the original ECN markings as received
    at the PCN-ingress-node, leaving the ECN bits in the encapsulating
    header fully available for use by PCN.

13. Section 5.1.3, basically editorial rearrangement of text to take 
account of the fact that the ingress node will always perform 
encapsulation. Talking about extensions to the DiffServ MIB.

OLD

    ... The required
    extensions specifically include objects for re-marking the ECN field
    at the PCN-ingress-node and an extension to the classifiers to
    include the ECN field at PCN-interior and PCN-egress-nodes.  In
    addition, the MIB has to be extended to include a potential
    encapsulation action following re-classification by ingress-egress-
    aggregate.  Finally, a new metering algorithm may need to be defined
    at the PCN-interior-nodes to handle excess-traffic-marking.

NEW

    ... The required
    extensions specifically include an encapsulation action following re-
    classification by ingress-egress-aggregate.  In addition, the MIB has
    to be extended to include objects for marking the ECN field in the
    outer header at the PCN-ingress-node and an extension to the
    classifiers to include the ECN field at PCN-interior and PCN-egress-
    nodes.  Finally, new metering algorithms may need to be defined at
    the PCN-interior-nodes to handle threshold-marking and packet-size-
    independent excess-traffic-marking.

*Oops noted* -- that text was taken from the SM document. Have to remove 
the reference to threshold-marking, and have to mark that point 
"[CL-specific]" in the CL document.

*Speaking of oops*: Section 5.1.1 still talks about the operator having 
to decide whether to use tunneling. Should that stay or go?

14. Security consideration added (Section 6), in response to comments by 
two ADs. Section now reads:

    [RFC5559] provides a general description of the security
    considerations for PCN.  This memo introduces one new consideration,
    related to the use of a centralized Decision Point.  The Decision
    Point itself is a trusted entity.  However, its use implies the
    existence of an interface on the PCN-ingress-node through which
    communication of policy decisions takes place.  That interface is a
    point of vulnerability which must be protected from denial of service
    attacks.

15. Fixed reference Mele12, naming the journal in which the article will 
appear.

16. SM-specific change in Section 3.3.2 to improve the description of 
the factor U. The new text reads:

    1.  [SM-specific] The sustainable aggregate rate (SAR) for the given
        ingress-egress-aggregate is estimated using the formula:

           SAR = U * NM-Rate

        for the latest reported interval, where U is a configurable
        factor greater than one which is the same for all ingress-egress-
        aggregates.  In effect, the value of the PCN-supportable-rate for
        each link is approximated by the expression

           U*PCN-admissible-rate

        rather than being calculated explicitly.