Subject: [PCN] Key results from PCN

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Nov 2009 08:29:29 +0900

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.

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.

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Nov 2009 08:33:39 +0900

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.

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:
> 
> 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.
> 
> 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.
> 
> Tom Taylor
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
> 
>

---

From: Steven Blake <[email-masked]>
Date: Thu, 12 Nov 2009 05:45:41 -0500

On Wed, 11 Nov 2009 08:33:39 +0900, Tom Taylor <[email-masked]>
wrote:

> 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.

>> 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.

>> transport is needed and also with the liveness question described in 2) 

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

Regards,

// Steve