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

[Michael Menth <[e-mail]>]

Hi Tom,

Am 21.03.2012 22:47, schrieb Tom Taylor:
> 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.
But when you deploy PCN for the sake of an experiment, then you can.

>
>> * 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.
But when you want to perform the experiment, then you want to experience 
challenging conditions. Maybe in a testbed to avoid losing revenues.

>>
>>> 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.
I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid 
confusion by a soon obsoleted RFC.

>>>
>>> 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.
ok, now I see the reference was some sentences before

>>
>>> 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.
ok, understand

Regards,

     Michael

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