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

[Michael Menth <[e-mail]>]

Hi Tom,

> Changes
>
> 1. Added text in the introduction to describe the experiment 
> (requested by Pete Resnick).
* committed bandwidth is strange, you mean the rate of admitted traffic
* link capacity is wrong, this should be admissible rate
* a long duration of the experiment is not needed if pre-congestion is 
caused intentionally


> 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
Using ETM-Rate instead of (PCN-sent-rate - SAR) may be a correct 
workaround for CL but not for SM! With SM, the PCN traffic rate is 
terminated down to the admissible rate in the absence of traffic loss. 
The approach corresponding to CL would be (NM-Rate + ETM-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.
This works for CL but not for SM, see my previous email!

> 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.
Moving the old text to 3-in-1 means that this doc is now aware of 
3-in-1. Therefore, we should base this edge behavior no longer on 
baseline encoding (RFC5696) but on 3-in-1.

>
> 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.
I think to remember that 3-in-1 recommended recoloring as preferred 
policing option.

> 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 
which 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.
I do not understand why the defined marking algorithms are not 
sufficient. Also packet-size-independent excess-traffic-marking is 
defined (see 2.4 in RFC5670).

Regards,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: [phone]
fax: [phone]
mailto:[e-mail]
http://kn.inf.uni-tuebingen.de