[Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #111

RFC 2597 states 

"This memo does not specify that any particular relationship hold between AF
PHB groups and other implemented PHB groups; it requires only that whatever
relationship is chosen be documented. Implementations MAY allow either or
both of these relationships to be configurable. It is expected that this
level of configuration flexibility will prove valuable to many network
administrators."

In other words, it's up to the admin, as long as the rules are clearly
stated. I am a fan of absolute priority (of CIR traffic) between classes,
relative priority within classes. For example:

CIR = PIR for EF traffic. Network "reserves" the EF CIR as committed, and
refuses to admit anything above CIR=PIR.

CIR is committed and reserved for AF4 traffic. Excess traffic between CIR
and PIR receives higher priority than excess traffic for lower priority
groups, even within AF class (e.g. AF1).

CIR for AF1 is oversubscribed based on statistical analysis of historic
network traffic. AF1 CIR may be dropped under extreme conditions.

BE gets whatever is left.

I have no strong opinion about how to treat excess AF traffic vs. BE. My
inclination is to give BE CIR higher priority than any "excess" traffic, but
to treat all "excess" traffic in absolute priority by class. To summarize:

Absolute priority order:
EF
AF4 CIR
AF1 CIR
BE CIR
AF4 excess (medium drop priority)
AF1 excess (mdp)
BE excess (mdp)
Etc.

This way, if a customer wants to increase their service quality, it is clear
what they do: they bump up a class if they want more deterministic
assurance, or they increase PIR if they want a more subtle (and probably
less expensive) improvement.

I would be very interested in hearing from a "real" network administrator
about how s/he sets priorities and policies.

J

> From: diffserv-interest-request@ietf.org
> Reply-To: diffserv-interest@ietf.org
> Date: Fri, 07 Nov 2003 12:00:02 -0500
> To: diffserv-interest@ietf.org
> Subject: Diffserv-interest digest, Vol 1 #111 - 1 msg
> 
> Send Diffserv-interest mailing list submissions to
> diffserv-interest@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> or, via email, send a message with subject or body 'help' to
> diffserv-interest-request@ietf.org
> 
> You can reach the person managing the list at
> diffserv-interest-admin@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Diffserv-interest digest..."
> 
> 
> Today's Topics:
> 
>  1. QoS in diffserv network (Feng Y)
> 
> --__--__--
> 
> Message: 1
> From: "Feng Y" <feng6@uwindsor.ca>
> To: diffserv-interest@ietf.org
> Date: Thu, 06 Nov 2003 11:29:01 -0500
> Subject: [Diffserv-interest] QoS in diffserv network
> 
> 
>>> =20
>>> It is up to the carrier to monitor congestion
> periodically to prevent
>>> lowest-priority traffic from being too congested. EF
> should ALWAYS get
>>> through on-time, and AF CIR should always get through,
> if somewhat delayed
>>> and jittery. The cases when this is NOT true should be
> rare and bizarre
>>> (earthquakes, major network outages, etc.) unless the
> carrier is not doing
>>> their job... Which is simply to make sure they engineer
> total network
>>> bandwidth above the level of peak CIR.
>> 
>> Exactly. Each traffic class (i.e. each queue) needs to be
> provisioned for
>> the expected load with appropriate over- or
> under-provisioning. The new
>> thing is that you can over-provision for some traffic and
> under-provision
>> for other traffic. (New to IP, that is. It's hardly a new
> concept.)
>> 
> 
> Can we always assume that a higher service class provides
> the same or a better service than any lower service class
> in AF? Can the following scenario happen in Diffserv
> network?
> The gold service was allocated x percent of a link=92s
> bandwidth and silver service was allocated x/2 percent of
> the link=92s bandwidth, but the traffic intensity of gold
> packets was 10 times higher than that of silver packets.
> 
> Should the ISP assure that there are not so many gold
> packets in service?=20
> 
> Thanks
> 
> Yang=20
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Diffserv-interest mailing list
> Diffserv-interest@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv-interest
> 
> 
> End of Diffserv-interest Digest

_______________________________________________
Diffserv-interest mailing list
Diffserv-interest@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv-interest

[Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #111 - 1 msg