Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts

From: <[email-masked]>
Date: Tue, 3 Aug 2010 13:23:19 +0100

Lcle is horrid. Let's stick with the name we're familiar with.

<<Drepsup is a configurable value for the maximum duration of continuous report suppression.>>
I find this change hard to understand ['continuous report suppression' = ?]
Repsup is hard to guess; maxnorep was easier.

I can see why you want the names for limits to be easily distinguished from the names of the variable. I'd simply use T_x and t_x [ie the data x is reported once the timer t_x has reached the value T_x]
I also suggest better names than 'mi' - it's hard to guess this means measurement interval, there are no prizes for as few characters as possible.

I don't like your change of 'amount of traffic to be terminated' to 'Termination rate'. The latter suggests to me a continual process where you keep terminating this amount, whereas the former suggest a one-off process.

You deleted the phrase that the decision point MAY choose to terminate in one step or it MAY choose to spread over a longer period. I think it's better with this phrase.
In general, I don't like the changes round the end of 3.3.2

<<The PCN-ingress-node MUST provide the estimated current rate of
   sent PCN traffic (octets per second) for a specific ingress-
   egress-aggregate >>
'sent' is better than 'admitted'. I think it would be better to say something like:
The PCN-ingress-node MUST provide an estimate of the current rate of PCN-traffic that is destined for this specific PCN-egress-node.

<<Identifying Ingress and Egress Nodes for PCN Traffic
...  The procedure to provide the required information is out of the scope of this document.>>
Ruediger, does this change pass your test?

5.4
<<Reference rates on each inward link for threshold-marking and excess-traffic-marking; see Section 2.>>
Better:
The reference rates on each inward link, PCN-threshold-rate and PCN-excess-rate; see Section 2.

Thanks
phil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Menth
> Sent: 29 July 2010 20:15
> Cc: [email-masked]
> Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>
>
> Hi Tom, hi all,
>
> sorry for being late. I made some proposals for better
> formulations in
> some cases when I found a passage hard to understand. I also suggest
> improved names for variables using the following idea:
> Txyz: a timer name
> Dxyz: the duration after which timer Txyz expires
> I suggested more selfexplaining timer names for xyz
> Suggest to change the variable name:
> admission-decision-threshold (CLElimit) -> CLE limit (Lcle),
> otherwise
> this is confusing.
>
> I hope my comments are all well visible in the attached Word
> file since
> Word crashed twice while revising the doc.
>
> I also took care of Ruediger's comment and added appropriate text.
>
> Kind regards,
>
>     Michael
>
>
> Scott O. Bradner schrieb:
> > this starts a WGLC for
> >  "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode
> >   of Operation"  (draft-ietf-pcn-cl-edge-behaviour)  and
> >   "PCN Boundary Node Behaviour for the Single Marking (SM) Mode
> >    of Operation" (draft-ietf-pcn-sm-edge-behaviour).
> >
> > comments to the list by July 24 please
> >
> > Scott
> > _______________________________________________
> > PCN mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> PD Dr. habil. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632
> (new) mailto:[email-masked]
> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>

---

From: Michael Menth <[email-masked]>
Date: Tue, 03 Aug 2010 19:00:49 +0200

Hi Phil,

> Lcle is horrid. Let's stick with the name we're familiar with.
Well, consistently taking D for durations, T for timers, and L for 
limits suggests to move CLElimit to Lcle. I'm sure that this is only a 
matter of familiarization. However, as such a limit is used only once, I 
do not insist on the one letter indication rule for limits.

> Repsup is hard to guess; maxnorep was easier.
I do not insist on _repsup for report suppression, _maxnorep works also 
for me. However, the duration is not really the duration after which a 
report must be sent because the next report will be sent only after the 
next measurement interval is over. Therefore, the maximum time during 
which no reports are received is larger than D_maxnorep. That was my 
motivation to rename Dmaxnorep it to  D_repsup, the duration during 
which reports are suppressed. Does that make sense?

> I can see why you want the names for limits to be easily distinguished from the names of the variable. I'd simply use T_x and t_x [ie the data x is reported once the timer t_x has reached the value…
I am fine with any distinction that makes clear what's a timer and 
what's a value. Tx and Dx just seems simpler to me than T_x and t_x, but 
this is not essential to me.

> I also suggest better names than 'mi' - it's hard to guess this means measurement interval, there are no prizes for as few characters as possible.
I don't object better names. I just proposed this as an improvement over 
Tcalc which makes it hard to guess that it is related to the duration of 
the measurement interval. There are so many calculations at different 
nodes so that Tcalc does not seem to be specific enough for me ...

> I don't like your change of 'amount of traffic to be terminated' to 'Termination rate'. The latter suggests to me a continual process where you keep terminating this amount, whereas the former sugg…
Well, I used to argue against this term for long time for exactly the 
reasons you are stating. I just adopted it as it was consistently used 
by Anna and others. As long as it is explained what it means I am fine 
with it. I just think that we must name the quantity somehow to 
facilitate talking about the mechanism.

> In general, I don't like the changes round the end of 3.3.2
The existing text was not clear enough for me, that's why I elaborated 
this section.

> The PCN-ingress-node MUST provide an estimate of the current rate of PCN-traffic that is destined for this specific PCN-egress-node.
That's fine with me.

> Ruediger, does this change pass your test?
I proposed this text to him in a private email and he replied that he 
was ok with this phrasing.

> The reference rates on each inward link, PCN-threshold-rate and PCN-excess-rate; see Section 2.
Not better, but equivalent ;-) I'm fine with this change.

Tom, can you take care of these changes to my corrections, please?

Kind regards,

    Michael

-- 
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 4 Aug 2010 09:36:51 +0200

Phil, Michael

[snip]
Michael: <<Identifying Ingress and Egress Nodes for PCN Traffic
...  The procedure to provide the required information is out of the scope of this document.>>
Phil: Ruediger, does this change pass your test?
[snip]

Thanks, yes, that's sufficient.

Regards, Ruediger

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 10:22:39 +0200

Hello Michael,

one additional remark,

On your question on 3.3 I'd suggest a simple answer:

If only Termination is active, new flows are addmitted by default until termination state is reached. Then some traffic may have to be terminated and new traffic shouldn't be admitted. Details on such an operational regime are out of scope of this document.

Would that make sense?

Regards,

Ruediger 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Thursday, July 29, 2010 9:15 PM
Cc: [email-masked]
Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts

Hi Tom, hi all,

sorry for being late. I made some proposals for better formulations in 
some cases when I found a passage hard to understand. I also suggest 
improved names for variables using the following idea:
Txyz: a timer name
Dxyz: the duration after which timer Txyz expires
I suggested more selfexplaining timer names for xyz
Suggest to change the variable name:
admission-decision-threshold (CLElimit) -> CLE limit (Lcle), otherwise 
this is confusing.

I hope my comments are all well visible in the attached Word file since 
Word crashed twice while revising the doc.

Kind regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Fri, 20 Aug 2010 10:36:55 +0200

Hi Rüdiger,

I think your email is regarding this text in the draft:

   Operators may choose to deploy just flow admission, or just flow
   termination, or both.  The Decision Point MUST implement both
   mechanisms, but configurable options MUST be provided to activate or
   deactivate PCN-based flow admission and flow termination
   independently of each other at a given Decision Point.

> If only Termination is active, new flows are addmitted by default until termination state is reached. Then some traffic may have to be terminated and new traffic shouldn't be admitted. Details on s…

How can "shouldn't be admitted" be enforced? I believe flow termination 
requires admission control to be implemented.

Does anybody have a clear vision how flow termination without admission 
control is feasible?

Regards,

    Michael

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 10:46:47 +0200

Hello Michael,

during the Maastricht meeting we agreed to avoid the term "implicit probing". To me, probing would mean transmitting packets for the only purpose of probing (i.e. they carry no other information or have any other purpose then probing). What the draft proposes however is to mark one (or more) regular signaling packets which are transmitted along the same path as a PCN data packet with the same PCN code point as a data packet. 

To me "PCN marked signaling" seems a proper definition of what we propose. Are there objections or better suggestions on the idea? 

Regards,

Ruediger

---

From: Michael Menth <[email-masked]>
Date: Fri, 20 Aug 2010 10:49:48 +0200

Hi Rüdiger,

yes, that's correct. We need a different name. I currently work with 
"signalling-inferred admission control". I am open for improvements.

Best wishes,

    Michael

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 11:38:48 +0200

Hi Michael,

>>>I currently work with 

If others don't express preferences, we can stick with that one too.

Regards, Ruediger

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Aug 2010 11:55:28 -0400

Below, following Michael's query.

On 20/08/2010 4:36 AM, Michael Menth wrote:
>> If only Termination is active, new flows are addmitted by default until
>> termination state is reached. Then some traffic may have to be terminated and
>> new traffic shouldn't be admitted. Details on such an operational regime are
>> out of scope of this document.
>> Would that make sense?
>
> How can "shouldn't be admitted" be enforced? I believe flow termination requires
> admission control to be implemented.
>
> Does anybody have a clear vision how flow termination without admission control
> is feasible?
>
> Regards,
>
> Michael
>
[PTT] My own feeling is we should stick strictly to how flow termination works 
and leave it up to the operator to sort out the question of admission. I think 
that's what Ruediger was trying to say, and I would phrase it like this:

If flow termination is enabled but flow admission is not, flow termination 
operates as specified in this document. Logically, some system of flow admission 
control is needed to keep new flows from being admitted to an 
ingress-egress-aggregate while flows are being terminated on that aggregate, but 
the operation of such a system is out of scope of this document and depends on 
local arrangements.

---

From: Michael Menth <[email-masked]>
Date: Fri, 20 Aug 2010 21:46:39 +0200

Tom Taylor schrieb:
> [PTT] My own feeling is we should stick strictly to how flow 
> termination works and leave it up to the operator to sort out the 
> question of admission. I think that's what Ruediger was trying to say, 
> and I would phrase it like this:
>
> If flow termination is enabled but flow admission is not, flow 
> termination operates as specified in this document. Logically, some 
> system of flow admission control is needed to keep new flows from 
> being admitted to an ingress-egress-aggregate while flows are being 
> terminated on that aggregate, but the operation of such a system is 
> out of scope of this document and depends on local arrangements.

This phrase is somehow a contradiction: "but flow admission is not 
[enabled]" & "some system of flow admission control is needed" ...

Tom, your sentence basically says that PCN-based flow termination can be 
done with some other sort of admission control which does not need to be 
based on PCN. That is something I agree with. What I dislike is a strong 
statement that flow termination can be used without (any kind of) 
admission control. Can't we just say that PCN-based AC can be used on 
its own or in combination with flow termination? Why is this other 
statement (flow termination alone can be used) necessary if nobody knows 
how to implement it now? Isn't it enough to not forbid it?

Regards,

    Michael

---

From: Steven Blake <[email-masked]>
Date: Sun, 29 Aug 2010 23:25:09 -0400

> comments to the list by July 24 please

This last call has run a little longer than planned.  :)  But there have
been good stream of comments.

Let's wrap this WGLC up on Friday this week (Sept. 3).

Regards,

// Steve