Subject: Re: [Diffserv] A question on PHB-PDB relationship

From: demir <[email-masked]>
Date: Thu, 1 Mar 2001 12:59:41 -0800 (PST)

Brian,
Pre-note: I am aware of that this is a fundamental argument. My intention
is to learn the factors/trade offs on choosing current Diffserv 
Arcitecture as it is. I am sorry if this was an earlier discussions in
Diffserv group. I wasn't a member of diffserv discussion group back then.
In addition to below lines I would like to add: It seems to me that AF PHB
with a "loose" rate contraint (+ some other contraints if PDB definition
can't achieve adding additional contraints to PHB) would suffice as a
building block (p.s. if a PDB definition can add such contraint then only
AF PHB is enough as a PHB level building block. I mis-used
"overload" term, I guess. I meant adding additional contraints on a PHB,
i.e. adding rate contraint to AF PHB when defining (Expedited) Virtual
Wire PDB + delay). I assume loss also will depend on buffer/queue length
allocated.  Current, EF PHB claims that EF PHB can be used to build low
loss, low delay, low jitter, assured bandwidth services. I asked the
question of if "low jitter" is claimed or not, but didn't receive any
reply. If this is the case, then I don't see any reason why AF PHB can't
claim to be a building block for such services.
Going back to this threads discussion, I tried to make this point a long
time ago. To me, the most fundamental building block is a assurance
varying from 0% to 100%. I guess, this is the current Internet with no QoS
support (congestion control and avoidance is excluded). What AF PHB is put
into current architecture is to provide assurance levels for packets that
is marking packets with different assurance levels (from 0% to 100%). I
assume this mechanisms is a building block for "low loss" services. The
other two contraint that a PHB can achieve is rate and delay contraint. I
don't think that jitter contraint can be achieved efficiently by a PHB. As
a result result, a PHB can have a rate, delay, loss contraints varying
from 0% to 100%. Though jitter is not one of the contraints that a PHB can
achieve it efficiently, let's assume that this contraint can be achieved
varying from 0% to 100% (though current research shows that with aggregate
scheduling 100% is not possible if we don't know the topology where EF
addresses this with "figure of merit"). 
Regarding to congestion control and avoidance, I asked the question of "if
we need adaptive protocols in QoS-enabled networks" to
end-to-end-interest list a long time ago. I assume the answer to that is
for default (let's assume best-effort)  and default-like services, we need
adaptive protocols, i.e. the current Internet. Still, I am not sure if we
need it for non-defaul services. I assume for some services to improve the
performance of applications using this services and fairness among
applications, adaptive applications will help. However, I assume this
complexity can be pushed into the edge (this is kind of end-to-end
argument, I guess). I am aware of that TCP is all around and we need
mechanisms to protect TCP flows in a QoS-enabled networks. I assume
this is a whole different research and you will tell me to take this to
diffserv-interest.
Post-note: I am aware of that this is a fundamental argument. My intention 
is to learn the factors/trade offs on choosing current Diffserv
architecture as it is.

Alper K. Demir

On Wed, 28 Feb 2001, demir wrote:

> Brian,
> Then what's wrong with defining a "Expedited Virtual Wire" PDB based on AF
> PHB instead of defining a EF PHB purely. It seems that only AF PHB is
> enough with some loose definitions (meaning intead of MUSTs, MAYs,
> etc...). The rest is to define "right" PDBs (p.s. I am not sure about
> class selectors :) 
> 
> Alper K. Demir
> 
> 
> On Wed, 28 Feb 2001, Brian E Carpenter wrote:
> 
> > Some of us believe that the set of PHBs already defined (default,
> > class selectors, AF, EF) is rich enough to keep us busy for many
> > years - i.e. they give us enough flexibility to define a rich set
> > of PDBs. 
> > 
> >   Brian
> > 
> > demir wrote:
> > > 
> > > Brian,
> > > > It seems perfectly reasonable for a PDB definition to constrain the
> > > > parameters of the PHB it is using (I wouldn't use the word overload).
> > > > Actually the BH PDB does exactly that to the class selector, which
> > > > is why Kathie and I don't see the need for an LE PHB.
> > > 
> > > I assume the choice is kind of an "end-to-end argument". One might make an
> > > extereme argument such that only one PHB is enough /Or We don't need PHBs
> > > at all; PDBs can take care of that. Is there a fine-line /Or is there
> > > system design guidelines (tradeoffs defining a PDB with existing ones or
> > > defining a new PHB) that Diffserv suggests?
> > > 
> > > Alper K. Demir
> > > 
> > > >
> > > >    Brian
> > > >
> > > > demir wrote:
> > > > >
> > > > > Can a PDB definition overload a PHB definition? To be more specific, Can
> > > > > someone define a PDB where he/she overloads a PHB with additional
> > > > > rules? i.e. Foo PDB: Based on AF PHB, but wants to achieve the goals of a
> > > > > PDB based on EF PHB, i.e. VW (virtual wire) and has rules such as:
> > > > > MaxThreshold=MinThreshold=AFQueueLength, mark only using one DSCP,
> > > > > additional delay and rate constraints defined in the new EF draft, etc...
> > > > > Let's not discuss if Foo PDB makes sense or not to choose such a way. My
> > > > > aim is not to ask if it is possible to achieve EF-based PDB using AF-based
> > > > > PDB. I am also aware of that, if one needs a PHB to define a PDB, he/she
> > > > > could define a new PHB.
> > > > >
> > > > > Alper K. Demir
> > 
> > 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Mar 2001 15:06:11 -0600

If you define a mathematically sound PDB that way, I can't see anything
wrong. 

The class selectors are mainly there for compatibility with IP Precedence,
but the first VW I ever experienced ran over class selector 5 with PQ
and strict admission control. It worked just fine.

   Brian

---

From: demir <[email-masked]>
Date: Thu, 1 Mar 2001 14:06:43 -0800 (PST)

> and strict admission control. It worked just fine.

- The (strict) admission control was for Diffserv EF aggregate or per-flow
(meaning microflow/application flow) at the edge ??? 
- I assume network was a little "overprovisioned" to achieve rate
constraints ??? 
- Was jitter among the services to be supported? If so, I assume jitter
accumulation problem was solved with toplology-are
setup/configuration/mechanisms??? 
- I appreciate any pointer/reference. Thank you very much.

Alper K. Demir

---

From: demir <[email-masked]>
Date: Thu, 1 Mar 2001 16:01:05 -0800 (PST)

Brian,
> If you define a mathematically sound PDB that way, I can't see anything

I remember your answer that stated "self-similar traffic" based on a
mathematical model. I wasn't very sure what you meant by this, but to me
some deterministic/stochastic models can achieve delay/jitter services
based on AF PHB. I might be underestimating the problems.
What I meant by "Expedited Virtual Wire" PDB is to inherit the current EF
PHB constraints as PDB constraints. In this context, "jitter
accumulation" fits very well here. However, my intention was not this
explicitly. I am trying to understand current design choices/tradeoff of
current Diffserv architecture (especially fundamental designof it) over
this approach. I tried to explain this in one of my previous (long
one) message. I also remember somehow related point made by Juha (I am
sorry if I am naming the wrong person). I hope I am not missing any
important issue here. Please see my previous email explained more detail.

P.S. I still didn't receive any answer if "jitter" is part of services
that EF might support.

Alper K. Demir

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 02 Mar 2001 10:46:22 -0800

demir wrote:
> PHB instead of defining a EF PHB purely. 
...

You can define any PDB you wish, but please note that "Virtual Wire"
is already taken. There are lots of possible names out there. For
example, use Virtual Leased Line. We abandoned that name since it
was getting a sort of colloquial use that was inconsistent with the
original intent. 

	Kathie

---

From: demir <[email-masked]>
Date: Fri, 2 Mar 2001 11:31:17 -0800 (PST)

Katie,
My intention is not to state that I would like to use "Virtual Wire" name
at all (I am not trying to write a PDB, I wish I were at that stage :).
It was just an example. I used that name so that readers can
understand my point. Please refer to my old email regarding to my
point. Thank you very much for reminding about naming issue though.

Alper K. Demir