Subject: Re: [ANCP] (no subject)

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 1 Apr 2010 16:02:39 +0200

Hi Sanjay,

On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote:
> 
> [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).

If admission control is to be performed by NAS (ie Grey list multicast flow), then I agree we are already covered by existing multicast procedures because the NAS is always fully aware of currently admitted multicast traffic on a given port.

> 
>  On the other hand if we are assuming bandwidth delegation model and autonomous AC on AN,

That is indeed the case of interest, here.

> then we are already covered via interaction related to bandwidth delegation between AN and NAS.

That was my initial reaction too. Indeed, I think it is possible to stretch existing bandwidth delegation procedures to achieve this. However this would result in sub-optimal handling of the new use case.

Example call-Flow based on re-using existing bandwidth delegation procedures:
===========================================================
AN <---PORT_MNGT (Bw allocation=0Mb/s) --NAS
...
(join from subscriber for 2Mb/s multicast flow)
AN ---Bandwidth Realloc Request (2Mb/s)--> NAS
                                                                   (NAS allocates 2Mb/s)
AN <--------Bandwidth Transfer (2Mb/s)-------- NAS
(AN starts replicating)
...
(leave + join from subscriber for 4Mb/s multicast flow)
AN ---Bandwidth Realloc Request (4Mb/s)--> NAS
                                                                   (NAS allocates 4Mb/s total)
AN <--------Bandwidth Transfer (4Mb/s)-------- NAS
(AN starts replicating)

Example call-Flow based on new "admitted bandwidth reporting" procedures:
=========================================================
AN <---PORT_MNGT (Bw allocation=4Mb/s) --NAS
...
(join from subscriber for 2Mb/s multicast flow)
(AN does admission control and starts replicating)
AN ------Admitted Bandwidth Report(2Mb/s)---> NAS
(leave + join from subscriber for 4Mb/s multicast flow)
(AN does admission control and starts replicating)
AN ------Admitted Bandwidth Report(4Mb/s)----> NAS

So, the sub-optimalities of reusing existing bandwidth delegation procedures include:
	*a* use of two messages instead of one, for every bandwidth change
	*b* extra delay on AN (ie need to wait for ANCP round-trip instead of immediately replicate)
	*c* unnecessary "bandwidth check" for "reallocation" on NAS

I'd say these sub-optimalities justify a new procedures, but I'm willing to be convinced otherwise.
I suppose one could argue that in the majority of join/leave/join, the bandwidth does not change (ie zapping among channels of same bandwidth), so the sub-optimality *a* is only incurred in less common case (leaveSD, joinHD).

Thoughts everyone?

Francois

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: "POSCIC Kristian" <[email-masked]>
Date: Thu, 1 Apr 2010 15:26:17 -0500

Hi everyone,

*b* would be a big worry for me in this case. I was thinking about
keeping the NAS free of AC. 

Also, at the beginning I would give the AN (via Port Mgmt) some
delegated b/w which would be fairly high, according to my policy rules
as an operator. Then the AN would report the b/w usage (if there is any
b/w change) to the NAS.

Then I would have the NAS ask the AN for b/w reallocation. In other
words, the NAS ask the AN to set the b/w admission threshold (delegated
b/w) to some (possibly lower) value. If the AN has the b/w available,
it'll do so and send the ACK back. If not, then it'll NACK it.

It may make strange that the NAS is asking for the b/w reallocation when
it is not doing any AC. But this is OK, since there can be some other
external policy server that is also managing b/w and this external
policy server may ask the NAS to see if the b/w is available (not
necessarily through ANCP but through some other interfaces). The NAS in
turn converts this request into ANCP and sends it to the AN since the AN
has the knowledge of the multicast usage and AC.

Does anyone know off-hand if it is possible to aggregate b/w
reallocation requests for multiple Target TLVs in the same ANCP message?
I can check myself, I was just wondering if someone knows off-hand.

Thanks,
kris 

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Thursday, April 01, 2010 7:03 AM
To: Sanjay Wadhwa
Cc: Francois Le Faucheur; POSCIC Kristian; [email-masked]
Subject: Re: 

Hi Sanjay,

On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote:
> 
> [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).

If admission control is to be performed by NAS (ie Grey list multicast
flow), then I agree we are already covered by existing multicast
procedures because the NAS is always fully aware of currently admitted
multicast traffic on a given port.

> then we are already covered via interaction related to bandwidth
delegation between AN and NAS.

That was my initial reaction too. Indeed, I think it is possible to
stretch existing bandwidth delegation procedures to achieve this.
However this would result in sub-optimal handling of the new use case.

Example call-Flow based on re-using existing bandwidth delegation
procedures:
                                                                   (NAS
allocates 2Mb/s)
                                                                   (NAS
allocates 4Mb/s total)

Example call-Flow based on new "admitted bandwidth reporting"
procedures:

So, the sub-optimalities of reusing existing bandwidth delegation
procedures include:
	*a* use of two messages instead of one, for every bandwidth
change
	*b* extra delay on AN (ie need to wait for ANCP round-trip
instead of immediately replicate)
	*c* unnecessary "bandwidth check" for "reallocation" on NAS

I'd say these sub-optimalities justify a new procedures, but I'm willing
to be convinced otherwise.
I suppose one could argue that in the majority of join/leave/join, the
bandwidth does not change (ie zapping among channels of same bandwidth),
so the sub-optimality *a* is only incurred in less common case (leaveSD,
joinHD).

Thoughts everyone?

Francois

---

From: Tom Taylor <[email-masked]>
Date: Thu, 01 Apr 2010 22:13:56 -0400

Can't do that until Target with multiple instances is defined. Even then, the 
question becomes one of whether you would give the same allocation to every port.

POSCIC Kristian wrote:
...

---

From: "POSCIC Kristian" <[email-masked]>
Date: Thu, 1 Apr 2010 21:30:16 -0500

Tom - a different allocation to each Target TLV. For example in PON
deployments. Multiple subscribers will reside on the same PON. So you
would need to do the AC for a subscriber (one Target TLV) and then
possibly per PON on which the subscriber resides (another TLV) and then
possibly a third reallocation request for the uplink towards the NAS (
another Target TLV). All come down as one request to the OLT which is
managing AC (all three entities are visible there - PON, subscriber(s)
on the PON and the uplink towards the NAS). 

I guess for this we can send three separate reallocation request
messages that are contained in a single ANCP packet. A more optimal way
would be to allow single reallocation request messages with (target, bw)
pairs - but I don't even want to go there :).  
Thanks,
Kris 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Thursday, April 01, 2010 7:14 PM
To: POSCIC Kristian
Cc: Francois Le Faucheur; Sanjay Wadhwa; [email-masked]
Subject: Re: [ANCP] (no subject)

Can't do that until Target with multiple instances is defined. Even
then, the 
question becomes one of whether you would give the same allocation to
every port.

POSCIC Kristian wrote:
...

---

From: Sanjay Wadhwa <[email-masked]>
Date: Fri, 2 Apr 2010 21:35:36 -0700 (PDT)

Hi Francois, Kris
  What is needed depends on at least two key variables:
  1. How dynamic do you want the per-subscriber bandwidth management across different traffic types to be. This includes managed VOD, multicast and best-effort traffic. 
  2. Where do you want the unified bandwidth admission control across multicast and managed VOD to happen (AN or NAS). 
We can consider most optimal interactions based on the model chosen. However, the protocol needs to allow all variations.

Now, specific to your examples, you have assumed in bandwidth delegation model that no minimal initial bandwidth is delegated to AN, which doesn't need to be the case.
In your second example you are allocating in initial amount of bandwidth delegated to AN (perhaps due to dynamic updates of allocated b/w you assume it is ok). However, based on reported bandwidth utilization from AN, the NAS could use the available bandwidth for unicast traffic (including best-effort). Next time around when AN gets a request for higher bandwidth  multicast channel, it can't assume bandwidth is available, and should update NAS before replicating. I don't see specific advantage/optimality with the second example.

Based on Kris's questions I am extrapolating the model in question is the following:

  1. AN manages assigned video bandwidth and does unified bandwidth admission control (AC) against it.
  2. AN terminates per-subscriber multicast and replicates based on an admission control decision.
  3. When VOD request needs to be admitted, policy server through NAS queries available bandwidth on the AN. This is a reverse AC request (from NAS to AN for unicast video). If bandwidth is available, VOD flow is admitted by NAS. AN always has the latest view of available bandwidth. Making AC request/response bidirectional and specifying bandwidth value in AC request can accomodate this interaction.
  4. AN notifies NAS of bandwidth allocations for multicast, so NAS can adjust bandwidth for unicast (e.g. best-effort) traffic accordingly. However, if AN needs to inform NAS to adjust bandwidth for unicast (best-effort) traffic lower (due to say a SD->HD multicast leave/join sequence), it does need to send a request to NAS and ideally wait for a response before replicating. This round-trip is not avoidable if one wants the most      dynamic/optimal bandwidth usage, where unicast best-effort traffic could utilize unused available video bandwidth and get throttled down when multicast needs the bandwidth (ofcourse this is dependent on how operator wants to manage subscriber's bandwdith). For this interaction either a new "bandwidth reporitng" message or a sub-type of an existing message can be used.

-Sanjay

ps. The model where unified AC happens on NAS has its own benefits (e.g. simplicity), so not necessarily advocating the above model with AN based AC, but we need to accommodate both.

--- On Thu, 4/1/10, Francois Le Faucheur <[email-masked]> wrote:

From: Francois Le Faucheur <[email-masked]>
Subject: Re:
To: "Sanjay Wadhwa" <[email-masked]>
Cc: "Francois Le Faucheur" <[email-masked]>, [email-masked], [email-masked]
Date: Thursday, April 1, 2010, 10:02 AM

Hi Sanjay,

Thoughts everyone?

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

 Think before you print.

---

From: "POSCIC Kristian" <[email-masked]>
Date: Sun, 4 Apr 2010 01:59:37 -0500

Hi Sanjay – 

In the model that I was thinking, the steps 3 and 4 are little bit different:

Video b/w that can be allocated in the AN is shared between the mcast and VoD. 

3) Policy server makes the VOD decision. NAS is transparent to this. It’s acting juts as an intermediary between the policy server and the AN.

4) If the b/w asked by the policy server is available in the AN, the AN will send an ACK which will be conveyed to the policy server through the NAS. The policy server will allow the VOD flow and update is resource reservation table. Nothing else is needed. The unicast VoD flow will be automatically accounted for in the QoS in the NAS as it is flowing through the subscriber queues.

B/w usage reporting from the AN to the NAS has to do only with the multicast AC.

One another note, the ANCP draft Target TLV definitions are mostly focused on DSLAM environments. But in the PON environment, if we need to manage b/w per PON, uplink and the subscriber, we’ll need 3 Target TLVs. Maybe this will be defined in the draft that you are working on (GPON)?

Thanks,

kris 

From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: Friday, April 02, 2010 9:36 PM
To: Francois Le Faucheur
Cc: Francois Le Faucheur; POSCIC Kristian; [email-masked]
Subject: Re:

Hi Francois, Kris

-Sanjay

Hi Sanjay,

Thoughts everyone?

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

Think before you print.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Sun, 4 Apr 2010 20:06:12 -0700 (PDT)

Hi Kris
  Please see inline [SW].

Thanks
-Sanjay

--- On Sun, 4/4/10, POSCIC Kristian <[email-masked]> wrote:

From: POSCIC Kristian <[email-masked]>
Subject: RE:
To: "Sanjay Wadhwa" <[email-masked]>, "Francois Le Faucheur" <[email-masked]>
Cc: "Francois Le Faucheur" <[email-masked]>, [email-masked]
Date: Sunday, April 4, 2010, 2:59 AM

Hi Sanjay –  

In the model that I was thinking, the steps 3 and 4 are little
bit different: 

Video b/w that can be allocated in the AN is shared between the
mcast and VoD.  

3) Policy server makes the VOD decision. NAS is transparent to
this. It’s acting juts as an intermediary between the policy server and the AN.
[SW] I implied the same in #3 below. Policy server queries AN via NAS (through ANCP between NAS and AN). The decision to admit the VOD is being made on the AN
in this model, as it is managing this shared b/w pool between VOD and multicast, and is conveying back
the response via ANCP to NAS (which could then be conveyed via north-bound interface from NAS to
policy-server). Please let me know if this is different than what you are thinking.

4) If the b/w asked by the policy server is available in the AN,
the AN will send an ACK which will be conveyed to the policy server through the
NAS. The policy server will allow the VOD flow and update is resource
reservation table. Nothing else is needed. The unicast VoD flow will be
automatically accounted for in the QoS in the NAS as it is flowing through the
subscriber queues. 

B/w usage reporting from the AN to the NAS has to do only with
the multicast AC. 

[SW] In #4 below I am only talking about multicast and not VOD (please note the channel change scenario mentioned
in there). AN may want to optionally notify NAS of multicast, such that NAS can adjust unicast b/w lower due to multicast being sent on MVLAN (as
multicast bypasses normal QOS hierarchy for the subscriber).
The point I tried making is that AN will need to hold off on
replication till it gets an ACK back from NAS when notifying it of
QOS-adjust. Original response from Francois seemed to imply no
round-trip was needed before AN starts replication (which I don't believe is
the case).

One another note, the ANCP draft Target TLV definitions are mostly
focused on DSLAM environments. But in the PON environment, if we need to manage
b/w per PON, uplink and the subscriber, we’ll need 3 Target TLVs. Maybe this will
be defined in the draft that you are working on (GPON)? 

[SW] The target TLV is extensible. PON specific types as you mention need to be defined (to also include PON and uplink). The PON draft covers the models and information exchanged at a  high level. The specific TLVs in the messages need to go in the protocol draft. I believe for the model discussed here, you will also need Admission Control message (NAS to AN) extended for VOD (e.g to carry requested bandwidth). 

Thanks
-Sanjay

From: Sanjay Wadhwa
[mailto:[email-masked]] 

To: Francois Le Faucheur

Subject: Re: 

 
  
  Hi Francois, Kris

    1. How dynamic do you want the per-subscriber bandwidth management
  across different traffic types to be. This includes managed VOD, multicast
  and best-effort traffic. 

    2. Where do you want the unified bandwidth admission control across
  multicast and managed VOD to happen (AN or NAS). 

  We can consider most optimal interactions based on the model chosen. However,
  the protocol needs to allow all variations.

  Now, specific to your examples, you have assumed in bandwidth delegation
  model that no minimal initial bandwidth is delegated to AN, which doesn't
  need to be the case.

  In your second example you are allocating in initial amount of bandwidth
  delegated to AN (perhaps due to dynamic updates of allocated b/w you assume
  it is ok). However, based on reported bandwidth utilization from AN, the NAS
  could use the available bandwidth for unicast traffic (including
  best-effort). Next time around when AN gets a request for higher
  bandwidth  multicast channel, it can't assume bandwidth is available,
  and should update NAS before replicating. I don't see specific
  advantage/optimality with the second example.

  Based on Kris's questions I am extrapolating the model in question is the
  following:

    1. AN manages assigned video bandwidth and does unified bandwidth
  admission control (AC) against it.

    2. AN terminates per-subscriber multicast and replicates based on an
  admission control decision.

    3. When VOD request needs to be admitted, policy server through NAS
  queries available bandwidth on the AN. This is a reverse AC request (from NAS
  to AN for unicast video). If bandwidth is available, VOD flow is admitted by
  NAS. AN always has the latest view of available bandwidth. Making AC
  request/response bidirectional and specifying bandwidth value in AC request
  can accomodate this interaction.

    4. AN notifies NAS of bandwidth allocations for multicast, so NAS can
  adjust bandwidth for unicast (e.g. best-effort) traffic accordingly. However,
  if AN needs to inform NAS to adjust bandwidth for unicast (best-effort)
  traffic lower (due to say a SD->HD multicast leave/join sequence), it does
  need to send a request to NAS and ideally wait for a response before
  replicating. This round-trip is not avoidable if one wants the most     
  dynamic/optimal bandwidth usage, where unicast best-effort traffic could
  utilize unused available video bandwidth and get throttled down when
  multicast needs the bandwidth (ofcourse this is dependent on how operator
  wants to manage subscriber's bandwdith). For this interaction either a new
  "bandwidth reporitng" message or a sub-type of an existing message
  can be used.

  -Sanjay

  ps. The model where unified AC happens on NAS has its own benefits (e.g.
  simplicity), so not necessarily advocating the above model with AN based AC,
  but we need to accommodate both.

  --- On Thu, 4/1/10, Francois Le Faucheur <[email-masked]>
  wrote: 

  Subject: Re:

  Cc: "Francois Le Faucheur" <[email-masked]>,
  [email-masked], [email-masked]

  Hi Sanjay,

  On 31 Mar 2010, at 04:40, Sanjay Wadhwa wrote:

  > [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).

  If admission control is to be performed by NAS (ie Grey list multicast flow),
  then I agree we are already covered by existing multicast procedures because
  the NAS is always fully aware of currently admitted multicast traffic on a
  given port.

  > then we are already covered via interaction related to bandwidth
  delegation between AN and NAS.

  That was my initial reaction too. Indeed, I think it is possible to stretch
  existing bandwidth delegation procedures to achieve this. However this would
  result in sub-optimal handling of the new use case.

  ...

                       
                     
     (NAS allocates 2Mb/s)

  (AN starts replicating)

  ...

                       

  (AN starts replicating)

  ...

  

  So, the sub-optimalities of reusing existing bandwidth delegation procedures
  include:

      *a* use of two messages instead of one, for every
  bandwidth change

      *c* unnecessary "bandwidth check" for
  "reallocation" on NAS

  I'd say these sub-optimalities justify a new procedures, but I'm willing to
  be convinced otherwise.

  I suppose one could argue that in the majority of join/leave/join, the
  bandwidth does not change (ie zapping among channels of same bandwidth), so
  the sub-optimality *a* is only incurred in less common case (leaveSD,
  joinHD).

  Thoughts everyone?

  Francois

   

  Francois Le Faucheur

  Distinguished Engineer

  Corporate Development

  [email-masked]

  Phone: +33 49 723 2619

  

  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.

---

From: "POSCIC Kristian" <[email-masked]>
Date: Sun, 4 Apr 2010 23:45:06 -0500

Hi Sanyaj – please see inline.

Thanks,

Kris

From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: Sunday, April 04, 2010 8:06 PM
To: Francois Le Faucheur; POSCIC Kristian
Cc: Francois Le Faucheur; [email-masked]
Subject: RE:

Hi Kris
  Please see inline [SW].

Thanks
-Sanjay

Hi Sanjay – 

[SW] I implied the same in #3 below. Policy server queries AN via NAS (through ANCP between NAS and AN). The decision to admit the VOD is being made on the AN in this model, as it is managing this shared b/w pool between VOD and multicast, and is conveying back the response via ANCP to NAS (which could then be conveyed via north-bound interface from NAS to policy-server). Please let me know if this is different than what you are thinking.

[Kris] Yes, we are on the same page. I was confused by this statement in your original post: If bandwidth is available, VOD flow is admitted by NAS. 

[SW] In #4 below I am only talking about multicast and not VOD (please note the channel change scenario mentioned in there). AN may want to optionally notify NAS of multicast, such that NAS can adjust unicast b/w lower due to multicast being sent on MVLAN (as multicast bypasses normal QOS hierarchy for the subscriber). The point I tried making is that AN will need to hold off on replication till it gets an ACK back from NAS when notifying it of QOS-adjust. Original response from Francois seemed to imply no round-trip was needed before AN starts replication (which I don't believe is the case).

[Kris]Ok,  I think this is where the disconnect is. This new message that is being proposed to update the b/w usage (not the allocation) is sent from the AN to the NAS. This will be done only if there is a difference in channel b/w usage. Based on this message, the NAS will adjust its b/w for unicast. For example, a new join comes for a  5mbps channel. If this channel is admitted by the AN, the AN will send a new b/w usage report (total new sub usage = old + 5mbps). The NAS will now know that the subscriber is getting more video b/w (mcast channel bypassing subscriber’s QoS hierarchy). So the NS will lower its aggregate rate for the subscriber for the -5Mbps. Within this new aggregate (minus 5mbps) , video still has a higher priority than HSI so the only affected traffic will be HSI.  For this I also (as Francois) do not believe that any feedback is necessary back from the NAS.

Thanks

-Sanjay

Hi Francois, Kris

-Sanjay

Hi Sanjay,

Thoughts everyone?

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

Think before you print.

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

---

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

> [Kris]Ok,  I think this is where the disconnect is. This new message that is being proposed to update the b/w usage (not the allocation) is sent from the AN to the NAS. This will be done only if th…

[FLF] Let's drill down on that one.
In the case where the AN starts replication without waiting for any "QoS-Adjust-response" from the NAS, there is a small window of time (from time where replication starts on An to time when QoS-adjust is effected on NAS following the "bandwidth-update") during which there may be an excessive amount of traffic sent towards a given customer port (ie high "new" multicast load + high "old" unicast load). However, I have been assuming this is not an issue because:
	 (i) the AN can still prioritize video (unicast & multicast) over HSI, and
	(ii) it is only transient.
This is why I feel OK with the "no round-trip" approach.
Is it safe to assume the AN can always prioritize video over HSI during the transient "congestion" period?

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

 Think before you print.

---

From: "POSCIC Kristian" <[email-masked]>
Date: Tue, 6 Apr 2010 09:01:54 -0500

Hi Francois – 

I agree with the assessment

The transient will affect only HSI. During the transient, the NAS will keep sending more HSI for the subscriber into the access network for the case where this was an existing multicast channel in the NAS. The AN  usually has its own QoS with proper prioritization and will discard this excess HSI, which is Best-Effort anyway.

In the PON where the PON is shared and QoS implemented per aggregate link (instead of subscriber), the HSI will be also discarded although across all subscribers. This 5mbps (from the previous example) will be cut from the HSI on the PON port uniformly.

But again, assuming that this is only transient condition, traffic is best-effort anyway, congestion is short lived (otherwise we have other issues), this should be OK. The benefit is a faster channel change, greatly reduced messaging between the NAS and the AN. The downside is that best-effort traffic is cut for the amount of b/w that mcast channel is taking during this short transient period. And this will happen only if there is congestion, if not, things are fine.

For the case where channel in not present at the NAS (new channel join), things will be similar. The NAS will treat traffic appropriately via QoS.

It us up to operator to design QoS behavior, but I think it is safe to assume that video (mcast + VOD) can be always prioritized over HSI. I know that vendors that can do this. If there is any case where this cannot be done, maybe this approach is not the best and they will have to resort to some of the other approaches defined in the draft. 

Thanks,

kris

From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2010 1:40 AM
To: POSCIC Kristian
Cc: Francois Le Faucheur; Sanjay Wadhwa; [email-masked]
Subject: Re: RE: 

Francois

 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked] <mailto:[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 <http://www.cisco.com> 

 Think before you print.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Tue, 6 Apr 2010 10:19:48 -0700 (PDT)

Hi Francois
   As long as we assume AN can do classification and downstream queuing and scheduling to not impact video, we are ok. However, uplink
bandwidth
on the AN, and bandwidth in aggregation network (if
present) is also a consideration, especially if the channel is not
already being received by AN. Any FCC in play at the same time will
also cause unicast bursts, but hopefully this is prioritized/queued right all through. Dropping downstream of NAS is likely to be subscriber agnostic,
which was original concern. However, since this is not sustained (although quite possible across several subscribers at the same time),
it is reasonable to not require an ACK before replication to reduce latency and messages. If we don't want to make assumptions about AN capabilities, we could consider making it a configurable option on AN which is signaled in the updates.

Based on network
dimensioning and the provisioned QOS model on NAS, there may be no
congestion at all, in which case nothing to worry.

-Sanjay

--- On Tue, 4/6/10, Francois Le Faucheur <[email-masked]> wrote:

From: Francois Le Faucheur <[email-masked]>
Subject: Re: RE:
To: "POSCIC Kristian" <[email-masked]>
Cc: "Francois Le Faucheur" <[email-masked]>, "Sanjay Wadhwa" <[email-masked]>, [email-masked]
Date: Tuesday, April 6, 2010, 4:39 AM

 [SW] In #4 below I am only talking about multicast and not VOD (please note the channel change scenario mentioned in there). AN may want to optionally notify NAS of multicast, such that NAS can adjust unicast b/w lower due to multicast being sent on MVLAN (as multicast bypasses normal QOS hierarchy for the subscriber). The point I tried making is that AN will need to hold off on replication till it gets an ACK back from NAS when notifying it of QOS-adjust. Original response from Francois seemed to imply no round-trip was needed before AN starts replication (which I don't believe is the case).[Kris]Ok,  I think this is where the disconnect is. This new message that is being proposed to update the b/w usage (not the allocation) is sent from the AN to the NAS. This will be done only if there is a difference in channel b/w usage. Based on this message, the NAS will adjust its b/w for unicast. For example, a new join comes for a  5mbps channel. If this
 channel is admitted by the AN, the AN will send a new b/w usage report (total new sub usage = old + 5mbps). The NAS will now know that the subscriber is getting more video b/w (mcast channel bypassing subscriber’s QoS hierarchy). So the NS will lower its aggregate rate for the subscriber for the -5Mbps. Within this new aggregate (minus 5mbps) , video still has a higher priority than HSI so the only affected traffic will be HSI.  For this I also (as Francois) do not believe that any feedback is necessary back from the NAS.
[FLF] Let's drill down on that one.In the case where the AN starts replication without waiting for any "QoS-Adjust-response" from the NAS, there is a small window of time (from time where replication starts on An to time when QoS-adjust is effected on NAS following the "bandwidth-update") during which there may be an excessive amount of traffic sent towards a given customer port (ie high "new" multicast load + high "old" unicast load). However, I have been assuming this is not an issue because:	 (i) the AN can still prioritize video (unicast & multicast) over HSI, and	(ii) it is only transient.This is why I feel OK with the "no round-trip" approach.Is it safe to assume the AN can always prioritize video over HSI during the transient "congestion" period?
Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

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

  Think before you print.