Subject: [Diffserv] AF used in AR PDB

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Jan 2001 07:55:20 -0800

Hi,

I have the following questions/concerns regarding this draft:

1) "However, all aggregates using this PDB in a single
   domain SHOULD utilize the same AF class PHB  set."

This statement implies that there can be only one instant of AR PDB. My question is: why can't we generalize this and permit up to 4 instances of AR PDB. By doing so we can construct up to 4 different AR PDBs, that may differ for example on the loss probability of yellow/red packets, or even on the delay that they experience, depending on the provisioning of each AF class (AF PSC) such as the amount of over-subscription.
   
Yours,
-Shahram 

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Tue, 9 Jan 2001 18:20:18 +0200 (EET)

fine with me that we allow more than one ar pdp running simultaneously.
the only restriction should be that packets that belong to the same ar
pdp instance use code points from the same af class.

-- juha

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 09 Jan 2001 17:45:38 +0100

Sharam,

As I understand the draft, no loss probability is quantitativly given,
and no delay and jitter assurance is given. So what are the possible
different AR PDB you want to add. I think it is a good idea to keep all
AR PDB in the same AF PHB set.

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

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 9 Jan 2001 19:13:36 +0200

Hi Shahram and all,

  I think that Shahram's question is legitimate. What is more, I think that
ability to support more than one instance of AR PDB across a given domain is
a highly desirable feature. E.g., a service provider supporting several L2
VPN types over its domain may wish to separate resource allocation for one
VPN type from resource allocation for the other one while providing
guarantees of low loss rate within the specified CIRfor both VPN types.

  As AR PDB is currently the only known PDB to use AFx PHB, limiting domains
to only one AR PDB instance would effectively mean that multiple AF classes
are not really needed.

  If there is a specific technical reason behind the draft limitation, it
deserves explanation.

______________________________________________
With best regards,

  Sasha Vainshtein

mailto: [email-masked]
phone: +972-3-7659993 (office)
fax:      +972-3-6487779 (office)

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf
>>Of Shahram Davari
>>Sent: Tuesday, January 09, 2001 5:55 PM
>>To: [email-masked]
>>Subject: [Diffserv] AF used in AR PDB
>>
>>
>>Hi,
>>
>>This statement implies that there can be only one instant of AR
>>PDB. My question is: why can't we generalize this and permit up
>>to 4 instances of AR PDB. By doing so we can construct up to 4
>>different AR PDBs, that may differ for example on the loss
>>probability of yellow/red packets, or even on the delay that they
>>experience, depending on the provisioning of each AF class (AF
>>PSC) such as the amount of over-subscription.
>>
>>Yours,
>>-Shahram
>>
>>Archive:
>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/
maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Jan 2001 11:39:53 -0600

Marcus,

If you have N customers, you may want to sell each of them their own
instance of the AR PDB. If some customers overload their PDB more than
others, they will in fact experience more loss and more jitter. That's
a fact, even if the PDB doesn't have loss or jitter parameters.

   Brian

---

From: Dan Grossman <[email-masked]>
Date: Tue, 09 Jan 2001 13:27:43 -0500

> instance of the AR PDB.
Which is a scaling limit of AR, and which should be included in the draft.

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 10 Jan 2001 13:45:33 +0100

Brian,

Sure I fully understand that. However, looking into the parameter list
of the PDB, different instances of a PDB vary only in the assured rate,
max packet size, and some traffic parameters (including averaging time).
What is the criteria for putting AR PDB in different PHB sets?

Marcus

-- 

Dr. Marcus Brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 10 Jan 2001 13:51:31 +0100

Dan,

Basically, I think you sell the customers a service not a PDB. But
beside this, I do not see the scaling problem. It is clear having
different customers, you need to maintain customer records etc. The only
configuration you have to perform per customer is configuring the CIR
into the ingress interface.

Marcus

-- 

Dr. Marcus Brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: demir <[email-masked]>
Date: Wed, 10 Jan 2001 10:37:28 -0800 (PST)

I agreee with this. In one of my previous email, I mentioned this as:
An Example PDB in AF PHB is given as:
   "In a typical application, a company uses the Internet
   to interconnect its geographically distributed sites and wants an
   assurance that IP packets within this intranet are forwarded with
   high probability as long as the aggregate traffic from each site does
   not exceed the subscribed information rate (profile).  It is
   desirable that a site may exceed the subscribed profile with the
   understanding that the excess traffic is not delivered with as high
   probability as the traffic that is within the profile."

I assume in AR PDB traffic aggregate is the total of the aggregate traffic
from each site. How to control aggregate traffic from each site is left
open. Ths also deserves some explanation.

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jan 2001 15:50:03 -0600

If I understand your question, there are no criteria: if you choose to
run 7 instances of the AR PDB, you will need 7 AF DSCP sets, i.e. 21 DCSP
values. But it has no importance which DSCP value is configured for which
instance of the PDB.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jan 2001 15:47:33 -0600

You seem to be missing that
a) some customers will want their traffic to be competing only with itself,
   i.e. they do not wish to share a PDB instance with other users.
b) different PDB instances may be engineered with different degrees of
   overbooking (and therefore different busy-hour performance).

Of course there will be admission control per customer per ingress
as well, but that is part of basic diffserv & doesn't need to be
restated in every document.

   Brian

---

From: demir <[email-masked]>
Date: Thu, 11 Jan 2001 18:23:37 -0800 (PST)

Brian,
Does this mean that a Diffserv PDB will have limited PDB instances on a
Diffserv domain? If so, is this a scability problem of PDBs? If not, what
is the proposed/suggested solution (can you give an example/intuition)?

>    i.e. they do not wish to share a PDB instance with other users.

Is it possible to isolate two PDB instances during the same time assuming 
thraffic aggregates share some resources (is this a resource management
issue as you mentioned in b? I so, is this a conflict with a) cause a
customer may not want its traffic to compete with others; actually I
guess answer depends on how isolation is achieved?)?

Alper K. Demir

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Jan 2001 16:54:49 -0600

I presume that the number of PDB instances is limited by the number of DSCPs, which
is by construction limited to 64. Of course the number of PDB instances is
limited to less than 64 if multi-DSCP behaviors such as AF are used.

This is a limit we accepted as the necessary price of the other nice
scaling properties of diffserv. 

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]