[PCN] CL Edge Behaviour Draft

[<Ruediger.Geib at telekom.de>]

Tom,

a second set of comments, on the CL draft.

Thanks for your work. The draft is clearer than the first version. I 
still miss details how to measure an IEA. That the "howto" is an 
issue isn't even mentioned in the draft.

Regards,

Ruediger


Some comments:

1.1 terminology and following chapters

A new PCN node called "Policy Decision Point" is added to the architecture. 
The document does not explain where it is located and by which interfaces 
and priotocols it communicates. The draft text however seems to make this
PDP mandatory in some instances.

My personal take: remove the "Policy Decision Point" and all references to
it from this draft and write an experimental architecture draft explaining
the concept.

-----------------

3.1 Overview

Last section: "..supplies a list of excess-traffic-marked flows .." 
This is an IntServ concept rather than a DiffServ one. While recognising 
that dealing with ECMP is an issue, I don't like the idea of any per flow 
functionality on a backbone node. If you assume to be deployed in an 
application gateway operating PCN per flow identification, please mention 
that.

-----------------

3.2.1 PCN Egress Node Role in flow admission

new_CLE is the value of old_CLE during the next iteration, but the text 
doesn't state that. As you never know what an implementor understands 
from this text, the formula may be changed or text added.

"k" should be from  0 < k < 1. The text should state that.

------------------

3.2.2 PCN Egress Node Role in flow termination

1st section
"...it immediately resets NM-count and ThM-count.."
In this case, two measurement intervals have to pass to get an accurate 
value of "old_CLE", is that correct? If not, the text should state this.

3rd section 
"..to record flow identifiers.." As mentioned I don't like the concept.
If maintained despite my concerns, please specify what a "flow 
identifier" is.

Formula/definition:

"...ratio: R = ThM-count..."

Here a new definition is applied for R while the ratio itself isn't 
evaluated. Is it harmful to stick with the section 2.2.1 definition 
of R while termination state is detected? Or asking differently, 
could any error arise after termination state has ended and the ETM
packets aren't accounted for the old_CLE values? I don't think so.

-------------------

3.3.2 PCN-Ingress-Node role in Flow Termination

1st section: "... It immediately begins to measure the rate.."
This incurs more delay.

-------------------

4.5 Assumptions

"Recovery from overloads should happen within 1-3 seconds."

Collecting two CLE values at the egress is at minimum 200 ms.
Informing the Ingress another 20 ms, say, which then starts to 
measure, taking at least another 100 ms. In your draft, the 
ingress must contact a PDP, that'll take another 50 ms (RTT).

That's approximately 400 ms with processing and minimum 
evaluation configurations. Isn't 1 second fairly optimistic 
for a recovery from overload? 

-------------------

4.7 Environmental Concerns

Please change the 2nd sentence

If the mechanism flow termination can't be enabled, signaling the 
corresponding state may be used to reduce traffic by other means 
like codec adaptation or the drop of low priority video frames.
This is however out of scope of the PCN WG.

-------------------

4.8 and 5. Security Considerations

Delete one section.