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

[Tom Taylor <[e-mail]>]

My comments in turn below, marked with [PTT].

David, we have a technical error in the SM document, introduced in the 
-06 version. Can I update it and resubmit?

Tom Taylor

On 21/03/2012 5:14 PM, Michael Menth wrote:
> 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

[PTT] That terminology is appropriate once PCN is running, but when you 
are evaluating a network in advance of installing PCN, I don't think you 
can talk about admissible rate.

> * a long duration of the experiment is not needed if pre-congestion is
> caused intentionally
>
[PTT] I thought hard about that, then decided operators might not be 
willing to do it. They would be throwing away customer revenue, or at 
least violating the terms of an SLA.
>
>> 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.
>>
...

> This works for CL but not for SM, see my previous email!
>
[PTT] You are absolutely right. This comes from working on CL first, 
then cutting and pasting. The bad text has been there since the -06 
version. I'll have to back it out to what was there in -05: no 
workaround, just notify management.

>> 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.
>
[PTT] I don't think we have to, although it might be reasonable. The 
argument is that there is no need for the old text because we are using 
tunneling.
>>
>> 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.

[PTT] We agreed on local policy as the answer when discussing Brian 
Carpenter's review comments.
>
>> 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?

[PTT] DiffServ MIB [RFC3289], referenced in the document.
>
>> 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).
>
The above passage is talking about whether the DiffServ MIB supports the 
defined marking algorithms, not saying that new algorithms are needed.

> Regards,
>
> Michael
>