Subject: [PCN] draft-ietf-pcn-cl-edge-behaviour-08 posted

From: Tom Taylor <[email-masked]>
Date: Wed, 15 Dec 2010 23:56:29 -0500

I have submitted draft-ietf-pcn-cl-edge-behaviour-08 with the changes 
indicated in my two responses to the AD review notes, modified by list 
discussion. Please have a look while I finish updating the SM draft.

Diff is available at

http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-cl-edge-behaviour-08

Tom Taylor

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 16 Dec 2010 09:10:36 +0000

Hi Tom

Thank you very much!

It looks good to me!

Best regards,
Georgios

On 12/16/2010, "Tom Taylor" <[email-masked]> wrote:

>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Sat, 18 Dec 2010 23:41:11 +0100

Hi Tom,

Hi Tom,

thank you for your hard work in editing the two drafts.
I reviewed the latest version of the CL document. Here are my comments.

p5: of the Disffserv codepoint and ECN fields -> and the ECN field.

p6: threshold-marked and excess-traffic-marked is not defined; the fact that
     it is only defined in 3.2.1 makes the doc harder to read. I suggest 
defining
     it in the terminology section to help the reader.
     I still do not understand why the reference to the 3-in-1 marking 
was left
     while its content is basically repeated in this doc.

p7: def. of SAR: The estimated maximum rate of PCN-traffic that can be 
admitted to
     -> ... can be tolerated on ...
     At that stage, no more flows could be admitted!

p7/8: T-* (3x): An interval, the value of which is configurable, ...
     -> An interval whose duration is configurable ...

p9: ThM-rate: ... (i.e., marked with the PM codepoint);
     -> marked with the EXP codepoint).

     ETM-rate: ... (i.e., marked with the EXP codepoint).
     -> marked with the PM codepoint.

p10: T-maxsuppress functions as a keep-alive mechanism ...
     -> as a hello mechanism
     (these messages do not keep anything alive, they just show liveliness)

p11: This provides some protection against loss of egress reports and ...
     Hm, I don't think this provides protection, it just makes visible that
     something does not work anymore. Either drop this sentence or clarify
     what your exactly mean!

p12: an amount of flow -> flows

p13: If the difference ... single round of decision. Alternatively ... 
[MeLe10]).

     -> If the difference calculated in the second round is positive, it
     is an estimate for the PCN traffic rate of the respective
     ingress-egress-aggregate that should be terminated to remove overload
     (excess of PCN-supportable-rate) on some link. The Decision Point 
SHOULD
     terminate traffic until the PCN-sent-rate is no longer greater than 
SAR.

     There are different strategies for the Decision Point to remove excess
     traffic. For instance, it may terminate an appropriate set of flows in
     one shot if it knows exact flow rates, e.g. from resource signalling,
     or it may terminate traffic incrementally over several measurement
     intervals. Special care has to be taken if the difference is less than
     than the rate than the smallest rate of the flows in the corresponding
     ingress-egress-aggregate. Some termination options have been 
proposed and
     investigated in Section 4.6 of [MeLe10].

     If the Decision Point has to terminate traffic more than once, it is
     RECOMMENDED that sufficient time has elapsed between successive 
termination
     steps so that the effect of previous termination steps is reflected 
in the
     measurements upon which the current termination decision is based.
     Otherwise, too much traffic may be terminated so that overtermination
     occurs [IEEE-Satoh and Sections 4.2 and 4.3 of [MeLe10]].

p13
    3.3.3 Decision Point Action For -> for
    Missing  PCN-Boundary -> Missing PCN-Boundary

p14 observation of at least thirty PCN-packets
     Where does this number come from?

     3.5 Summary of Timers
     Here some streamlining is needed. T-* was introduced as an interval
     in the terminology section, now T-* is the actual value and t-* is the
     name of the timer. Is the latter one required at all in the doc?

     IEA is defined only over Table 1. I missed that while reading. Why not
     introduce "IEA" as an abbreviation in the terminology section?

p15 ... keep-alive procedure.
     -> hello-mechanism. ?
     keep-alive is actually needed when a softstate needs to be maintained,
     this is here not the case. Or is it? If so, make it explicit!

     ... as proposed by the transport protocol specification.
     What are you referring to? This is hard to understand. Sounds like the
     signalling draft which is not cited ...

     The means by which this is done ...
     "this" refers to the last sentence which does not make sense. You mean
     another sentence before: rephrase! A new paragraph is not needed.

p16 (e.g. due to network failures): that is very general and maybe not 
so clear
     -> (e.g. due to link or node failures with subsequent rerouting)

     The CL boundary node behaviour is less ...
     -> The performance results in [MeLe10] have shown that the CL ...

5.2.1 ... PCN-ingress-nodes MUST block ECN-capable traffic  that uses 
the same DSCP as PCN ...

I don't agree. I think that the ECN field of such traffic should be set
to 00 (not-ECN), which means that ECN is basically disabled. That's better
than dropping or downgrading the traffic.

... Packets belonging to  ... flowspec.

... flowspec that were possibly signalled by a resource signalling protocol
for flow admission.

5.2.2

The meaning of this sentence is not clear to me:
"As a result, they are not tied to the selection of a specific DSCP value".
Does that mean that PCN will be available for mulitple DSCPs? That's what we
always said no, but this sentence could be interpreted that way! This 
section
is not yet very comprehensible.

p17

o Whether ... (2x)
-> o Indication whether ...

p18

... to map between ... PCN-egress-node
->
o The information needed to map an ingress-egress-aggregates to a
   corresponding PCN-ingress-nodes and a corresponding PCN-egress-node.

5.5 Assumptions

This section calls for bullets to simplify reading.

I'll review the SM-draft only in the next version when these and other 
corrections have been applied.

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Wilhelm-Schickard-Institute
Lehrstuhl für Rechnernetze und Internet
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220
mailto:[email-masked], http://www.net2.uni-tuebingen.de

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 21 Dec 2010 15:46:16 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: 18 December 2010 22:41
> To: [email-masked]
> Subject: Re: [PCN] draft-ietf-pcn-cl-edge-behaviour-08 posted
> 
> Hi Tom,
> 
> Hi Tom,
> 

Agree

>      while its content is basically repeated in this doc.

Be careful not to repeat definitions that already exist in other
documents... We are already getting very near the stage of needing an
informational document listing all defined PCN terms along with their
normative reference!

3-in-1 is not worth referencing in case it delays publication. You can
(perhaps) reference Bob's new RFC6040 and explain that it relieves some of
the constraints that RFC5696 had to allow for... That way you hold the door
open for 3-in-1 without actually referencing it.

>      At that stage, no more flows could be admitted!

"can be tolerated" sounds wrong. I would suggest sticking with the original
wording or changing to "can be carried"

>      -> An interval whose duration is configurable ...

I think I sent Tom some suggested alternative wording for all these phrases.
It went something like "A configurable time interval that defines the period
over which..."

>      -> marked with the EXP codepoint).

This possibly ties the document too firmly to RFC5696. But leave this to
others to decide

>      (these messages do not keep anything alive, they just show

"as an indication the link is still live"

>      something does not work anymore. Either drop this sentence or

Agree with Michael. Going to be interesting to come up with elegant wording
though

>      occurs [IEEE-Satoh and Sections 4.2 and 4.3 of [MeLe10]].

I'm not convinced we need quite so much extra text in the main body of the
document. Quite a bit of what Michael is adding sounds like it really
belongs in an appendix.

>      Where does this number come from?

Indeed. This comes across like something plucked from the air

>      introduce "IEA" as an abbreviation in the terminology section?

as the document currently stands I think the name of the timer is
unnecessary...

agree with putting IEA in terminology section, or use an asterisk and have
it as a footnote to the table

> than dropping or downgrading the traffic.

The key is to ensure that whatever action is taken can be clearly understood
by the end hosts. Of the top of my head I can't recall the exact negotiation
rounds that ECN goes through, nor whether ECN in TCP can spot the ECN field
being reset... Personally I am really dubious about introducing a new
mechanism that resets an existing mechanism (and it might get people a bit
hot under the collar also)

> ... flowspec that were possibly signalled by a resource signalling

Change whole sentence to "Packets belonging to an admitted flow are policed
to ensure they adhere to the agreed rate or flowspec that was negotiated
during flow admission"

> is not yet very comprehensible.

There are two competing things here. Within a PCN domain the choice of DSCPs
is limited, but between domains there aren't limits (as PCN is defined as a
single domain protocol). Indeed if you read appendix a of RFC5696 it
discusses choosing "suitable DSCPs"

>    corresponding PCN-ingress-nodes and a corresponding PCN-egress-node.

"The information needed to map an IEA to the corresponding PCN-ingress-node
and PCN-egress-node"

> This section calls for bullets to simplify reading.

Agree

Toby

PS I /may/ go through both documents again myself and see if I can spot any
other changes. But we are already at risk of changing so much that we will
have to go back to square one of the publication process (and the IESG are
going to start to wonder why we didn't do all this first time round!)

---

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Dec 2010 12:46:31 -0500

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Toby Moncaster
> Sent: Tuesday, December 21, 2010 10:46 AM
> To: 'Michael Menth'; [email-masked]

Hi,

You are only at square one of the publication process. The documents
are in AD Evaluation; they have not gone to the IESG yet. We ARE doing
all this the first time round. Hopefully, this all this work will
smooth the way through the IESG Evaluation. ;-) 

dbh

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Dec 2010 15:20:09 -0500

Thank you for your review. In this awkward stage between the end of WGLC 
and the beginning of IETF Last Call, I'm not sure I can do anything to 
the document beyond satisfying AD comments. I'll take Steven Blake's 
advice on that, as PROTO Shepherd.

In any event, I have comments on some of your points. Please see below.

> p5: of the Disffserv codepoint and ECN fields -> and the ECN field.

[PTT] Can't change that -- it's a direct quotation. Anyway, I think it's 
correct. The sentence is talking about the behaviour aggregate.
> it in the terminology section to help the reader.

[PTT] Face it, if you don't read the architecture document you can't 
really understand this one.

> I still do not understand why the reference to the 3-in-1 marking was left

[PTT] Process issues. It would introduce an undesirable dependency.
> -> An interval whose duration is configurable ...

[PTT] Toby Moncaster didn't like that either. Guess it's a choice 
between grammatical correctness ("who" refers to persons) and 
naturalness of expression. As Churchill said: "That is a criticism up 
with which I will not put!"
> -> marked with the PM codepoint.

[PTT] Good catch! That has to be fixed right away, regardless of the 
stage of process.
> p12: an amount of flow -> flows

[PTT] First it detewrmines an amount, then it selects flows to achieve 
that amount.
> (excess of PCN-supportable-rate) on some link. The Decision Point SHOULD
> terminate traffic until the PCN-sent-rate is no longer greater than SAR.
>
> ingress-egress-aggregate. Some termination options have been proposed and
> RECOMMENDED that sufficient time has elapsed between successive termination
> steps so that the effect of previous termination steps is reflected in the

[PTT] It's the number you need to get the standard deviation of the 
average below a certain level if you are observing normally-distributed 
variates. Maybe a stretch to apply it to this statistical context, but 
better than nothing.
> name of the timer. Is the latter one required at all in the doc?

[PTT] Yes, otherwise how can I talk about action taken upon expiry?
> introduce "IEA" as an abbreviation in the terminology section?

[PTT] The table is the only point at which it is used in the document. I 
have to use it there for lack of space, otherwise I would avpoid it 
entirely.
> signalling draft which is not cited ...

[PTT] What I am referring to is the document that specifies the actual 
transport protocol. The only concrete candidate at the moment is the 
proposal I've co-authored with others to use Diameter for the purpose. 
BTW none of this will apply for the piggybacking edge behaviour, if that 
ever gets written up.
> 5.2.1 ... PCN-ingress-nodes MUST block ECN-capable traffic that uses the
> same DSCP as PCN ...
>

[PTT] File an erratum against RFC 5559, then.
> is not yet very comprehensible.

[PTT] File an erratum against RFC 5696, which this quotes.
> corrections have been applied.
...

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Dec 2010 15:30:28 -0500

Needless to say, I started writing this a few hours ago, before all the 
other notes arrived on the list, and didn't check the list until I sent 
it. I'll look them over.

...