Subject: [Diffserv] One-To-Any AR PDB

From: Nabil Seddigh <[email-masked]>
Date: Fri, 16 Mar 2001 14:55:30 -0500

I just read the one-to-any AR PDB draft. 
The key concept in the draft appears to be
an admission control mechanism for aggregates based on
assigning traffic distribution probabilities for each 
ingress-egress pair visited by that aggregate.

In this respect, it seems to me there are a few key 
issues worth discussing:

- The draft says the traffic distributions MAY be a 
  PDB parameter for an aggregate.
  I doubt customers would specify such information as it
  is difficult to predict ahead of time. In a network with
  hundreds of nodes, it will be difficult for a customer to
  provide a probability for each of the 100 egresses that
  its traffic may visit from a particular ingress.

- Morover, an aggregate's parameters would usually be
  something that the network would assure and also
  enforce: such as the rate. The provider can neither
  assure the traffic distribution nor enforce it.
  The latter is theoretically possible via an 
  edge device mechanism but may introduce scalability
  concerns and may not be desirable.

- The draft specifies a loss probability to be 
  associated with the PDB parameters. In order for 
  such information to be useful, there must be an 
  indication of how such probability will be measured.
  This is something that needs careful consideration.
  e.g. Is a measurement interval for the loss probability
  sufficient? Probably not. Hotspot routing 
  type problems (eg olympic server), may cause loss 
  rates to be temporarily skewed for timeframes 
  longer than the measurement interval. In any case,
  just wanted to point out it is not as simple of 
  stating a loss probability as a PDB parameter. The
  AR PDB originally had much discussion on loss
  probability but the authors finally agreed to take
  it out because not all providers want to explicitly 
  guarantee a loss probability. 

- IMHO, the key contribution of the draft, is providing
  one mechanism to assist in realizing the AR PDB.  I don't
  think it is really a separate PDB definition. 
  I'm also not sure there is sufficient evidence to say that 
  such an approach is better than one based on 
  monitoring traffic loads. 

Best,
Nabil

> 
> INTERNET-DRAFT                                               M. Brunner
> draft-brunner-diffserv-pdb-one2any-ar-00.txt                  A. Banchs
> Expires August 2001                                       S. Tartarelli
>                                                                  H. Pan
>                                                         NEC Corporation
> 
>                                                           February 2001
> 
>    An one-to-any Assured Rate Per-Domain Behavior for Differentiated
>                                 Services
>              <draft-brunner-diffserv-pdb-one2any-ar-00.txt>
>

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: demir <[email-masked]>
Date: Fri, 16 Mar 2001 13:45:22 -0800 (PST)

I, also, agree with all comments made by Nabil below. I have a question
on the traffic  volume granularity of an admission control:
As far as I am aware of, all current admission control research is based
on a finer-grained traffic that is five tupple microflows
(srcIP,dstIP,srcPrt,dstPrt,protocolID). However the grain of Diffserv
aggregate is much larger than microflow (I am not very familiar with ATM
or any other architectures, but I assume they are the same way, too). To
me the question is: Do we need "admission control" for Diffserv
aggregates (actually, what is the granularity that can be used for
admission control)? If so, what is the granularity of services that can be
provided and if clients are willing to use it? If not, then I assume there
are easier mechanisms that can be used such as one described in AR PDB
(Nabil also points it out in a differnt way in his last comment).
My last concern is on the implementation and service provider
issue: will clients ask for "stochastic" services at all if the network
dynamics can not be predetermined with current tools we have, and will
network dynamics not change at all (what is the time scale that network
dynamics change drasticaly?)

Alper K. Demir

---

From: [email-masked]
Date: Mon, 19 Mar 2001 03:40:26 +0100 (CET)

Nabil Seddigh <[email-masked]> wrote :

[...]
>   its traffic may visit from a particular ingress.

I agree, that most customers won't be able to specify that. But some may be 
around, which have a very clear picture of their usage. Therefore it is a MAY. 
IMO, the probability is a function of the capacity or utilization of the egress 
links assuming that new users behave similar to the total of the existing users.
 
>   concerns and may not be desirable.

You are right, the latter has severe scalability problems (to our todays 
knowledge). But as said before, the probability as a parameter makes only 
sense in a few scenarios.

>   guarantee a loss probability. 

We recognized, that loss probability is the wrong wording. What we meant is the 
probability of congestion in a buffer less network model. (Albert, Sandra do I 
correctly discribe our discussion?

>   monitoring traffic loads. 

We do not claim to be better, but we try to quantify the congestion probability 
(at least an upper bound). I would like to here some other opinions on whether 
it is a seperate PDB or not.

Marcus

> > INTERNET-DRAFT                                               M.
> Brunner
> >                                                                  H.
> Pan
> >                                                         NEC
> Corporation
> >                                                           February
> 2001

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 19 Mar 2001 18:55:57 -0500

[email-masked] wrote:

> We do not claim to be better, but we try to quantify the 
> congestion probability (at least an upper bound). 
> I would like to here some other opinions on whether

What I meant was: the introduction (section 1.0) of the 
one2any draft implies that the AR PDB as defined 
cannot be used for a one-to-any service. It further
appears to infer that folks deploying the AR PDB
would use an admission control scheme based on
multi-path capacity reservation. Neither of the above
are the case.

The AR PDB applies to the one-to-any scenario and 
does not mandate how it should be realized.

Best,
Nabil

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 20 Mar 2001 04:57:21 +0100

> does not mandate how it should be realized.

Oh, did we write that? The emphasis was on the fact, that one-to-one
assured rate with admission control may be provided differently than we
use in our draft. Which means in fact that our draft may not work well
for the one-to-one case. 

Since your draft does not specify how the PDB should be provided, we can
not argue about whether it is at all comparable with ours. Sorry for any
misunderstandings, we will fiix it in a future version. 

Marcus
-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155