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

From: [email-masked] (Scott O. Bradner)
Date: Sat, 10 Jul 2010 09:30:56 -0400 (EDT)

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

---

From: <[email-masked]>
Date: Mon, 12 Jul 2010 11:40:04 +0100

Some comments on the CL draft. I guess some of them are applicable to SM as well.
Thanks
Phil

My only non-editorial comment is:-
S3.2.4
So CLE is not smoothed, even optionally?
[sorry - my brain hasn't been in PCN mode for ages, so I probably forget old agreements!]

Abstract
>>Precongestion notification (PCN) is a means for protecting quality of
   service for inelastic traffic admitted to a Diffserv domain.
Precongestion notification (PCN) is a means for protecting the quality of
   service of inelastic traffic admitted to a Diffserv domain.
[reads better to me]

>>PCN edge
Rfc5559 uses the term PCN-boundary-node. Ditto several times through the doc.

Intro
>>thus providing notification to boundary nodes about
   overloads before any congestion occurs
Change to "incipient overloads"?

>>The level of marking allows decisions to
   be made on whether to admit or terminate individual flows
Delete "individual" [seems redundant]

Terminology
PCN traffic => PCN-traffic [several times]

"admission decision threshold"
Suggest hyphenate. I didn't find it obvious later [S3.3.1...] that it's a defined term.
Also, later "CLElimit" appears as a synonym for admission(-)decision(-)threshold, maybe this should appear in the terminology?

S2
>>   o  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];
Delete "Extensions for this purpose will be specified by the IETF." - the next sentence says enough.

You could hypehnate some of the defined terms from RFC5559,
Domain => PCN-domain; packets => PCN-packets
Threshold meter => threshold-meter; Excess-traffic-meter

>>   o  a PCN packet which is not-marked (NM) MAY be threshold-marked
      (ThM) or excess-traffic-marked (ETM);

   o  a PCN packet which is threshold-marked (ThM) MAY be excess-
      traffic-marked (ETM).
Which => that (*2) [ietf defines how it uses which and that!]
Similarly for the first bullet in S3.2.1

S3.1
New para after first sentence?

The PCN egress node collects and reports the rates
Could add 'for each ingress-egress-aggregate'
Could hyphenate PCN-egress-node

S3.2.4
So CLE is not smoothed, even optionally?
[sorry - my brain hasn't been in PCN mode for ages, so I probably forget old agreements!]

S3.3.1
>>If the CLE was not
   provided in the report, the Decision Point MUST calculate it.
Maybe repeat the formula, or say "using the formula in S3.2.4"

S3.3.2
>> an estimate of the rate
   (Admit-Rate) at which PCN-traffic is being admitted to the aggregate
I don't like the phrasing. How about "an estimate of the
      rate of PCN-traffic that is destined for this specific PCN-egress-
      node" or "... this specific ingress-egress-aggregate".

S3.5
The table is good, though slightly odd that it's the first time seen the names of the Timers in first column

S5.3
"Recovery from overloads
   through the use of flow termination should happen within 1-3 seconds."
I think this was a requirement - and not a performance estimate. my guess is that PCN flow termination will actually do better than this.

S5.4
>>   o  The DSCP(s) to be used to mark PCN traffic.
This needs to be something more general like "how the traffic is marked" [which anyway will include ECN field as well as dscp]
This parameter is also missing from the interior node list

>>edgepoints
PCN-boundary-nodes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Scott O. Bradner
> Sent: 10 July 2010 14:31
> To: [email-masked]
> Subject: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>
>
>
> this starts a WGLC for
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 16 Jul 2010 09:13:03 -0400

This comment is about the report suppression capability. Currently reports can 
be omitted if no PCN marking was observed. It has been suggested that we could 
cut down the messaging even further if we used a reporting threshold for 
computed CLE, such that there would be no report if computed CLE for the 
interval (and for the previous interval) was below the reporting threshold.

Comments?

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 16 Jul 2010 14:22:47 +0100

That seems a reasonable proposal, but we would probably want to say that it
should default to something very low.

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: 16 July 2010 14:13
> To: Scott O. Bradner
> Cc: [email-masked]
> Subject: Re: [PCN] PCN WGLC for the CL and SM edge behaviour drafts
>

---

From: Michael Menth <[email-masked]>
Date: Fri, 16 Jul 2010 15:23:43 +0200

Hi Tom,

I am in favor of leaving the mechanism as simple as it is, i.e., do not 
introduce another parameter that possibly avoids a few signalling 
messages in rare cases. We are talking about pre-congestion which should 
not occur during normal operation so that the savings potential for 
signalling messages is rather low.

Best wishes,

    Michael

Tom Taylor schrieb:
> This comment is about the report suppression capability. Currently 
> reports can be omitted if no PCN marking was observed. It has been 
> suggested that we could cut down the messaging even further if we used 
> a reporting threshold for computed CLE, such that there would be no 
> report if computed CLE for the interval (and for the previous 
> interval) was below the reporting threshold.
>
> Comments?
>
> Scott O. Bradner wrote:
>> 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).
>>

-- 
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: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 16 Jul 2010 16:27:43 +0200

Hi Tom

I agree with the argumentation of Michael, i.e., do not introduce another
parameter that possibly avoids 
a few signalling messages in rare cases.   

Best regards,
Georgios

> Behalf Of Michael Menth
> Sent: vrijdag 16 juli 2010 15:24
> To: Tom Taylor
> Cc: [email-masked]
> I am in favor of leaving the mechanism as simple as it is, 
> i.e., do not introduce another parameter that possibly avoids 
> a few signalling messages in rare cases. We are talking about 
> pre-congestion which should not occur during normal operation 
> so that the savings potential for signalling messages is rather low.
> 
> Best wishes,
> 
>     Michael
> 
> Tom Taylor schrieb:
> 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]

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 16 Jul 2010 23:08:02 +0800

Hi Michael,

I think the most frequent scenario is that very few packets are PCN-marked for each interval, but the scenario that no packets are PCN-marked is actually a rare case. The following data shows the frequency of each scenario in my mind (the data is just for example):
    1) No packets are PCN-marked:          25%;
    2) Very few packets are PCN-marked: 65%
    3) Some packets are PCN-marked:      6%
    4) Many packets are PCN-marked:      3%
    5) All packets are PCN-marked:          1%

But without a reporting threshold as suggested by Tom, many reports will be sent to the decision point in the 2) scenario. So I think Tom's proposal really makes sense. 

Best regards,
Fortune

---

From: Michael Menth <[email-masked]>
Date: Fri, 16 Jul 2010 17:29:42 +0200

Hi Fortune,

I think that most of the time no packets will be PCN-marked at all and 
for this case signalling reduction already minimizes the signalling 
traffic. When some packets are marked, the PCN traffic rate is already 
close to to some PCN-threshold and this is usually not the normal 
operating condition of a network. Note that short traffic bursts do not 
mark packets if the queue size of the meter is set large enough. Also 
see page 7 of
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08f.pdf

I think that the savings of the new mechanism will be small so that an 
additional parameter makes the overal mechanism just more complex. Apart 
from that, I do not think that the new mechanism does any more harm than 
actual signalling reduction.  A general problem with signalling 
reduction is the following: if the first PCN report with "low PCN 
pre-congestion" after a pre-congestion period is lost, further reports 
are suppressed and the decision point still assumes pre-congestion so 
that the decision point may block longer than needed. But this is 
probably also a corner case.

Kind regards,

    Michael

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 16 Jul 2010 23:53:38 +0800

Hi Michael,

Even if that most of the tim no packets will be PCN-marked, it doesn't change the fact that the 2) scenario happens much more often than scenario 3), 4) and 5).
For example, it might be like the following:
     1) No packets are PCN-marked:          65%              // switch the percentages.
     2) Very few packets are PCN-marked: 25%
     3) Some packets are PCN-marked:      6%
     4) Many packets are PCN-marked:      3%
     5) All packets are PCN-marked:          1%

Generally speaking, a report should be sent in scenario 3), 4) and 5), but it doesn't need to be sent in scenario 2).
For the old mechanism, (25 + 6 + 3 + 1)% of the time a report should be sent; 
But for the new mechanism, (6 + 3+1)% of the time a report should be sent;
As you can see, 100% * 25/(25 + 6 + 3 + 1) = 71% signalling messages could be saved and this is certainly not a small proportion.

Best regards,
Fortune

---

From: Michael Menth <[email-masked]>
Date: Sat, 17 Jul 2010 09:02:06 +0200

Hi Fortune,

it is clear that "some marked packets" are on the transition path from 
"no marked packets" to "all packets marked" and vice-versa. How often we 
see that in practice depends very much on the capacity of the network. I 
don't fight against the additional parameter that saves some signalling 
messages during the transition phase, I just want to point out that it 
does not lead to tremendous savings and makes the configuration  
unnecessarily more complex.

Your example: you assume that at least some packets are marked in 35% of 
the time. This would probably happen only in networks that are not well 
provisioned. Therefore, I do not think that it is realistic.

Kind regards,

    Michael

---

From: Fortune HUANG <[email-masked]>
Date: Sat, 17 Jul 2010 16:22:48 +0800

Hi Michael,

I am sorry that my previous example seems confusing.
Actually it is not important that packets are marked in 35% of the time or in 1% of the time. What really matters is that normally only very few packets are marked when packets are marked. Let's get rid of the time when no packets are marked but consider only the time when packets are marked.

      1) Very few packets are PCN-marked: 70%
      2) Some packets are PCN-marked:      15%
      3) Many packets are PCN-marked:      10%
      4) All packets are PCN-marked:          5%

For the old mechanism, in 100% of the time when packets are marked, a report should be sent.
For the new mechanism, only in 30% of the time when packets are marked, a report should be sent.
So 70% of the signalling messages will be saved by using the new mechanism.

Best regards,
Fortune

---

From: Michael Menth <[email-masked]>
Date: Sat, 17 Jul 2010 10:57:40 +0200

Hi Fortune,

I understand that you report conditional probabilities. The results are 
valid only under the condition that some packets are marked at all. My 
reasoning is that this is already a rare case and, therefore, the 
absolute savings in signalling overhead are small.

Regards,

    Michael

---

From: Fortune HUANG <[email-masked]>
Date: Sun, 18 Jul 2010 09:08:01 +0800

Hi Michael,

This saving is very important especially for the centralized case because a centralized decision point needs to handle reports from many PCN-egress-nodes for many ingress-egress-aggregates per PCN-egress-node. If you are against the new mechanism for the all the scenarios, a compromise would be  that we only apply it to the centralized case. Is that acceptable for you?

Best regards,
Fortune

---

From: Michael Menth <[email-masked]>
Date: Sun, 18 Jul 2010 08:25:26 +0200

Hi Fortune,

as a university person I am not building equipment and accept 
architectural necessities of manufacturers and network operators. 
Therefore, I have nothing against the new mechanism. I just point out 
inefficiencies or exaggerated expectations on savings.

Best wishes,

    Michael

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 11:25:05 +0200

Hi Tom,

thanks for working out a quite reasonable draft. I've one issue which I brought up several times and you did your best to write down somethinhg reasonable. My main question is, whether the topic how to identify an ingress-egress aggregate should be put out of scope for this document explicitely. A requirement specifying soltions should be mentioned in your draft. Or a discussion convincinng me that no such specification is required.

The introduction says 

"Boundary node behaviours specify a detailed set of algorithms and
edge node behaviours used to implement the PCN mechanisms."

Section 4 says:

"4.  Identifying Ingress and Egress Nodes for PCN Traffic

   The operation of PCN depends on the ability of the ingress node to
   identify the ingress-egress-aggregate to which each new flow belongs
   and the ability of the egress node to identify the aggregate to which
   each received PCN packet belongs.  If the Decision Point is
   collocated with the ingress node, the egress node also needs to
   associate each aggregate with the address of the ingress node to
   which it must send its reports.

   The means by which this is done depends on the packet routing
   technology in use in the network.  In general, classification of
   individual packets at the ingress node (for enforcement and metering
   of admission rates) and at the egress node must use the content of
   the outer packet header.  The process may well require configuration
   of routing information in the ingress and egress nodes." 

To me, this is not a detailed specification. Should we explicitely state that operationg PCN may require a routing set up and / or network configuration adapted to PCN operation? I'd rather prefer that to raising the impression that PCN may be operated on any Internet platform.

Your text is somehow stating that, I guess. But worries me if you refer to the "outer packet header" in section 4, while no other PCN document states that tunnels are a requirement (or is that a requirement I missed?).

I don't insist on doing this exactly as I propose it above. But I'd like the text above text to give a better indication to interested operators, that additional engineering on edge node and routing features is required before deploying PCN.  

Regards,

Ruediger

---

From: Michael Menth <[email-masked]>
Date: Thu, 29 Jul 2010 21:14:48 +0200

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