Subject: [ANCP] (no subject)

From: Sanjay Wadhwa <[email-masked]>
Date: Tue, 30 Mar 2010 19:40:52 -0700 (PDT)

We may be already covered by existing AN and NAS interaction defined in multicast extensions draft. Please see inline [SW].
-Sanjay

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of POSCIC
Kristian

Sent: Tuesday, March 30, 2010 7:46 PM

To: Francois Le Faucheur; [email-masked]

Subject: Re: [ANCP] "Admitted Bandwidth Reporting" multicast use case

Thanks Francois. 

This sums it up well. 

Some additional comments inline.

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

From: [email-masked]
[mailto:[email-masked]] On Behalf Of

Francois Le Faucheur

Sent: Tuesday, March 30, 2010 8:03 AM

To: [email-masked]

Subject: [ANCP] "Admitted Bandwidth Reporting"
multicast use case

Folks,

Following up on this item.

For memory, the draft minutes say:

> Kris Poscic: Question regarding whether a use case
of interest can be

supported with defined mechanisms

> use case is where AN does AC and does IGMP
suppression. All I want to

do is report bandwidth usage to NAS (eg so NAS adjusts
Qos). I saw

bandwidth allocation and query. but not quite the same
thing. Can this

use case be supported?

> Francois: can possibly be emulated with Bandwidth
Delegation

capability

> Chris: possibly but that would not be optimal

> Francois: I can agree probably agree with that.
Let's have a

discussion off-line.

We had a chat after the meeting and I also discussed this
with Tom and

then with Woj. There seems to be agreement that this is a
valid use case

worth addressing. We discussed an approach along the
lines of:

      * define a new
capability for "admitted bandwidth reporting"

(actual name is TBD)

      * if the
capability is negotiated, the AN MUST report to the NAS

the new value of the bandwidth currently
allocated/admitted by the AN on

a given port whenever that value changes (eg the AN just
admitted

another multicast channel in the White List, or the user
just jumped

from and SD channel to a HD channel,..).

      * the AN is
allowed to make some judgment calls about when to

report a changed admitted bandwidth. For example, when
the AN receives

the leave, the AN may want to wait a little before
reporting the changed

admitted bandwidth in case a join comes in (say because
user is simply

changing channel).

      * on receipt
of a new admitted bandwidth value, the NAS MAY

adjust its QoS mechanisms accordingly (note that, when
doing so, the NAS

needs to take into account the rest of the video traffic
that is not

admitted by the AN such as unicast VoD traffic or NAS
Initiated

Multicast traffic.

[Kris]  Little more
details for a possible use case: This feature will

be primarily used when the multicast is sent from the NAS
towards the AN

over a common multicast VLAN. Since the subscriber QoS
context in the

NAS actually does not see this mcast traffic, (mcast
traffic is sent

over a separate common VLAN), QoS b/w adjustment needs to
be made for

the subscriber. Most likely, every other traffic that is
flowing

directly over subscribers queues in the NAS will be automatically

included in the subscriber QoS. This would include any
unicast video

streams that are directly flowing over the subscriber
queues.

      * the call
flow to report a new admitted bandwidth value will

only involve a message in the direction AN-->NAS. No
response is needed

from NAS (except in case of errored message as per usual
ANCP

procedures).

      * we'll look
into whether the AN-->NAS message used for admitted

bandwidth reporting should be a new message type or
piggy-backed using

an existing message (eg PortUp, Generic Response,..)

[Kris] 

Do we report the diff in b/w usage or the total b/w used
value per

access port? I think that the 'total usage' should be
certainly a

priority. Possibly you can include a flag that would
indicate that a

diff in b/w usage is reported. 

      * one question
that needs more thoughts is combination of this

new capability with various other multicast capabilities
(eg what should

be done when we have both this new capability and Grey
List, since the

NAS is already aware of all admitted multicast grey
groups). I don't

think any of that should be a show stopper, but it has to
be carefully

walked through.

[Kris] This is my (maybe skewed :)) view on this: QoS B/W
adjustment in

the NAS can be done based on IGMPs received from the AN
or based on this

new model (proposed here) via ANCP. The latter would be
normally the

case in the absence of IGMP messages reaching the NAS
(there are valid

reasons to do this). Which option to chose is up to the
operator and it

is controlled in the NAS. 

[SW] The scenario above, where
NAS sends the channel on MC-VLAN, assumes NAS is doing bandwidth based AC. A
channel join on AN may trigger an AC request message to NAS, which should
trigger a CAC decision and QOS-adjust on NAS and a response back to AN (before
AN can perform replication). Do we need another bandwidth update message
from AN to NAS? In case AN sees a channel leave (and no new join for some time)
or a user switches from HD to SD, then AN may decide to notify NAS of released bandwidth.
I believe we are again covered by existing AC request message from AN to NAS
(described in multicast extensions draft). On the other hand if we are assuming
bandwidth delegation model and autonomous AC on AN, then we are already covered
via interaction related to bandwidth delegation between AN and NAS.

Thanks-Sanjay