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

From: Fortune HUANG <[email-masked]>
Date: Tue, 06 Apr 2010 15:38:19 +0800

Hi Kris, 
Hi Francois,

I think this use case makes sense and I support working on it in the mc
extension draft.

"	* 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)."  
--[Fortune: Maybe there should be some configuratble policy about when to
report the b/w, e.g. report immediately after the AC action, report after a
configurable time after the AC action, or report periodically, etc.]

"[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. " 
-- [Fortune: I think we should report the 'total usage' in order to avoid
confusions when resending the report.
In case the  'total usage'  is reported, the 'diff in b/w usage' would not
be needed.]

Best regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
POSCIC Kristian
Sent: Wednesday, March 31, 2010 7:46 AM
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. 
The AN asking for the NAS for the resource admission via the grey lists
should be orthogonal to b/w adjustment. 
Thanks again Francois.     

High level feedback is welcome on this before we start working out details.

Oh, last thing, does anyone know whether this use case is already discussed
in the Framework document?

Thanks

Francois

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 6 Apr 2010 10:43:45 +0200

> I think this use case makes sense and I support working on it in the mc

good.

> configurable time after the AC action, or report periodically, etc.]

While we can give some example of reasonable things to do (such as what you mention above), the details can probably be left to implementers since that does not affect interoperability. Do you agree?

> In case the  'total usage'  is reported, the 'diff in b/w usage' would not

I agree.

Francois

> in the Framework document?

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Fortune HUANG <[email-masked]>
Date: Wed, 07 Apr 2010 08:17:10 +0800

While we can give some example of reasonable things to do (such as what you
mention above), the details can probably be left to implementers since that
does not affect interoperability. Do you agree?
     [Fortune: Yes, I agree. We can just give some examples for guidance but
not for restriction.] 

Best regards,
Fortune