[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Multicast BW Admission Control
Stefann,
I am a bit confused about the Cc'ed and your prior mail, because i
think they contradict each other. Aka:
a) In the first mail i thought to understood that you wanted a
usage case of internet video for which no admission control is done,
and because there may be other video traffic for which admission
control IS done, the idea is to have the non-CACed video use simply
"best-effort" DSCP marking.
Correct ?
So, then i conclude that
I) this "intern video" traffic would somehow get DSCP best-effort
marked. We can probably keep the whee and why of that marking
outside of the scope of ANCP, even if it happens (orthogonal to ANCP)
in the NAS. Correct ?
II) To make sure that this best-effort traffic would not cause
congestion/packet-loss of actually admission controlled video,
the AN would need to support well enough some form of DSCP-class
based queuing, by which some part of the bandwidth is prioritized
for DSCP-video-class traffic, which is the class for which ANCP
would also do admission control, eg: via grey-list.
The best-effort-DSCP video traffic might use this bandwidth,
but only when no DSCP-video-class traffic needs it.
Correct ? Which of these AN side queuing behavior do you think
should be documented by ANCP ?
III) The way that ANCP would cope withsuch trafic that wouldnot be
subject to it's admission control would as far as i understand
it best be to just whitelist it. So the "internet-video" with
DSCP-best-effort would be part of the whitelist. In addition,
if we feel that such "internet-video" traffic might have
"unpredictable" addresses, then one might want to have matching
against whitelist be done by default, but if the adress of
a channel matches tthe greylist, then that greylist should
trace precedence.
Correct ?
b) Now, in your second mail, you indicate that the NAS should provide
to the AN per-flow bandwidth information, such that the AN can do
add up on it's own bandwidth of flows to make admission control decisions.
This seems to be a diffeent approach to what i thought was expressed
by the first mail.
Can you calrify ??
Thanks
Toerless
P.S.: just returning from longer vacations, so i may be more confused than
usual ;-))
On Tue, Jan 15, 2008 at 02:31:18PM +0100, Stefaan DE CNODDER wrote:
>
> Hi Sven, Francois,
>
> see below...
>
> Francois Le Faucheur IMAP wrote:
>
> >Hi Sven,
> >
> >Thanks for the clarification.
> >The approach you describe below seems fine to me.
> >I think the key point it brings is to clarify that it it can make sense
> >to perform CAC on some flows and not on others (and the non- CACed flows
> >will not break the CACed flows).
> >
>
> How do I have interprete this CAC? From the email discussion I
> understand that the AN will not do any CAC on joins not matching with
> any white/grey/black list, assuming that this is an Internet multicast
> flow marked as best effort somewhere by an edge router. Then I
> understand that when the join matches a grey list, then all checks
> including the bandwidth CAC checks are perfomed in the NAS, and when it
> matches a white list, the NAS is not queried and hence the AN is doing
> all the checks. This is then done without querying the NAS, but still
> under control by the NAS, i.e., the NAS configures the AN via ANCP such
> that the AN can do all the checks. The latter means that the NAS must
> provision the AN with the necessary information to let the AN to make
> the decisions: in a white list the NAS configures the multicast groups
> (with masks), sources, bandwidth, and possibly other information (e.g.,
> related to accounting).
>
> If this is what we all understand, then it looks good.
>
> regards,
> Stefaan
>
>
> >One small point. When you say "the NAS must make sure that the
> >multicast content is marked as best-effort", I wasn't sure if you
> >implied that the NAS would remark the flow. While that may be an
> >option, a more common case if probably that the flow got marked best-
> >effort somewhere upstream (eg when flow enters the SP network). I think
> >it would be worth clarifying.
> >
> >Also, I would suggest that the text uses "Internet/Unkown" channels
> >just as an example of where this sort of approach may be used, but make
> >it clear it is a generic capability (e.g. the best-effort approach can
> >be used on known flows also).
> >
> >Cheers
> >
> >Francois
> >
> >On 8 Jan 2008, at 16:02, OOGHE Sven wrote:
> >
> >>Hi,
> >>
> >>In the Vancouver meeting minutes there is mention about multicast
> >>bandwidth admission control, and what to do with "best effort" streams.
> >>Apparently there is some confusion on the concept. This email is the
> >>clarify my view on this.
> >>
> >>As already described in section 3.4.2, there is a need - next to policy
> >>based admission control - to perform CAC for the video content being
> >>streamed across the access network. The different options to do so are
> >>already defined in the framework document.
> >>
> >>Now, the point I wanted to bring up is that in general, the Access Node
> >>and NAS cannot be aware of all possible multicast groups. It is likely
> >>that there may be multicast channels offered across the Internet. For
> >>these streams, performing bandwidth admission control may be
> >>challenging.
> >>
> >>To solve this, these requests should by default be accepted, but the
> >>network should handle the traffic as best effort. This can be done by
> >>first of all adding a "catch-all statement" in the Access Node white
> >>list or grey list. In case the Access Node queries the NAS, the NAS on
> >>his turn will have to accept the request. That way, the unknown streams
> >>are not blocked by default. Next, the NAS must make sure that the
> >>multicast content coming from the Internet is marked as best effort
> >>traffic. This way, whenever congestion occurs somewhere in the
> >>access/aggregation network, this stream will be kicked out before the
> >>access provider's own premium content.
> >>
> >>If people agree with this, I suggest to add the above discussion to the
> >>framework document.
> >>
> >>Regards,
> >>Sven
> >>
> >>
> >>_______________________________________________
> >>ANCP mailing list
> >>ANCP at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/ancp
> >
> >
> >
> >
> >_______________________________________________
> >ANCP mailing list
> >ANCP at ietf.org
> >https://www1.ietf.org/mailman/listinfo/ancp
>
>
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
--
---
Toerless Eckert, eckert at cisco.com
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp