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

["John H. Shuler" <[e-mail]>]

Dimitry,

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.

j


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

John,
 
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.
 
Regards,
  Dimitry
>  
> -----Original Message-----
> From: John H. Shuler  [mailto:[e-mail]]
> Sent: Sunday, November 02, 2003 5:30  PM
> To: Jozef Babiarz; Brian E Carpenter
> Cc:  [e-mail]
> 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 <[e-mail]>
> Date:  Sun, 02 Nov 2003 16:52:18 -0500
> To: Brian E Carpenter  <[e-mail]>, "John H. Shuler"
> <[e-mail]>
> Cc:  [e-mail]
> 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: [e-mail]
> Tel: [phone] ESN:393-6098
>