Subject: RE: [Diffserv] Resource provisioning to support SLAs

From: Jay Wang <[email-masked]>
Date: Mon, 18 Sep 2000 10:53:15 -0700

> -----Original Message-----
> From: Huan Pham [mailto:[email-masked]]
> Sent: Sunday, September 17, 2000 10:22 PM
> To: DiffServ mailing list
> Subject: [Diffserv] Resource provisioning to support SLAs
> 
> 
> 
> Hi DiffServers,
> 
> I have a concern regarding the way a DiffServ provider do resource
> provisioning to support SLAs
> 
> As I understand in SLA, the bandwidth required by customers 
> for specific
> classes of service is specified, but the DiffServ provider has no
> information about where that traffic going to.
> 

Depend on the kind of traffic, this is not necessary the case though.

> There might be two possible sollutions:
> 
> 1  -  DiffServe Provider over-provision the resource 
> (bandwidth, memory)
> so that in the worst case, if all traffic (conforming to SLAs from
> different customers) heading to one destination (let's say 
> one customer
> network), the traffic will not end up with a bottle neck.
> 
> This is of course extremely inefficient way of resource provisioning.
> 
> 2  -  Based on historical measured traffic information (which tell us
> where the customers' traffic going to/from), DiffServ 
> provider provision
> the resource on a statistical basis. The DiffServ provider is not sure
> that in all cases its resource provision is enough. If this 
> is the case,
> I just don't know what would happen if there is not enough resource to
> cope with the worst case mentioned above? What the DiffServ 
> get penalty
> for breaking SLAs.
> 
> 

Yes, indeed for traffic streams that you don't know the destination 
addresses at the provisioning time, this is a problem. I think provisioning/
resource management based on a statistical analysis/projection is fine,
but this has to be coupled with performance/conformance monitoring. If the
QoS falls under, the consequent actions can be policy-driven, for example,
reshuffle the bandwidth distribution among classes, give customer credit, 
or dimply drop the service.

- Jay

> I would appreciate any reply, comments.
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

---

From: Huan Pham <[email-masked]>
Date: Tue, 19 Sep 2000 12:07:33 +1000

Thank Jay and Tina very much  for your responses.

> Depend on the kind of traffic, this is not necessary the case though.

You mean that the throughput is not always need to be stated in the SLA?
Could you make it clearer please

> or dimply drop the service.

Yes I agree that performance/conformance monitoring and police-driven
actions can keep the service above a required QoS level. But I think
this should be applied to dynamic SLA traffic only. The newer request
for SLA will be dropped when there is not enough resource.

On the other hand for static SLA, they buy the service in advance. If a
customer A who is buying 100Kbit/s of EF PHB class  and at some point in
time it can only be transmiting 50Kbits/s  (because of  bottleneck of EF
PHB somewhere in the network) .  This  should be considered as the
network provider breaks the SLA, shoudn't it?

Now my question is more specific:
How the network provider dimentions the network to meet static
pre-subscribed SLA traffic? Over-provision to account for worst case ???
(I meant if traffic from all customers are not evenly distributed, but
heading to a same specific destination - for examle).