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

From: Tom Taylor <[email-masked]>
Date: Wed, 9 Mar 2011 16:09:12 -0500

Coming at this with a fresh view, I've done a lot of it. Comments below. 
Thanks for your efforts.

On 18/12/2010 5:41 PM, Michael Menth wrote:
> 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.

[PTT] Done.
>
> 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.

[PTT] 3.2.1 does not define those terms, only indicate what markings are 
used for them. Actually, the markings are first stated earlier than 
that, in section 2. Re 3-in-1: I'll review that given subsequent 
developments.
>
> 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!

[PTT] Used Toby's suggestion: ... can be carried on ...
>
> p7/8: T-* (3x): An interval, the value of which is configurable, ...
> -> An interval whose duration is configurable ...

[PTT] Again, used the suggestion Toby made to me earlier in a private note.
>
> 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.

[PTT] Good catch for these. When I finished making the correction I 
realized that the bullet dealing with ETM-rate was no longer CL-specific.
>
> 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!

[PTT] Rephrased to talk about indication of liveness.
>
> p12: an amount of flow -> flows

[PTT] Rephrased.
>
> 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]].

[PTT] No action taken.
>
> p13
> 3.3.3 Decision Point Action For -> for
> Missing PCN-Boundary -> Missing PCN-Boundary

[PTT] OK
>
> p14 observation of at least thirty PCN-packets
> Where does this number come from?

[PTT] It came from my memory of a statistics course taken 50 years ago. 
Digging into the textbooks, I found only that 30 is about the number of 
observations needed to make the distribution of error look like the 
normal distribution. I decided to take the sentence out.
>
> 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?
>
[PTT] I still think I need to distinguish the timers so I can say when 
they are reset. On the IEA issue, I haven't figured out how to make a 
postamble to a table break where I want it to (using XML2RFC). So if I 
asterisked the expansion of the abbreviation and put it at the bottom of 
the table it would run on with the note about ThM-rate being 
CL-specific. And if you missed reading it above the table, how much 
worse would it be if it were in the terminology section, then saw its 
only use in the table. (I don't want to use it throughout the document 
because that would turn the document into some kind of code.)
>
> 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!

[PTT] Again, rephrased as indication of liveness.
>
> ... 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 ...

[PTT] Explained earlier. The signalling draft sets the requirements for 
the actual transport protocol.
>
> 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.

[PTT] I expect this will change anyway when I deal with David's comments.
>
> 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)

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

[PTT] Done, except I expect other references have such results too, so I 
said "e.g., [MeLe10]".
>
> 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.

[PTT] I defer to the opinion of the WG.
>
> ... Packets belonging to ... flowspec.
>
> ... flowspec that were possibly signalled by a resource signalling protocol
> for flow admission.

[PTT] Used Toby's wording.
>
> 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.

[PTT] Rephrased as: "As a result, while the encoding uses a single DSCP 
value, that value MAY vary from one deployment to another."
>
> p17
>
> o Whether ... (2x)
> -> o Indication whether ...

[PTT] Used terminology also used in a later paragraph: 
"Activation/deactivation of ..."
>
> 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.

[PTT] Used Toby's modified text.
>
> 5.5 Assumptions
>
> This section calls for bullets to simplify reading.

[PTT] Done.
>
> I'll review the SM-draft only in the next version when these and other
> corrections have been applied.
>
> Best wishes,
>
> Michael