Subject: Re: [PCN] Natural decision point? draft-ietf-pcn-architecture-04

From: Bob Briscoe <[email-masked]>
Date: Thu, 17 Jul 2008 19:13:11 +0100

Phil,

[I've cc'd PCN again in case the list server or BT's mail relay catch 
up some time.]

The issue is this:
- if the ingress can override the decision of the egress, it's best 
to accept that the ingress is actually making the decision. The 
ingress will have to tell the egress what it has decided (to tear 
down path state and receiver state etc).

So, we should be wary of any implication that the egress is making 
the decision, otherwise a signalling design that says the egress 
signals its decision to the ingress will look valid. When in fact a 
second pass is needed.

This is an unavoidable consequence of spreading the admission control 
decision over a distributed system (PCN domain) rather than keeping 
it hop-by-hop like Intserv. The MBAC phase involves packets crossing 
the domain, then feedback coming back (in parallel to the signalling 
which continues to the destination and comes back). Then, when the 
e2e signalling returns to the PEP (ingress) if it has decided to 
block, its decision has to be signalled upstream and downstream to 
tear down the reservation.

There are many variants, with different optimistic/pessimistic 
models, but this is the basic one (IMHO).

Bob

At 14:10 17/07/2008, [email-masked] wrote:
>Bob
>
>[only replying to you, as only got your msg directly, not sure if you
>intended to only send to me, if pcn ML server is slow, or spam filter is
>blocking again]
>
>The text in architecture doc:
>Egress tells ingress the "admit /block" decision.
>Ingress goes with this decision.
>This is what the architecture doc currently says is 'most natural' (nb
>it doesn't say this is the only option!)
>
>Another option:
>Egress tells ingress the CLE.
>Ingress makes the decision. Now the ingress can decide what the
>CLE-threshold is (threshold for admit /block decision). Speculatively
>this might have an advantage where you want to prioritise the admission
>of various classes of users differently. (NB not talking about emergency
>etc calls, which will be admitted differently anyway.) I suspect in
>practive this is pretty marginal.
>
>Your scenario:
>Multi-domain. Ingress will get charged for traffic it admits (by
>downstream networks) so wants control over decision. This is still
>possible in either of the cases above - in either, the msg from the
>egress is treated as advice, eg even if the egress says "admit" the
>ingress might choose to block the new call.
>
>So would your issue be solved if I leave the current text & add some
>text to the effect that the ingress is the PEP so has ultimate control?
>And in the Appendix on possible future work, mention the multi-domain as
>a scenario where the ingress might want to over-ride what the egress
>suggests.
>
>Thanks
>Phil.
>
>Thanks for the spots of errors in text. S4 should have 'egress'
>
>
>{ -----Original Message-----
>{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
>{ Sent: 17 July 2008 12:54
>{ To: Eardley,PL,Philip,CXR9 R
>{ Subject: Natural decision point? draft-ietf-pcn-architecture-04
>{
>{ Phil,
>{
>{ Apologies for re-opening this issue (it was previously discussed in
>{ Mar '08 under the thread subject "Re: [PCN]
>draft-ietf-pcn-architecture-
>{ 03"
>{
>{ Firstly, There seems to be a contradiction between different parts of
>{ the text (quoted at the end).
>{
>{ But my main point concerns what 'natural' means in this context. So
>{ far the discussion has focussed on efficiency (where information
>{ gathers naturally?, which node has to be informed anyway?, etc).
>{
>{ However, "Keeping interconnect strongly in mind" [PCN charter], we
>{ should try to design protocols allowing for nodes doing what's in
>{ their operator's interests rather than what protocol messages from
>{ other operators ask them to do.
>{
>{ Seen this way, 'natural' means 'the node that has ultimate control
>{ anyway, whatever it is asked to do'. I.e. the ingress, which is the
>{ only node that can be a policy enforcement point (PEP) [RFC2753].
>{
>{ I think we should point out that the ingress will be the PEP if PCN
>{ becomes multi-domain later. Otherwise, if today's single-operator
>{ designs give the egress the final decision, the operator might have
>{ to change its design when it becomes multi-domain.
>{
>{
>{ >4. Deployment scenarios
>{ >{...}
>{ >    For admission control, the most natural place is the PCN-ingress-
>{ node.
>{
>{ >7.4. Other admission control functions
>{ >{...}
>{ >    o  The decision is made at the PCN-egress-node and the decision
>{ >       (admit or block) is signalled to the PCN-ingress-node.  This
>seems
>{ >       most natural.
>{
>{
>{
>{ Bob
>{
>{
>{
>{
>________________________________________________________________________
>__
>{ __
>{ Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
>{ Research
>{ B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
>{ 645196
>{

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

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