Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Jun 2010 15:16:34 -0400

I've updated the CL edge behaviour draft based on Michael's suggestions. The 
detailed changes from the -02 version (the one in the archives before this week) 
is as follows:

1) Added definitions of NM-rate, ThM-rate, and ETM-rate in the terminology 
section. Reordered but did not change the definition of CLE, except to update 
its forward reference.

2) s/unmarked/not-marked in the first paragraph of section 3.1. Followed through 
with same change in section 2.1.

3) Modified the egress node reporting requirements in accordance with 
yesterday/today's discussion. Basic requirement to report every interval, 
configurable option to suppress reports basic on lack of marking, configurable 
option for egress node to calculate and report CLE.

4) Both flow admission and flow termination are now independently configurable 
options at the decision point.

5) Modified the text regarding the calculation of CLE at the decision point to 
take account of the possibility it is in the report from the egress node. Named 
the admission decision threshold ("CLElimit") for further reference.

6) Change details of flow termination from MUST to SHOULD as suggested at the 
last meeting, to provide some room for discretion.

7) Focussed the missing report section (3.4.3) more tightly on the viewpoint of 
the decision point. Left recommendations for values of Tfail to the "Timers" 
section 3.5. Added text covering the possibility a report is subsequently 
received from the egress node concerned.

8) Realized Michael and I were disagreeing on names for times because I was 
failing to distinguish between timers and their limits. Created a table to show 
timer name, location, how many instances are needed, the limiting value, and 
action on expiry. Also made recommendations on limiting values in this section.

9) Made a detailed list of configurable parameters for each actor in the system 
in the applicable section 5.4 of the per-domain behaviour template.

Tom Taylor

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 23 Jun 2010 15:53:26 +0100

Tom,

Overall this seems to make sense and I don't think I disagree with any of
the actual technical stuff.

A few detailed comments.

I would quite like to see decision point capitalised to clarify that it is a
defined term, and maybe even hyphenated to give Decision-point...

2.
Bullet 2 in section 2 currently reads " the domain satisfies the conditions
specified in the applicable encoding extension document;"

This carries an inherent assumption that the encoding is defined in a
document (implication being that document will be a formal IETF document),
but this assumption isn't made clear in the first bullet. 

My suggested solution is to modify the first bullet so it reads:

 "encoding of PCN status within individual packets is based on
  [RFC5696], extended to provide a third PCN encoding state. 
  Extensions for this purpose will be specified by the IETF. 
  Possible extensions are documented in [ID.PCN3state] or 
  alternatively [ID.PCN3in1];" 

End of Section 2. Would it be an idea to re-iterate the other MUST NOTS for
the marking. E.g. any packet that has been threshold-marked (ThM) or
excess-traffic-marked (ETM) MUST NOT have that marking cleared to NM

3.1.
Para 2. This was slightly confusing first time I read it, because it seems
in the wrong order. It also made it unclear that the decision point was
receiving the reports as well as requesting them. I would be tempted to put
it as:

" The PCN ingress node enforces flow admission and termination decisions.
   When requested, it reports the rate of PCN traffic admitted to a
   given ingress-egress aggregate to the decision point.
   For details, see Section 3.3."

Section 3.2.
It is RECOMMENDED that the interval, Tcalc, between calculation
Insert commas:                     ^      ^      

In the last para (starting "In networks with multipath routing"), it might
be worth expanding as to why you want to identify the particular flows so as
to ensure people make the correct choice regarding this SHOULD

3.2.2.

This seems to be back to front because it starts by referring forward,
having looked at it, I think the solution is to swap sections 3.2.2 and
3.2.3... Otherwise it is very confusing.

Para 2 of 3.2.2.
   If so configured, and if excess-traffic-marked packets
Insert comma       ^

This para is actually a bit confusing, so should refer to why the reporting
of flow identifiers may be configured.

Section 3.2.3.

" Egress reports may be lost and they are also a demonstration of
   liveness to the decision point."

No such word as liveness... This whole paragraph needs to be re-written to
improve its English and make better sense 

3.2.4.

More or less clear, but could be made much clearer. IN particular we need to
clarify that this is an option for the egress node:

"The congestion level estimate (CLE) MUST be calculated in every measurement
for every ingress-egress-aggregate. This calculation MAY be performed at the
PCN-egress node. A configurable option MUST be provided to enable this. 
If this option is enabled, then the PCN-egress-node MUST calculate the CLE
and include this value in every report it sends, along with the values for
NM-rate, ThM-rate, and ETM-rate. The CLE is equal to the ratio:

      (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate)

   if any PCN traffic was observed, or zero otherwise."

3.4.
1st sentence, add "...or both." 

3.4.1.
Clunky first sentence. Suggested replacement:

" The decision point needs to know the current CLE for every
ingress-egress-aggregate. This may be contained in the reports from the
egress. If not then when the decision point receives a report from the
egress node for a  given ingress-egress-aggregate that contains non-zero
rates, it
   calculates the CLE as described in Section 3.2.4"

Should we add "...but this is NOT RECOMMENDED" to the end of the last
sentence (after the MAY about policy)?

3.4.2.
Sentence beginning " The decision point MUST then wait, both for the"
Reverse the order of both and for (giving "...wait for both the")

Sentence starting "if the difference calculated in the second step...". The
whole sentence has too many clauses and is confusing. I suggest a complete
re-order to give:

"If the difference calculated in the second step is positive, the
   decision point SHOULD select sufficient flows to terminate 
until it determines that the PCN traffic
   admission rate will no longer be greater than the estimated
   sustainable aggregate rate. This should be based on its knowledge
   of the bandwidth required by individual flows gained from
   resource signalling, etc"

last sentence of 3.4.2 is a bit clunky, but liveable with...

3.5.

This is a nice clear section. I like things in tables :) The only question
is about recommended Tfail values which seem to be wildly different
depending whether report suppression is active or not. Are these figures
based on anything or are they gut-feel figures for what seems right?

I think that will do for now!

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: 22 June 2010 20:17
> To: pcn
> Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: Tom Taylor <[email-masked]>
Date: Fri, 25 Jun 2010 20:48:01 -0400

Thanks for the review, Toby. Responses marked by [PTT].

> defined term, and maybe even hyphenated to give Decision-point...

[PTT] Changed to Decision Point. XML2RFC is inserting blanks after hyphens, and 
I have to go through and clean up manually afterwards. I am reluctant to add 
another hyphenated term.
>   alternatively [ID.PCN3in1];" 
[PTT] Done.
> excess-traffic-marked (ETM) MUST NOT have that marking cleared to NM

[PTT] I think you're the second person to suggest that, so I've given in. I felt 
that with the introductory text to the bullet saying "these are the only 
permitted transitions", I had said enough.
>    For details, see Section 3.3."

[PTT] You're right. Done.
> Insert commas:  

[PTT] OK
                    ^      ^
> to ensure people make the correct choice regarding this SHOULD
[PTT] Done

> 3.2.3... Otherwise it is very confusing.

[PTT] Done.
> of flow identifiers may be configured.

[PTT] Reworked the wording and requirement a bit. Not sure if that meets your needs.
> improve its English and make better sense 

[PTT] Rewritten.
>    if any PCN traffic was observed, or zero otherwise."

[PTT] A little push-back here. The whole of section 3.2 is about requirements on 
the egress node. Your first sentence is actually a requirement on the system, 
and therefore violates the separation of responsibilities between actors that is 
a basic priciple of the organization of section 3. That same principle is why I 
didn't pick up Michael's nicely-written text.
> 1st sentence, add "...or both." 

[PTT] Done
>    calculates the CLE as described in Section 3.2.4"

[PTT] Played with the wording a bit more.
> sentence (after the MAY about policy)?

[PTT] This is the escape hatch for something like emergency calls or high 
priority customers. I don't think we're in a position to recommend anything.
I did add the warning: ", but such policy intervention risks defeating
the purpose of using PCN".
>    resource signalling, etc"

[PTT] I wasn't happy with that myself. Played with the wording a bit more, hope 
you like it.
> based on anything or are they gut-feel figures for what seems right?
[PTT] The general principle was to use at least 3 * the expected interval. I'm 
open to suggestions, since we're looking at something in the order of 300 ms for 
no report suppression and ten times that for report suppression.

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 26 Jun 2010 12:30:52 +0100

Thanks for that Tom. I like the new version much better and it is probably
ready for WGLC in my view (especially if you accept the suggestion I make
below...)

Some inline comments marked {TM}

Toby

> From: Tom Taylor [mailto:[email-masked]]
> Sent: 26 June 2010 01:48
> To: Toby Moncaster
> Cc: 'pcn'
> Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt
> 

{TM} new version is much clearer...

> > improve its English and make better sense

{TM} The new version is much better!

> didn't pick up Michael's nicely-written text.

{TM} OK, I can see that argument. It would be a little clearer (to me at
least) if it read 

"Congestion level estimate (CLE) calculation and reporting MUST be provided
as a configurable option at the PCN-egress-node. If this option is enabled
then the PCN-egress-node MUST calculate the current value for CLE for each
ingress-egress-aggregate in each measurement interval and include this in
its report (along with the current values of NM-rate, ThM-rate and
ETM-rate). The CLE is equal to the ratio:
	(ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate)
if any traffic was observed, or zero otherwise."

> the purpose of using PCN".

{TM} OK, that makes it clearer

> [PTT] I wasn't happy with that myself. Played with the wording a bit

{TM} Much better, thanks...

> no report suppression and ten times that for report suppression.

{TM} OK, leave it as it is, I have no views on this whatsoever... 

> >> detailed changes from the -02 version (the one in the archives
> before
> >> this week)
> >> is as follows:
> >>
> >> section. Reordered but did not change the definition of CLE, except
> to
> >> update
> >> its forward reference.
> >>
> >> 5) Modified the text regarding the calculation of CLE at the
> decision
> >> point to
> >> 6) Change details of flow termination from MUST to SHOULD as
> suggested
> >> at the
> >> 8) Realized Michael and I were disagreeing on names for times
> because I
> >> was
> >> failing to distinguish between timers and their limits. Created a
> table
> >> to show
> >> action on expiry. Also made recommendations on limiting values in
> this
> >> section.
> >>