Re: [PCN] Key results from PCN

[Steven Blake <slblake at petri-meat.com>]

On Wed, 11 Nov 2009 08:33:39 +0900, Tom Taylor <tom111.taylor at bell.net>
wrote:

> Something I missed on point 2): what does one end do if it decides that
the
> other end is dead? Particularly, what does the decision point do if it
gets
> no reports for a "long" time.

That is my point, which is why I brought up the issue of signaling channel
liveness.

Suppose the decision point is at the ingress.  The ingress knows it is
sending PCN traffic to a particular egress, and it stops getting reports
from that egress for some extended time period.  What should it do?  If the
answer is nothing, then signaling channel liveness is not an issue.  My
guess is that at some point the ingress should stop admitting new flows. 
Whatever the desired response, that will help drive the requirements for
tracking the state of the signaling channel.

> Tom Taylor wrote:
>> This is a small report in advance of the official notes, written from my

>> point of view. The key outcomes I noted from the PCN meeting were these:
>> 
>> 1) The egress node will always report the measured rates of unmarked, 
>> excess-traffic-marked, and, if applicable, threshold-marked traffic. 
>> This is for two reasons: flexibility in the application of policy at the

>> decision point, and flexibility in future applications in general.
>> 
>> 2) Two remarks apply to the signalling requirements draft. One has to do

>> with the current division into ingress vs. centralized control. Fortune 
>> has sent notes on that topic. Probably more importantly, the draft has 
>> to talk about how each end knows that the other end is alive, and how 
>> long it is permissible for the system to proceed without some assurance 
>> that the peer is still alive. Steven was going to write a note on this, 
>> since he raised it.
>> 
>> 3) The piggybacking behaviour draft needs fixing to match how RSVP and 
>> NSIS actually work. I have to do some studying. Francois LeFaucheur gave

>> me a reference that should serve as a tutorial.
>> 
>> 4) I don't think we came to a conclusion on how much memory/lag is 
>> desirable in the measurements. Accumulating over an interval introduces 
>> some lag. Exponential smoothing or moving averages introduce some lag. 
>> These are both means to reducing very short-term oscillations in system 
>> behaviour. I'm personally indifferent to the means used, but believe 
>> that some damping is desirable.

Whatever is decided, recommending exponential smoothing and then saying
that the parameter values are completely irrelevant doesn't make any sense
to me.  It would be better to say that parameters within some range seem to
work fine.

>> 4) The final point is, I think, the most important one for us to resolve

>> going forward. That is the question of when reports are issued. It could

>> be at the end of fixed intervals, or it could be when something 
>> significant has changed. The question is tied up with whether reliable 
>> transport is needed and also with the liveness question described in 2) 
>> above.

The closer CLE at an egress gets to the blocking threshold, the more
frequently you might want to send reports.


Regards,

// Steve