Subject: [Diffserv] AR PDB

From: Kathleen Nichols <[email-masked]>
Date: Thu, 11 Jan 2001 10:34:55 -0800

Nabil, et al

This draft seems rather thin on the "technical specifications" and
"attributes" as defined in sections 5.2 and 5.3 of the pdb-def
draft. Your draft says that "The attributes of this PDB include a
basic throughput rate that is assured and low drop probability for the 
traffic conformant to the contracted rate." in section 4.0. And
in section 5.0 says "This PDB MUST have the following parameters:

	-A committed information rate (CIR), that is assured with
	high probability. ....
	The PDB does not define "high probability".

I believe this is tangling up the concept of a service that might
be offered based on this PDB and the PDB definition itself. Section
5.3 of the pdb-def draft tries to explain how these can be different.
So, it would be entirely reasonable to offer a service based on
the AR PDB that is presented to the customer as some throughput
delievered with some (high) probability, but the PDB is a *technical*
specification, not a service specification. So the drafts of PDBs
are supposed to have some numerical relationship between a probability
and a particular configuration. This, in turn, can be used by a
network operator to decide just what "high probability" in a service
might be a comfortable setting. As was covered on another thread, is
this statistical level affected by the number of customers in the
aggregate? If so, how? These are the kinds of questions a PDB definition
is supposed to answer.

	Kathie

_______________________________________________
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: Thu, 11 Jan 2001 21:23:00 +0200 (EET)

Kathleen Nichols writes:

 > So the drafts of PDBs
 > and a particular configuration. 

this is not something that we want to get into.  if the pdb i-d asks for
numerical analysis, then it might make sense to change it.  the idea of
the ar pdb is that the network operator is monitoring the amount of
green packets on the links and by experience learns what maximum amounts
are that in his particular network topology and subscribed set of
service profiles still delivered green packets with "high" probability.

//juha

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jan 2001 18:33:35 -0600

Juha,

OK. So you are saying (and I agree) that we don't have a mathematical model
for AR (or even AF). This should be spelled out in the draft I think.
This explains why you don't cover the delay/jitter issues as some people
asked - you don't because you can't - and imho that should also be explicitly
stated.

  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]

---

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

Brian,

> asked - you don't because you can't - and imho that should also be explicitly
Does this mean that any sort of delay/jitter (i.e. statistical) is not
possible to be achieved? I am not very sure, but I think some sort of
delay/jitter issue can be addressed (may be not by AR PDB, but some other
PDB based on AF PHB?)?

Alper K. Demir

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 12 Jan 2001 08:31:04 +0200 (EET)

Brian E Carpenter writes:

 > asked - you don't because you can't - and imho that should also be
 > explicitly stated.

yes, we need to state that explicitly.

-- juha

---

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

When someone develops the approriate queuing theory for self-similar traffic
across a mesh of nodes behaving with the complexity of AF, we can perhaps
say more. But surely not today.

  Brian