Subject: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Jun 2014 09:01:11 -0400

Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I noticed 
an inconsistency in treatment between three different cases where the AN 
is assigned a value of multicast bandwidth that is lower than the AN has 
already committed to a given subscriber. The question to the Working 
Group is whether:
   (a) no change is needed; or
   (b) local policy should determine whether established connections 
should be taken down to meet bandwidth limits set by the NAS in all 
cases; or
   (c) established connections should never be taken down until 
terminated by the subscriber (no provision for local policy in any case).

The context in each instance is that the NAS has sent a multicast 
bandwidth allocation to the AN. If the AN does not conform to that 
allocation, the NAS does not have a correct view of the amount of 
bandwidth available for admission control (e.g., of unicast services) at 
the NAS itself. That should probably be fixed independently of the 
question stated above.  And, of course, the over-commitment at the AN 
means that less bandwidth is available for services admitted at the NAS.

Here are the three cases in question:

Case 1: bandwidth assigned by Port Management message
=====================================================

Receiver behaviour is described in Section 4.2.2. Note the provision for 
local policy in the quoted text:

   "If the Port Management message contains a Bandwidth-Allocation TLV,
    the AN adopts this as the current value of its total multicast
    bandwidth limit for the target port.  If the AN has already committed
    multicast bandwidth exceeding the amount given in the Bandwidth-
    Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
    in order to bring bandwidth down to within the new limit, unless such
    action is required by local policy.  However, the AN MUST NOT admit
    new multicast streams that are subject to admission control until it
    can do so within the limit specified by the Bandwidth-Allocation
    TLV."

Case 2: bandwidth assigned by Bandwidth Transfer message
========================================================

AN behaviour as receiver is described in Section 4.6.2.2. There is no 
provision for local policy:

   "If as the result of the procedures just described the AN determines
    that it has over-committed multicast bandwidth, it MUST NOT terminate
    any currently-active programs, but MUST NOT honour any more "join"
    requests until it is possible to do so within the limit set by its
    current value of delegated bandwidth."

Case 3: bandwidth assigned by Delegated Bandwidth Query Response message
========================================================================

AN behaviour as receiver is described in Section 4.8.2.2. There is no 
provision for local policy:

   "... If the AN has
    currently committed more than this amount to active programs, it MUST
    NOT cease replicating the flows concerned, but MUST NOT honour any
    more Join requests until possible to do so within the new limit."

Tom Taylor

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 4 Jun 2014 14:18:59 +0000

Tom and all,

In the considered scenario where:
	* the AN receives a new Bandwidth-Allocation TLV
	* the AN has already committed more multicast bandwidth
I would suggest that the AN first attempts to increase the delegated bandwidth by sending to the NAS a Bandwidth Reallocation Request message. This is the behavior already specified (1) for the AN in the situation where the delegated bandwidth has not been modified but there is a new multicast join that would result in committing more bandwidth than delegated.
Would you agree? 

If this attempt does not result in obtaining sufficient bandwidth to avoid any over-commitment, I would recommend retaining the behavior currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy.)  and align the text of teh sections that are inconsistent with that.

Francois

(1) section 6.2.5.2. :
“
When the AN receives a join request, it
   checks whether it has sufficient remaining uncommitted multicast
   bandwidth on the access line to accommodate the new multicast flow.
   If not, it MAY send a request to the NAS for an increased allocation
   of delegated bandwidth using the Bandwidth Reallocation Request
   message.  The NAS MUST return a Bandwidth Transfer message indicating
   whether it has granted the request and, if so, the new amount of
   delegated bandwidth.
"

On 4 Jun 2014, at 15:01, Tom Taylor <[email-masked]> wrote:

> Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I noticed an inconsistency in treatment between three different cases where the AN is assigned a value of multicast bandwidth that is lower than the AN has already committed to a given subscriber. The question to the Working Group is whether:
>  (b) local policy should determine whether established connections should be taken down to meet bandwidth limits set by the NAS in all cases; or
>  (c) established connections should never be taken down until terminated by the subscriber (no provision for local policy in any case).
> 
> The context in each instance is that the NAS has sent a multicast bandwidth allocation to the AN. If the AN does not conform to that allocation, the NAS does not have a correct view of the amount of bandwidth available for admission control (e.g., of unicast services) at the NAS itself. That should probably be fixed independently of the question stated above.  And, of course, the over-commitment at the AN means that less bandwidth is available for services admitted at the NAS.
> 
> Receiver behaviour is described in Section 4.2.2. Note the provision for local policy in the quoted text:
> 
> AN behaviour as receiver is described in Section 4.6.2.2. There is no provision for local policy:
> 
> AN behaviour as receiver is described in Section 4.8.2.2. There is no provision for local policy:
> 
>  "... If the AN has
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Wed, 18 Jun 2014 12:34:16 +0000

Tom, Francois and All,
Sorry for my late reply, comments inline.

>I would suggest that the AN first attempts to increase the delegated bandwidth by sending to the NAS a >Bandwidth Reallocation >Request message. This is the behavior already specified (1) for the AN in the situation where the delegated bandwidth has not been >modified but there is a new multicast join that would result in committing more bandwidth than delegated.
>Would you agree?

I agree with this approach.

>If this attempt does not result in obtaining sufficient bandwidth to avoid any over-commitment, I would recommend retaining the behavior >currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the >new limit, unless such action is required by local policy.)  and align the text of teh sections that are inconsistent with that.

In opinion it would make sense to maintain the behavior currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the >new limit, unless such action is required by local policy), therefore I would support the proposal of aligning all the sections with this behavior.

Thanks
Best Regards
Roberta

---------- Forwarded message ----------
From: Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>>
Date: Wed, Jun 4, 2014 at 7:18 AM
Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16
To: Tom Taylor <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Tom and all,

Francois

(1) section 6.2.5.2. :
“

On 4 Jun 2014, at 15:01, Tom Taylor <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 18 Jun 2014 22:09:39 -0400

Time I brought this to a close. I will modify the text as suggested and 
let RFC publication proceed.

Tom Taylor

On 18/06/2014 8:34 AM, Roberta Maglione (robmgl) wrote:
>>I would suggest that the AN first attempts to increase the delegated bandwidth by sending to the NAS a >Bandwidth Reallocation >Request message. This is the behavior already specified (1) for the AN in the  situation where the delegated bandwidth has not been >modified but
> there is a new multicast join that would result in committing more
> bandwidth than delegated.
>>Would you agree?
>
>>If this attempt does not result in obtaining sufficient bandwidth to avoid any over-commitment, I would recommend retaining the behavior >currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any  multicast streams in order to bring bandwidth down to within the >new
> limit, unless such action is required by local policy.)  and align the
> text of teh sections that are inconsistent with that.
>
> In opinion it would make sense to maintain the behavior currently
> specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast
> streams in order to bring bandwidth down to within the >new limit,
> unless such action is required by local policy), therefore I would
> support the proposal of aligning all the sections with this behavior.
>
> Thanks
>
> Best Regards
>
> Roberta
>
> From: *Francois Le Faucheur (flefauch)* <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>
>
> Tom and all,
>
> I would suggest that the AN first attempts to increase the delegated
> bandwidth by sending to the NAS a Bandwidth Reallocation Request
> message. This is the behavior already specified (1) for the AN in the
> situation where the delegated bandwidth has not been modified but there
> is a new multicast join that would result in committing more bandwidth
> than delegated.
> Would you agree?
>
> If this attempt does not result in obtaining sufficient bandwidth to
> avoid any over-commitment, I would recommend retaining the behavior
> currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any
> multicast streams in order to bring bandwidth down to within the new
> limit, unless such action is required by local policy.)  and align the
> text of teh sections that are inconsistent with that.
>
>
> Francois
>
>
> (1) section 6.2.5.2. :
> “
> On 4 Jun 2014, at 15:01, Tom Taylor <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>  > Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I
> noticed an inconsistency in treatment between three different cases
> where the AN is assigned a value of multicast bandwidth that is lower
> than the AN has already committed to a given subscriber. The question to
> the Working Group is whether:
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Jun 2014 15:21:54 -0400

I have made the following changes to the RFC Editor's version of the 
document. Basically they propagate the Section 4.2.2 text to Sections 
4.6.2.2 and 4.8.2.2, with an extra reference to procedures in 6.2.5.2.

In Section 4.6.2.2:

OLD

    If, as the result of the procedures just described, the AN determines
    that it has over-committed multicast bandwidth, it MUST NOT terminate
    any currently active programs but MUST NOT honor any more join
    requests until it is possible to do so within the limit set by its
    current value of delegated bandwidth.

NEW

    If the AN has already committed multicast bandwidth exceeding the
    amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT
    discontinue any multicast streams in order to bring bandwidth down to
    within the new limit, unless such action is required by local policy.
    However, the AN MUST NOT admit new multicast streams that are subject
    to admission control until it can do so within the limit specified by
    the Bandwidth-Allocation TLV.  As specified in Section 6.2.5.2, the
    AN MAY attempt to correct the situation by sending a request to the
    NAS for an increased allocation of delegated bandwidth using the
    Bandwidth Reallocation Request message.

In Section 4.8.2.2:

OLD

    If the AN has
    currently committed more than this amount to active programs, it MUST
    NOT cease replicating the flows concerned but MUST NOT honor any more
    join requests until possible to do so within the new limit.

NEW

    If the AN has
    already committed multicast bandwidth exceeding the amount given in
    the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any
    multicast streams in order to bring bandwidth down to within the new
    limit, unless such action is required by local policy.  However, the
    AN MUST NOT admit new multicast streams that are subject to admission
    control until it can do so within the limit specified by the
    Bandwidth-Allocation TLV.  As specified in Section 6.2.5.2, the AN
    MAY attempt to correct the situation by sending a request to the NAS
    for an increased allocation of delegated bandwidth using the
    Bandwidth Reallocation Request message.

Tom Taylor