[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Multicast BW Admission Control
Hi Toerless,
The confusion probably comes from the fact that 2 discussions are mixed:
Initial question: what should the AN do when an IGMP join does not match
any white/black/grey list? There the assumption is that such a join is
for an unknown Internet video stream, which is best effort and also
marked as best effort (using 802.1p bits is more appropriate than DSCP
since the AN is a switch). Hence, the AN can accept this join without
doing any further CAC.
Note: since in any list you can configure a "catch-all" entry, we have a
"configurable default" but also this needs a default.
This discussion raised a second question on the need for CAC and how CAC
should be done. There may also be a number of premium content channels
that are offered by the service provider. The premium content channels
will not be offered as best effort, and will require CAC to be
performed. DSL lines are of limited bandwidth and CAC on such links is
useful. Today, such CAC in performed by ANs and used by many service
providers because it is an easy and simple solution.
These premium channels may also be part of the white list, in particular
the popular channels, and channels for which the authorization
information is not changing frequently. The white list contains the
multicast streams for which the AN can decide autonomously, and
therefore, the AN also needs the information to do this. Therefore,
just listing the multicast streams in the white list is just not
sufficient and the AN needs the bandwidth in the white list as well.
I feel there is a need to describe this into more detail in the
framework document to make sure we understand all the same. Also, the
explanation above also does not provide the whole story on CAC, and all
details should be in the framework. Is this also your understanding
because then we have to work on describing all the details.
regards,
Stefaan
Toerless Eckert wrote:
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
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp