Subject: [ANCP] Multicast Admission Control with AN Bandwidth Delegation

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 6 Aug 2008 10:39:22 +0200

Hello,
    In Dublin we presented some enhancements to multicast use cases and requirements (draft-maglione-ancp-mcast-01) in particular we proposed to extend the concept of multicast flows that share the same admission control rules (aka flow-group) with a mechanism that we called Admission Control with AN bandwidth delegation.
Proposal would be to incorporate in next revision of the ANCP framework I-D the outcomes of the list discussion on this draft, so I'd like to invite those of you that have questions or comments to send us feedbacks on the list.

Thanks.
Best Regards,
Roberta

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

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

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Fri, 22 Aug 2008 10:57:50 +0200

Hi Roberta,

Some comments on the multicast draft:

- Why is there a need to have a flag in the white/grey list to indicate
whether the AN should do admission control or not?  I would think that
in case of grey list, when the AN has sufficient delegated bandwidth,
and the AN has to necessary information to do the admission control,
then the AN does admission control.  Otherwise, the admission control is
part of the query to the NAS, which must contain an indication whether
or not the AN has already done admission control or not.  With the
current proposal, it might be that the AN does not perform admission
control, queries the NAS, but then the NAS has not sufficient BW and has
to go back to the AN to get some delegated BW back.  At the end, it does
not matter who is reserving the bandwidth, as long it gets reserved.
Both solutions have pros and cons, and I am not claiming that one is
better than the other, but I would think it is better to generalize the
proposal and remove the "Bandwidth Delegation" flag.  For white list,
there is also no need to have the flag: if the AN is provisioned with
the necessary information to do admission control, then the AN is doing
admission control, and otherwise there is no admission control.

- the text sometimes mentions "multicast bandwidth" and "unicast
bandwidth".  I would just make it "bandwidth", after all, it does not
matter whether the bandwidth is used for unicast or multicast on the
NAS.  At least, I assume that you are not proposing to split the
bandwidth in 2 parts: unicast and multicast BW?

- In the meeting in Dublin, it was said that this generalizes the
flow-group concept, but I do not see anymore where these flow-groups
are.  Is there still a grouping of flows?  Is there still a difference
between a user zapping from a channel to a channel is the same group,
and zapping from a channel to a channel belonging to a different group?

- 5th requirement (new text) in section 4.2: If the bandwidth delegation
flag is set, the AN first has to do admission control before querying
the NAS.  However, I would not specify the order and make it
implementation dependent.  The disadvantage of first allocating the BW
is that the BW is also reserved while the query is ongoing, and the
query might fail and then the BW has to be released again.  So doing
first admission control and then query can save messages, but it can
result in allocating BW while it was not really needed, and sessions
setup in parallel might fail because of no sufficient BW.  Other
implementations might be more intelligent: check BW, but does not
reserve, then query NAS, and after possitive answer from NAS, check BW
again and reserve it.

- 6th requirement (new text) in section 4.2: what is the difference
between a NAS querying the AN, and a NAS instructing to decrease the
delegated multicast bandwidth on a given port?

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maglione Roberta
Sent: woensdag 6 augustus 2008 10:39
To: [email-masked]
Subject: [ANCP] Multicast Admission Control with AN Bandwidth Delegation

Hello,
    In Dublin we presented some enhancements to multicast use cases and
requirements (draft-maglione-ancp-mcast-01) in particular we proposed to
extend the concept of multicast flows that share the same admission
control rules (aka flow-group) with a mechanism that we called Admission
Control with AN bandwidth delegation.
Proposal would be to incorporate in next revision of the ANCP framework
I-D the outcomes of the list discussion on this draft, so I'd like to
invite those of you that have questions or comments to send us feedbacks
on the list.

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received the
message in error, be informed that any use of the content hereof is
prohibited. Please return it immediately to the sender and delete the
message. Should you have any questions, please contact us by replying to
[email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 22 Aug 2008 12:56:24 +0200

Hi Stefaan,
    thanks for your comments, please see answers inline [RM].

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 10:58 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth Delegation

 Hi Roberta,

proposal and remove the "Bandwidth Delegation" flag.

[RM]  My vision is slightly different; first of all I'd like to clarify that the purpose of this draft is to enhance one CAC approach currently defined in the framework introducing Multicast Admission with AN  Bandwidth Delegation mechanism but still keep the Multicast Admission without AN Bandwidth Delegation approach currently defined in the framework.
Now in grey list I can have three types of flows:
        1. Multicast flows that require some Conditional Access checks to be    performed by the NAS and CAC can be performed on AN with AN Bandwidth   Delegation;
        2. Multicast flows that require both Conditional Access checks and CAC to be    performed by the NAS.
        3. Multicast flows that do not require Conditional Access but that require CAC          to be performed by the NAS.

Do you agree that we need a way to differentiate case 1 from 2/3? The way we thought is to use the "Bandwidth Delegation" flag but if you think there is a better way to achieve to same goal I am interested in discussing it. In addition when CAC is done by NAS (cases 2 and 3) NAS does not delegate any portion of bandwidth to the AN, thus the scenario that you described (NAS does not have enough BW and has to query the AN) does not apply to these cases.

 For white list,

[RM] I am no not really sure about that, how do you handle multicast flows that do not require CAC?

[RM] In this proposal bandwidth delegated to AN is just to admit multicast flow not unicast VOD requests.

[RM] The word " flow-group" does not appear in the current framework but the concept is there as " multicast flows that share the same rules" the proposal is to remove this concept for conditional access and to extend it with the "AN Bandwidth Delegation" mechanism in case of CAC.

[RM] I see pros and cons in both approaches, but if nobody else has additional opinions I'm fine with your suggestion to not specify the order and make it implementation dependent.

[RM] The difference is that with "instruct" the NAS can force the AN to release bandwidth, instead of just asking.

Regards,
Roberta

regards,
Stefaan

-----Original Message-----

Hello,

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 22 Aug 2008 13:33:09 +0200

Hello Roberta,

My understanding of the proposal of bandwidth delegation is to have a
mechanism that allows reducing the signaling load between the Access
Node and the NAS, and to enable fast acceptance or rejection of a
channel zap request in the Access Node. I'm supportive of that.

What puzzles me a bit is that in the case of grey lists, you seem to
decouple "conditional access" from "admission control", putting
"conditional access" in the NAS and "admission control" in the Access
Node. If I understand the grey list concept correctly, the Access Node
will ALWAYS signal to the NAS to know whether or not the request can be
approved. So whether or not admission control is performed on the Access
Node will have very limited effect on the overall message load. I would
argue that for grey lists it would be conceptually much simpler to
perform both "conditional access" as well as "admission control" in the
NAS.

So, in my view, bandwidth delegation makese sense, but I would apply it
only to white lists. 

The general behavior of bandwidth delegation as defined in the draft
looks fine to me.

Regards,
Sven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maglione Roberta
Sent: vrijdag 22 augustus 2008 12:56
To: DE CNODDER Stefaan; [email-masked]
Subject: Re: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

Hi Stefaan,

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 10:58 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

 Hi Roberta,

[RM]  My vision is slightly different; first of all I'd like to clarify
that the purpose of this draft is to enhance one CAC approach currently
defined in the framework introducing Multicast Admission with AN
Bandwidth Delegation mechanism but still keep the Multicast Admission
without AN Bandwidth Delegation approach currently defined in the
framework.
Now in grey list I can have three types of flows:
        1. Multicast flows that require some Conditional Access checks
to be    performed by the NAS and CAC can be performed on AN with AN
Bandwidth   Delegation;
        2. Multicast flows that require both Conditional Access checks
and CAC to be    performed by the NAS.
        3. Multicast flows that do not require Conditional Access but
that require CAC          to be performed by the NAS.

Do you agree that we need a way to differentiate case 1 from 2/3? The
way we thought is to use the "Bandwidth Delegation" flag but if you
think there is a better way to achieve to same goal I am interested in
discussing it. In addition when CAC is done by NAS (cases 2 and 3) NAS
does not delegate any portion of bandwidth to the AN, thus the scenario
that you described (NAS does not have enough BW and has to query the AN)
does not apply to these cases.

 For white list,

[RM] I am no not really sure about that, how do you handle multicast
flows that do not require CAC?

[RM] In this proposal bandwidth delegated to AN is just to admit
multicast flow not unicast VOD requests.

[RM] The word " flow-group" does not appear in the current framework but
the concept is there as " multicast flows that share the same rules" the
proposal is to remove this concept for conditional access and to extend
it with the "AN Bandwidth Delegation" mechanism in case of CAC.

[RM] I see pros and cons in both approaches, but if nobody else has
additional opinions I'm fine with your suggestion to not specify the
order and make it implementation dependent.

[RM] The difference is that with "instruct" the NAS can force the AN to
release bandwidth, instead of just asking.

Regards,
Roberta

regards,
Stefaan

-----Original Message-----

Hello,

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 22 Aug 2008 13:59:30 +0200

Hello Sven,
    I see your point, but if for one user, most of the channels are in white list  and few of them are in grey then it seems reasonable for bandwidth accounting reasons to have CAC handled on the AN, with AN bandwidth delegation mechanism, for all the multicast flows (both in white and grey list.)

Thanks,
Regards
Roberta

-----Original Message-----
From: OOGHE Sven [mailto:[email-masked]]
Sent: Friday, August 22, 2008 1:33 PM
To: Maglione Roberta; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth Delegation

Hello Roberta,

Regards,
Sven

-----Original Message-----

Hi Stefaan,

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 10:58 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

 Hi Roberta,

 For white list,

Regards,
Roberta

regards,
Stefaan

-----Original Message-----

Hello,

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 22 Aug 2008 14:11:46 +0200

Hi Sven,

On 22 Aug 2008, at 13:33, OOGHE Sven wrote:

> channel zap request in the Access Node.

Agreed.

> I'm supportive of that.
> Node.

This is correct where AN Bandwidth Delegation is used.
Where Bandwidth Delegation is used, both Conditional Access and  
Admission Control are done by NAS.

> If I understand the grey list concept correctly, the Access Node
> approved.

Right.

> So whether or not admission control is performed on the Access

I think this is very similar to the comment Tom made in Dublin.
It is correct that for the flow in the Grey list, there will be the  
same amount of signaling whether we do admission control on AN or NAS.
The benefit of doing admission control on the AN (when Bandwidth  
Delegation is activated) is that it is also done on AN for the white  
groups. So we have a single entity performing admission control for  
all multicast flows (whether they are white or grey). This should  
simplify operations of multicast bandwidth management (particularly  
since the expectation is that there would be typically many more  
white groups than Grey groups).

> The general behavior of bandwidth delegation as defined in the draft

Great.

Francois

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Fri, 22 Aug 2008 14:44:38 +0200

Hi Roberta,

Maybe I misunderstood something.  The "bandwidth delegation flag", is
this a flag per multicast stream or is it a general flag that applies to
all multicast streams?  I mean: is it possible to do CAC on NAS for some
flows and CAC on AN for some other flows, or is it always on one place?

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: vrijdag 22 augustus 2008 14:00
To: OOGHE Sven; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

Hello Sven,
    I see your point, but if for one user, most of the channels are in
white list  and few of them are in grey then it seems reasonable for
bandwidth accounting reasons to have CAC handled on the AN, with AN
bandwidth delegation mechanism, for all the multicast flows (both in
white and grey list.)

Thanks,
Regards
Roberta

-----Original Message-----
From: OOGHE Sven [mailto:[email-masked]]
Sent: Friday, August 22, 2008 1:33 PM
To: Maglione Roberta; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

Hello Roberta,

Regards,
Sven

-----Original Message-----

Hi Stefaan,

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 10:58 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

 Hi Roberta,

 For white list,

Regards,
Roberta

regards,
Stefaan

-----Original Message-----

Hello,

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 22 Aug 2008 14:58:05 +0200

Hi Francois and Roberta,

When the Access Node is using bandwidth delegation for many flows in a
white list and there are only a few flows in the grey list, I can see it
makes sense to have bandwidth delegation for all multicast flows. It's
probably useful to clarify that in the framework. At least I didn't
consider that scenario when reading the draft.

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: vrijdag 22 augustus 2008 14:12
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; Maglione Roberta; DE CNODDER Stefaan;
[email-masked]

Hi Sven,

Agreed.

> If I understand the grey list concept correctly, the Access Node will 
> ALWAYS signal to the NAS to know whether or not the request can be 
> approved.

Right.

> So whether or not admission control is performed on the Access Node 
> will have very limited effect on the overall message load. I would 
> perform both "conditional access" as well as "admission control" in 
> the NAS.

I think this is very similar to the comment Tom made in Dublin.
It is correct that for the flow in the Grey list, there will be the same
amount of signaling whether we do admission control on AN or NAS.
The benefit of doing admission control on the AN (when Bandwidth
Delegation is activated) is that it is also done on AN for the white
groups. So we have a single entity performing admission control for all
multicast flows (whether they are white or grey). This should simplify
operations of multicast bandwidth management (particularly since the
expectation is that there would be typically many more white groups than
Grey groups).

>
> So, in my view, bandwidth delegation makese sense, but I would apply 
> it only to white lists.
>

Great.

Francois

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Maglione Roberta
> - Why is there a need to have a flag in the white/grey list to 
> indicate whether the AN should do admission control or not?  I would 
> think that in case of grey list, when the AN has sufficient delegated 
> bandwidth, and the AN has to necessary information to do the admission

> control, then the AN does admission control.  Otherwise, the admission

> control is part of the query to the NAS, which must contain an 
> indication whether or not the AN has already done admission control or

> not.  With the current proposal, it might be that the AN does not 
> perform admission control, queries the NAS, but then the NAS has not 
> sufficient BW and has to go back to the AN to get some delegated BW 
> back.  At the end, it does not matter who is reserving the bandwidth, 
> as long it gets reserved.
> better than the other, but I would think it is better to generalize 
> the proposal and remove the "Bandwidth Delegation" flag.
>
> [RM]  My vision is slightly different; first of all I'd like to 
> clarify that the purpose of this draft is to enhance one CAC approach 
> currently defined in the framework introducing Multicast Admission 
> with AN Bandwidth Delegation mechanism but still keep the Multicast 
> Admission without AN Bandwidth Delegation approach currently defined 
> in the framework.

> does not delegate any portion of bandwidth to the AN, thus the 
> scenario that you described (NAS does not have enough BW and has to 
> query the AN) does not apply to these cases.
>
>  For white list,
> the necessary information to do admission control, then the AN is 
> doing admission control, and otherwise there is no admission control.
>

> [RM] The word " flow-group" does not appear in the current framework 
> but the concept is there as " multicast flows that share the same 
> rules" the proposal is to remove this concept for conditional access 
> and to extend it with the "AN Bandwidth Delegation" mechanism in case 
> of CAC.
>
>
> - 5th requirement (new text) in section 4.2: If the bandwidth 
> delegation flag is set, the AN first has to do admission control 
> before querying the NAS.  However, I would not specify the order and 
> make it implementation dependent.  The disadvantage of first 
> allocating the BW is that the BW is also reserved while the query is 
> ongoing, and the query might fail and then the BW has to be released 
> again.  So doing first admission control and then query can save 
> messages, but it can result in allocating BW while it was not really 
> needed, and sessions setup in parallel might fail because of no 
> sufficient BW.  Other implementations might be more intelligent: check

> BW, but does not reserve, then query NAS, and after possitive answer 
> from NAS, check BW again and reserve it.
>
> [RM] The difference is that with "instruct" the NAS can force the AN 
> to release bandwidth, instead of just asking.
>
> Regards,
> Roberta
>
> regards,
> Stefaan
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Maglione Roberta
>     In Dublin we presented some enhancements to multicast use cases 
> and requirements (draft-maglione-ancp-mcast-01) in particular we 
> proposed to extend the concept of multicast flows that share the same 
> admission control rules (aka flow-group) with a mechanism that we 
> called Admission Control with AN bandwidth delegation.
> Proposal would be to incorporate in next revision of the ANCP 
> framework I-D the outcomes of the list discussion on this draft, so 
> I'd like to invite those of you that have questions or comments to 
> send us feedbacks on the list.
>
> Thanks.
> Best Regards,
> Roberta
>
>
> above and may contain confidential information. If you have received 
> the message in error, be informed that any use of the content hereof 
> is prohibited. Please return it immediately to the sender and delete 
> the message. Should you have any questions, please contact us by 
> replying to [email-masked].
>
>         Thank you
>
>                                         www.telecomitalia.it
>
> above and may contain confidential information. If you have received 
> the message in error, be informed that any use of the content hereof 
> is prohibited. Please return it immediately to the sender and delete 
> the message. Should you have any questions, please contact us by 
> replying to [email-masked].
>
>         Thank you
>
>                                         www.telecomitalia.it
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 22 Aug 2008 15:16:47 +0200

On 22 Aug 2008, at 14:58, OOGHE Sven wrote:

> probably useful to clarify that in the framework.

I agree.
Francois

> At least I didn't
> same
> all

---

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 22 Aug 2008 15:28:09 +0200

> The "bandwidth delegation flag", is
> all multicast streams?

The flag is not for all multicast streams, it is per group of flows, according to the mask used in the ACL.

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 2:45 PM
To: Maglione Roberta; OOGHE Sven; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth Delegation

Hi Roberta,

regards,
Stefaan

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]]
Sent: vrijdag 22 augustus 2008 14:00
To: OOGHE Sven; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

Hello Sven,

Thanks,
Regards
Roberta

-----Original Message-----
From: OOGHE Sven [mailto:[email-masked]]
Sent: Friday, August 22, 2008 1:33 PM
To: Maglione Roberta; DE CNODDER Stefaan; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

Hello Roberta,

Regards,
Sven

-----Original Message-----

Hi Stefaan,

Regards,
Roberta

-----Original Message-----
From: DE CNODDER Stefaan [mailto:[email-masked]]
Sent: Friday, August 22, 2008 10:58 AM
To: Maglione Roberta; [email-masked]
Subject: RE: [ANCP] Multicast Admission Control with AN Bandwidth
Delegation

 Hi Roberta,

 For white list,

Regards,
Roberta

regards,
Stefaan

-----Original Message-----

Hello,

Thanks.
Best Regards,
Roberta

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it