Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt

"John H. Shuler" <> Mon, 03 November 2003 18:28 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA13589 for <>; Mon, 3 Nov 2003 13:28:24 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AGjQp-0005nk-0e for; Mon, 03 Nov 2003 13:28:04 -0500
Received: (from exim@localhost) by (8.12.8/8.12.8/Submit) id hA3IS2cb022270 for; Mon, 3 Nov 2003 13:28:02 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AGjQn-0005lv-UU; Mon, 03 Nov 2003 13:28:01 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1AGjQA-0005lJ-UB for; Mon, 03 Nov 2003 13:27:23 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA13549 for <>; Mon, 3 Nov 2003 13:27:12 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AGjQ8-000274-00 for; Mon, 03 Nov 2003 13:27:20 -0500
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1AGjQ7-000271-00 for; Mon, 03 Nov 2003 13:27:19 -0500
Received: from (smtpin08-en2 []) by (Xserve/MantshX 2.0) with ESMTP id hA3IRET7024973; Mon, 3 Nov 2003 10:27:14 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (Xserve/smtpin08/MantshX 3.0) with ESMTP id hA3IQuZq010865; Mon, 3 Nov 2003 10:27:14 -0800 (PST)
User-Agent: Microsoft-Entourage/
Date: Mon, 03 Nov 2003 10:26:55 -0800
Subject: Re: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01 .txt
From: "John H. Shuler" <>
To: Dimitry Haskin <>, Jozef Babiarz <>, Brian E Carpenter <>
CC: <>
Message-ID: <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3150700016_14584362"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Differentiated services general discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


You are right that AF4 could be removed, given very careful engineering and
management and a few other assumptions. I leave it in because it actually
simplifies operations to have it.

There is a balance that must be struck between the cost of equipment,
facilities, and management. It is technically possible to throw massive
amounts of any of these at the problem and get a workable result. However,
the cost-benefit curves for each is non-linear. More classes is better, up
to a point, because it reduces the bandwidth and engineering requirement.
Then it is worse, mostly because it increases the equipment and management
cost. You seem to feel that 4 is the magic number. Even though I subscribe
to the KISS principle, I feel more comfortable with 5. Most of the really
smart people I know are comfortable in the range of 3-7 total classes. The
point is, it is not 16, or 32...

One consideration is that having more classes seems to work better in
bandwidth-constrained environments such as are found in the access network,
whereas you can get away with murder in the NxOC192 backbone. All for very
well-known queuing theory reasons.


From: Dimitry Haskin <>
Date: Mon, 03 Nov 2003 11:12:12 -0500
To: "'John H. Shuler'" <>om>, Jozef Babiarz
<>om>, Brian E Carpenter <>
Subject: RE: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01

Since the jitter level is bound by latency, your AF4 service class seems to
be incongruous and can be safely removed from the list. What would remain
appears to be a reasonable grouping of services.
> -----Original Message-----
> From: John H. Shuler  []
> Sent: Sunday, November 02, 2003 5:30  PM
> To: Jozef Babiarz; Brian E Carpenter
> Cc:
> Subject: Re: [Diffserv-interest] Re:  draft-baker-diffserv-basic-classes-01
> .txt
> Here is my take on the examples you  gave below:
> Total of 5 service classes, ever, for any  service:
> Control Class: Highest absolute priority. Never used for anything  but
> control. Period.
> EF for TDM-like services such as IP telephony,  circuit em, and possibly
> (depending on your attitude) interactive video  services. Engineered such that
> it is never oversubscribed under even the most  extreme conditions. Yields low
> latency and jitter.
> AF4 for  latency-sensitive (but not particularly jitter-sensitive) traffic
> such as  unidirectional audio-video streaming, TV broadcast, etc. Jitter is
> buffered by  end systems. Also available for people who want to pay through
> the nose for  transactional data service (banks may). Very conservatively
> engineered w.r.t.  CIR... Should never block.
> AF1 for guaranteed CIR services with some  (but not much) delay sensitivity,
> such as SNA, VPN, etc. This class - even CIR  - will typically be
> oversubscribed, based on statistical analysis of network  traffic.
> BE for everything else - Best Effort internet services, etc.   No distinction
> between "standard" and "low priority". This is both. BE  is subject to
> complete blocking under extreme conditions, but these conditions  should
> almost never occur with proper network engineering. In fact, the apps  that
> use it should not even know when they are blocked even for several  seconds,
> since they are totally elastic. Service providers will price and
> differentiate based on their performance on this class as well as the others.
> If someone is intense about blocking, they can pay to up their service to AF1
> or even AF4.
> Why do you need more? All services can be addressed using  these basic
> classes, plus policy-based tweaks on policers and shapers and  queuing systems
> (WFQ or CBQ). If a customer wants a better quality than is  "typical" of a
> particular service, they can pay to bump up a class (except to  the control
> class). CIR on EF and AF4 will not be oversubscribed. The payback  from
> excessive attention to detail in management is negligible at best. Any
> problems that occur will be due to failure to properly engineer the network
> bandwidth or access policies.
> Please explain to me why I am  wrong.
> j
>  From: Jozef Babiarz <>
> Date:  Sun, 02 Nov 2003 16:52:18 -0500
> To: Brian E Carpenter  <>om>, "John H. Shuler"
> <>
> Cc:
> Subject: RE: [Diffserv-interest] Re:  draft-baker-diffserv-basic-classes-01
> .txt
> Brian E Carpenter wrote:
> John, I guess your comment refers to the draft so I changed the subject.
> If you want to be sure the authors see your comments, you might want  to
> write to them directly. My reactions inserted below.
>    Brian 
> "John H. Shuler" wrote:
>> >  
>> > Why make a distinction between "Standard Service Class" and "Low  Priority
>> > Data"? 
> There is a kitchen sink aspect to this draft  that worries me. Rather than
> starting simple, with three or four generic  service classes, the authors
> have chosen to present the union of a number  of diffserv deployment models.
> I think that risks confusing operators by  giving them too much complexity
> to choose from. 
> [[Joe] The draft  tries to address the service differentiation that is needed
> in carriers and  enterprise networks including access networks. I agree that
> network  administrators both in carrier and enterprise should start off with
> only the  service differentiation level (service classes) that are required
> for their  business. Let me provide some examples that I worked on so that you
> can  understand why we have defined the number of service classes.
> Carriers  wanted to use IP technology for provide telephony service, plus
> provide IP VPN  service with CIR as well basic Internet connectivity service.
> This scenario  can be address by configuring the network using the following
> service classes  define in the draft.
> - Standard service class for Internet connectivity
> - High Throughput Data service class of IP VPN and collection of network  data
> for billing 
> - Telephony service class for VoIP and signaling between  voice gateways
> - Network Control service classes for routing, etc.
> This simple example used four of the defined service classes.
> A different operator is deploying the services listed above plus new
> multimedia IP services like desktop video conferencing to go along with
> telephony, instant massaging plus other "workflow" applications.
> This  operator needs:
> - Standard 
> - High Throughput Data
> - Low Latency  Data
> - Multimedia Conferencing
> - Telephony 
> - Network Control
> Another operator has plans to offer broadcast TV service,  pay-per-view,
> telephony, two different SLAs for IP VPN services and basic  Internet
> connectivity. They will need:
> - Standard 
> - High Throughput  Data
> - Low Latency Data
> - Multimedia Streaming
> - Telephony 
> -  Network Control
> A large enterprise is currently configuring their  network to support the
> flowing service classes (using the drafts terminology).  Most location will
> have a subset of services available with migration to  network wide service
> transparency in the future.
> - Standard 
> - High  Throughput Data
> - Low Latency Data
> - Multimedia Streaming
> -  Multimedia Conferencing
> - Telephony 
> - Network Control
> -  Administration
> I can go through more scenarios that I have come across  over the years.
> I agree that two or three user service classes is what  many operators start
> off with, however they are not always the same three and  they always like to
> know how they can evolve in the future.]
> Regards,  Joe. 
> Jozef Babiarz 
> QoS and Network Architecture
> Nortel Networks  
> email:
> Tel: (613) 763-6098 ESN:393-6098