From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Wed May 05 2004 - 00:59:11 GMT-3
At 9:53 PM -0400 5/4/04, Kenneth Wygand wrote:
>Howard,
>
>Thank you for your complete and very comprehensive analysis. My
>question, however, was theoretical in application and is not
>intended for a production environment. Technically the bits in the
>TOS field can be set to anything provided they support the overall
>implementation of the network policy in effect.
Correct. I did want to emphasize the point that network/internetwork
control protocols MUST have absolute priority, and, in production
environments, it's often wise to have either out-of-band or
prioritized telnet for remote consoles.
>The real basis of my question was if a question says "set a specific
>priority or DSCP for a specific type or subset of traffic and use
>"best effort" for everything else", do I retag all other traffic
>with all zero's for the TOS byte or do I trust them the values of
>the TOS byte for this traffic. What does "best effort" actually
>imply, all zero's or unchanged?
>
It's a little more subtle than that. Under the differentiated
service model, there are two main kinds of traffic: guaranteed
service (GS) and best effort (BE). Controlled load is a special case
and not worth considering in a general discussion.
BE is a somewhat misleading term when one looks at the Cisco RSVP
implementation of GS. Since you can reserve only 75 percent of an
interface bandwidth for GS, leaving 25 percent for BE, the
highest-priority BE really has a guarantee that it will get 25
percent of the total bandwidth.
If this were a question in the CCIE lab, you really have already
identified the key issue, which, I believe, is a legitimate question
to ask a proctor: "I need to determine what amount of policy
enforcement you want. Do I force differentiated service priority, or
should I trust the data originator? Further, should I follow best
practice and not reprioritize routing protocols and related network
control mechanisms?"
[If the proctor answered "no" to the last question, I might indeed
walk away muttering that he needed a thorough thrashing with a large
clue stick. Nevertheles...]
Given that you'll use a router as data source in the lab, AFAIK, it
will not set non-routine priority on anything other than VoIP.
Is that answer closer to your question? :-)
>
>-----Original Message-----
>From: nobody@groupstudy.com on behalf of Howard C. Berkowitz
>Sent: Tue 5/4/2004 5:48 PM
>To: ccielab@groupstudy.com
>Cc:
>Subject: Re: Best Effort Definition
>
>
>
> At 4:31 PM -0400 5/4/04, Kenneth Wygand wrote:
> >Hello Group,
> >
> >
> >
> >I think I know the answer to this one but I just want to get some more
> >opinions...
> >
> >
> >
> >If I am performing QoS (whether it be CoS, IP Precedence, ToS Bits, or
> >DSCP), supposed I would like to "mark all traffic going from
>router A to
> >router B as IP Precedence 6 while other traffic receiving
>"best effort"
> >service"... obviously through some kind of classification, marking and
> >queuing I would make sure all traffic from router A to
>router B receives
> >the type of service it requires.
>
> Why are you using priority 6? Priority 5 is intended as the highest
> to be used for application traffic.
>
> >However, what about all other traffic?
>
> Priorities 6 and 7 are reserved for time-criticall routing protocols,
> network management, etc. Never interfere with the priorities for
> these services, or you may create a situation where the routers lock
> up and you cannot get control. Along the same lines, you might want
> to create fine-grained rules to have telnet from a control console at
> priority 5.
>
> >When requesting that other traffic gets "best effort",
>should one leave
> >the QoS markings as-is, or actually remark them back to all 0's?
>
> Leave them as-is. I can't say with certainty that any other
> applications will set priority, but they rarely do without a good
> reason. If, for example, you use TFTP to reload NVRAM during
> production hours, I might give it priority 4.
>
> To put it in perspective, the original military purposes of the
> precedences were having the highest for network and internetwork
> control. The next was used, among other things, for Emergency Command
> Precedence, which is an order to launch a nuclear weapon. Considering
> that the sender of such a message may become part of a mushroom cloud
> at any time, that message HAS to take priority -- but even then, the
> network/internetwork control had even higher precedence, because if
> they weren't working, the network might not be there to carry the
> Emergency Action Message at ECP precedence.
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:04 GMT-3