Subject: [Diffserv] Does Diffserv need an admission control?

From: Safeen <[email-masked]>
Date: Thu, 15 Feb 2001 20:18:06 -0800 (PST)

Hi group,

I have a simple question which is, does DS need an
admission control?
Thanx

Safeen

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

_______________________________________________
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: Fred Baker <[email-masked]>
Date: Fri, 16 Feb 2001 00:04:20 -0800

>I have a simple question which is, does DS need an

IMHO, some applications (notably VoIP and Video on IP) do; I would expect 
that would use two or more separate instances of EF, due to the fact that 
both are essentially fixed mean rate and have different scheduling 
deadlines from a deadline scheduling perspective. Some will tell you that 
AF works for video, and they may be right, but again only if it is 
provisioned with sufficient bandwidth, and there is no way to tell that 
from the application apart from signalling. So I will argue that those 
instances of diff-serv do indeed call for signalling and admission.

Admission for TCP or whatever - if it needed admission with diffserv, it 
would surely need it without diffserv, and the fact that the Internet works 
tells us it doesn't now.

---

From: "Jay Wang" <[email-masked]>
Date: Fri, 16 Feb 2001 10:06:15 -0800

Hi,

If your question is that in applying Diffserv architecture to
achieve QoS, do we need to conduct admission control? In this
case, the answer is yes.  Otherwise, you will not be able to
support any sensible SLA.

thanks.

- Jay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Safeen
Sent: Thursday, February 15, 2001 8:18 PM
To: [email-masked]
Subject: [Diffserv] Does Diffserv need an admission control?

Hi group,

Safeen

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

---

From: stanislav shalunov <[email-masked]>
Date: 16 Feb 2001 13:53:35 -0500

Safeen <[email-masked]> writes:

> does DS need an admission control?

This would depend on the service in question.  EF sure needs some form
of admission control (and associated policing), but I don't see why
Bulk Handling would need any form of admission control.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

I never let school stand in the way of my education.  -- Mark Twain

---

From: John Wroclawski <[email-masked]>
Date: Fri, 16 Feb 2001 14:04:04 -0500

>support any sensible SLA.

Welll...

The question is one of relative versus absolute service.

A service that gives the user a numerical bound on some performance 
metric (X mb/s, X ms delay, etc..) generally needs admission control. 
This is an "absolute service" because the QoS is held to some 
particular absolute numerical value.

A service of the form "my packets are more important than his, and 
get to go first" (or "Napster packets are less important than email, 
and get to go last") does not need admission control. This is a 
"relative service" because it is expressed relative to how other 
traffic is treated, not in absolute numerical terms.

People seem to think that both of these are useful in different circumstances.

John

---

From: "Jay Wang" <[email-masked]>
Date: Fri, 16 Feb 2001 15:17:57 -0800

Well, I agree that depending on the nature of the SLA, the
importance of admission control may vary (that is why I did
not say for ALL SLAs, we absolutely need admission control).
BUT, even for QoS on a "relative" sense, I disagree that
admission control is necessarily not useful.  Yeah, sure your
service plan may simply say that type A application is more
important than type B traffic as you stated.  Given such,
presumably what you want is that your type A traffic to receive
somewhat "better" treatment than the type B application.  Certainly,
in a normal day, Diffserv w/o admission control may give you what
you want IF you have done proper traffic engineering.  However,
suppose for some abnormal reason the system is swamped with huge
amount of packets of type A application for a significant period,
then Diffserv w/o proper admission control may not even satisfy your
simple SLA (i.e., classification, policing and scheduling along won't
cut it).

cheers,

- Jay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of John Wroclawski
Sent: Friday, February 16, 2001 11:04 AM
To: Jay Wang; [email-masked]; [email-masked]
Subject: RE: [Diffserv] Does Diffserv need an admission control?

Welll...

People seem to think that both of these are useful in different
circumstances.

John

---

From: demir <[email-masked]>
Date: Fri, 16 Feb 2001 16:49:09 -0800 (PST)

I agree with Jay Wang. Please see below:

> you want IF you have done proper traffic engineering.  

...or with support of proper per-hop behaviors (?) (I guess this is out of
scope of IETF Diffserv).

> However,

I am unable to understan how "admission control" would help for the above
problem.

I think "admission control" may be used for any "qualitative" SLA if
needed. Also, Using "admission control" for "quantitative"/"qualitative" 
SLAs will ease the "provisioning problem" of a diffserv domain(?).

Alper K. Demir

---

From: Bora Akyol <[email-masked]>
Date: Fri, 16 Feb 2001 17:46:30 -0800

The whole point of diffserv is that you do the either policy based enforcement or admission
control at the edge and combine that with policing so that whatever is presented to the
core is fairly well understood and remains along the bandwidth limits set.

If you really want to be strict you can run Diffserv combined with MPLS LSPs such that you
not only know the bandwidths involved but also the routing of the flows (which, IMHO, is
one of the shortcomings of the existing diffserv work).

Other than these there are no strict guarantees. Edge boxes almost end up doing all the
work, while the big iron at the core just does smart(er) queueing and shaping.

Bora

---

From: "GwangHoon Kwark" <[email-masked]>
Date: Sat, 17 Feb 2001 10:46:08 +0900

Right, My opinion is same as Jay Wang.
Occasionally, CAC will be mandatory even with AF.
The main focus is that the service is considered with per-class scheme, not
with per-flow schemd.
Without CAC, the service quility of previous flow should be influenced by
late joined flow with (even)SAME AF class as Previous flow's as well as by
another flow with low AF classes
Nobody may want SLA that 'I need service alway better than other's whatever
the amount of performance varys'
----- Original Message -----
From: "Jay Wang" <[email-masked]>
To: "John Wroclawski" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, February 17, 2001 8:17 AM
Subject: RE: [Diffserv] Does Diffserv need an admission control?

---

From: Constantinos Dovrolis <[email-masked]>
Date: Sat, 17 Feb 2001 10:39:22 -0500 (EST)

This is an interesting thread, and even though it is not related
to the WG agenda, it may help finding out what is missing from
the current DiffServ model.

IMO, per-flow admission control (a la ATM CAC or IntServ) is only
one way to do *load control*, i.e., to control the offered load
into the network so that you can provide deterministic or statistical
absolute guarantees. Traditionally, per-flow admission control
required a signalling protocol (RSVP or simplifications like YesSIR),
and per-flow control state plus an admission control test in
each router of the flow's path. This was probably the least scalable
component of those architectures.

More recently, there have been proposals for doing distributed
admission control *without* requiring signalling and per-flow state
at the core. To name two such works:

1. 'Endpoint Admission COntrol", by L.Breslau et al (Sigcomm 2000)

2. 'Providing Guaranteed Services without Per-Flow Management", By
    I.SToika & Zhang (Sigcomm 1999)

However, admission control (with or without a signalling protocol)
is not the only way to do load control.

The most widely used form of load control is bandwidth provisioning,
i.e., monitor the utilization of each link and use a wider pipe
when the utilization reaches a certain point. This load control
mechanism does not have the "fine granularity" of per-flow guarantees
and it cannot be effective in short timescales or when the network
experiences sudden changes in the topology or demand. For
normal operating conditions, though, it does work and it is the
simplest way to offer some type of absolute QoS. DiffServ can be
used in this context to differentiate between classes of service
even though there is no admission control per se. In that case,
as long as the utilization of the link does not exceed a certain
point, different classes of service can get different absolute
delays/loss rates, in some finite-horizon average sense. This is
for example what UUNET does (check their SLAs about round-trip
times).

What is still an open question IMO, is how to combine provisioning
with some kind of edge devices that block/limit sudden large
traffic loads. These edge devices cannot be simple leaky bucket
type of controllers, because they have to have a clue about the
traffic's egress point.

Regarding admission control and relative services: We have to
keep in mind that for many users and applications there is no absolute
QoS requirement, and even if there is one, it is only loosely
defined. Instead, these applications/users normally have *absolute
cost constraints*, i.e., do not use a class of service that costs
more than X cents per MB. In this context, you want to find the
best possible CoS that meets your cost constraints. Even though
admission control or provisioning would be helpful, in order
to associate an absolute (but average) QoS grading of the class,
it is certainly not required.

Cheers

Constantinos

Computer and Information Sciences - University of Delaware

http://www.cis.udel.edu/~dovrolis/

---

From: demir <[email-masked]>
Date: Sun, 18 Feb 2001 07:19:02 -0800 (PST)

Dear Authors,
I have two comments regarding to AR PDB:   
1)
   "This document uses  "one-to-one"  to  describe  a  traffic  aggregate
   entering  via  a  single ingress point of a domain and exiting from a
   single egress point for the domain. One-to-any refers  to  a  traffic
   aggregate  with  single entry point and multiple (any) exit points in
   the domain. One-to-few refers to  a  traffic  aggregate  with  single
   ingress point and fixed set of egress points within a domain."

I think, above features of AR PDB is defined a little loose. To me, it
needs further expolaration and some elaboration. To me, it seems that
"provisioning" might become more complicated with the support of  
"one-to-any" and "one-to-few" traffic aggregate (from 
ingress-to-egress) features. While provisioning, utilization of network
resources might become a more complicated problem to solve. with these
features. I am not sure if you have a specific mechanism in mind to
support such features. If so, could you please be a little more
specific? I think same argument is not valid for Virtual Wire (VW) PDB
because EF PHB provides a base for VW PDB to provide such features (I
assume (expected) well-defined output rate of EF PHB is the base).

2) 
   "The  AR  PDB  is  suitable for carrying traffic aggregates that
   require rate assurance but do not require  delay  and jitter  bounds."

   "It may be possible to determine delay and jitter bounds  for  traffic 
   aggregates  using the AR PDB. However, such parameters are beyond the
   scope of this PDB definition and no attempt is made  to  characterize
   them. Development of a mathematical model to predict delay and jitter
   for the  AR  PDB  is  left  as  a  subject  of  future  research  and
   investigation."

It seems AR PDB does not (specifically) say that AR PDB will not provide
delay and jitter bounds for traffic aggregates. I am not sure if a PDB
allows a "future research" feature. To me, it seems it is reasonable to
discuss about open research features (in AR PDB, they are delay and
jitter) related to a PDB. I guess the answer will depend on if a PDB
definition allows such open research and investigation features to be
owned by a PDB. If the answer is "yes", it seems it is a little easier to
provide some additional features in a PDB.

Alper K. Demir

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 19 Feb 2001 17:11:44 +0100

Demir,

I totally agree with your first comment, this is the reason why we are 
working on one-to-any AR PDB, which will hopefully submitted before the 
cutoff date.

The second comment, I think if a PDB with delay and jitter guarantees is 
defined no problem, but it should be in a seperate PDB.

Marcus

- --On Sunday, February 18, 2001 7:19 AM -0800 demir <[email-masked]> wrote:

> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis
> t.html
>

- --------------------------------------
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