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

From: <[email-masked]>
Date: Thu, 7 Aug 2008 08:43:43 +0100

You've more or less convinced me. Basically I propose in S7.4 to
replace:

   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.

By

   o  The decision is made at the PCN-egress-node and the decision
      (admit or block) is signalled to the PCN-ingress-node.  
   o  The decision is recommended by the PCN-egress-node (admit or
block) but the decision is definitively made by the PCN-ingress-node.
The rationale is that the PCN-egress-node naturally has the necessary
information about PCN-marking in the ingress-egress-aggregate, but the
PCN-ingress-node is the policy enforcement point which polices incoming
traffic to ensure it's part of an admitted PCN-flow. 

{ -----Original Message-----
{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Sent: 17 July 2008 19:13
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: PCN IETF list
{ Subject: RE: Natural decision point? draft-ietf-pcn-architecture-04
{ 
{ 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