Subject: [PCN] Corridor discussions on edge behaviour

From: Tom Taylor <[email-masked]>
Date: Tue, 24 Mar 2009 18:03:54 -0700

We discussed the edge behaviour drafts for a couple of hours today and will 
continue tomorrow. I explained my view of PCN as a statistical filtering process 
designed to operate the network at as efficiently as possible without incurring 
significant risk of overload when traffic exhibits its normal level of 
variation. That set a context for further discussion, but needs follow-up.

We actually have two issues which should be discussed independently:

1. When does the egress node report?
(a) Periodically.
(b) When the CLE crosses a threshold (upward or downward).
(c) When triggered by a RESV message or the equivalent.

2. What does the egress node report?
(a) Octet counts per second of unmarked, threshold-marked, and excess-marked 
traffic.
(b) The smoothed CLE.
(c) The admission state (admit, block).

One other bit of news: Giorgios is joining the edge behaviour draft editorial 
team, which also includesx Anna, me, Michael, and Fortune.

Tom Taylor

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 02:15:58 -0000

to add to this:
 
so far we only discussed admission. we (continue to) agree that the ingress is the right place to make the admission decision. becuase the policy information about flow admissin will be at the ingress (that's the point that most naturally knows about users attaching at this ingress), and such policy info might form part of the decision about whether to admit the flow (along with PCN info about marking level)
 
there is also the question about empty IEAs. my view is that we shouldnt worry too much about this, there seem heuristics that look ok, although of course it's nice if they are naturally solved. 
 
a particular issue that tom raised was if you dont already have a signalling msg between the ingress and egress, ie you dont have an rsvp msg to piggyback the measurement data on. this could be the case if the legacy system is doing some kind of call counting at the ingress & the operator wants to improve the accuracy of this with PCN.
 
as regards the optins below 
1 a) has the drawback that there are potentially a lot of IEAs (say 10k with 100 gateways) so peridocially reporting every 10ms or 100ms is quite an overhead.
2a) seems a lot of info to report which is not in general of any interest for admission (however, it possibly has the advantage that if termination is needed then you already have (or maybe have) the rate info without having to ask for it. 

________________________________

From: [email-masked] on behalf of Tom Taylor
Sent: Wed 25/03/2009 01:03
To: [email-masked]
Subject: [PCN] Corridor discussions on edge behaviour

Tom Taylor
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 02:34:29 -0000

the other thing we agreed is that an edge behaviour draft would try to cover a fairly small subset of all the possible edge behaviours. different edge behaviour then needs a different draft. in fact, different drafts may make it easier to write the signalling draft [get a better feel of requiremetns ]

Tom Taylor

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Mar 2009 11:39:16 +0100

Hi all,

> so far we only discussed admission. we (continue to) agree that the ingress is the right place to make the admission decision. becuase the policy information about flow admissin will be at the ingr…
Taking the AC decision means accept or block new flows. This can be done 
on the base of CLE values or admit/block states so that this is not the 
question and options 1a-c of Tom's previous email are still valid.

> there is also the question about empty IEAs. my view is that we shouldnt worry too much about this, there seem heuristics that look ok, although of course it's nice if they are naturally solved. 
I do not know these heuristics, at least they are not investigated. I 
find it safe to go for some CLE-based AC but to keep the door open for 
some probe-based AC for IEAs that are likely to carry only little 
traffic. I don't say that this has priority, but the signalling should 
be designed in a way that it hides the details of the AC state 
calculation. Therefore, I am in favor to report only AC states from the 
egress to the ingress.

> a particular issue that tom raised was if you dont already have a signalling msg between the ingress and egress, ie you dont have an rsvp msg to piggyback the measurement data on. this could be the…
If RSVP is already in place, it could be reused for PCN purposes. If it 
is not used, yet, what's the problem with using it for signalling 
accross the PCN domain? I know it's a heavy-weight protocol, but it's 
done. As long as states are installed only in ingress and egress, PCN 
still achieves it objective to keep the core without states. It's not 
that I am in favor of this solution, but I thing it's an option.

> 1 a) has the drawback that there are potentially a lot of IEAs (say 10k with 100 gateways) so peridocially reporting every 10ms or 100ms is quite an overhead.
I would prefer a different view with a similar result: as long as we 
have a large number of flows per IEA, the relative overhead of periodic 
signalling is low. Otherwise, it is large.

> 2a) seems a lot of info to report which is not in general of any interest for admission (however, it possibly has the advantage that if termination is needed then you already have (or maybe have) t…
 From my perspective the quantitiy of information is not the critical 
issue as long as the data fit in a single small signalling message. From 
that point of view signalling rates or smoothed CLE or both are fine. 
However, I find that the signalling must be generic and we should avoid 
that PCN can do only CLE-based AC forever unless new signalling is 
developed. Probing for IEAs seems important to me, especially when many 
IEAs are likely to be empty. I do not say that this has priority, but we 
should keep this door open and not just as a hack with signaling CLE=0 or 1.

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

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 18:27:22 -0000

From: Michael Menth [mailto:[email-masked]]
Sent: Wed 25/03/2009 10:39
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Corridor discussions on edge behaviour

Hi all,

[phil] this is ok providing we agree that the actual value of teh CLE never forms part of the decision whether to admit a flow. ie the only thing that matters is the CLE is "high" or "low" (alternative: depending on eg the user, we might admit depending on the exact CLE value)

[phil] good point, we just have to say what the signalling reqt is, so we can say "use something like rsvp, with object carrying this info"

[phil] ok. (altho not sure how small the signalling msg is with signalling rates)