Subject: [Diffserv] DiffServ & CAC

From: shen jing <[email-masked]>
Date: Wed, 16 May 2001 09:14:46 +0800

I'm newcomer of DiffServ, if any question followed has been
asked before accept my apology please.

As it states that DiffServ asks edge router to  lable and police the
traffic, the criterion of admission control and traffic shaping
/policing  is mainly based on SLA negotiated( ?).

But, how can such a CAC  method reflect the requirement of traffic
engineering
inside the transient  network cloud?  To my opition, if the routing
procedure still
relies on  SPF method,  it is not possible to avoid congestion on some
nodes.

Is there any work done on this subject ?

Thanks a lot.

James Shen

_______________________________________________
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: "Brenda Zhuang" <[email-masked]>
Date: Wed, 16 May 2001 10:39:20 +0800

Dear James,

I think the edge router, or called boundary node, conditioned the traffic based on TCA which 
is the agreement specifying the rules and profiles necessary for admission control as 
you stated.  This is done for the purpose of conforming the traffic to appropriate condition.
Thus, we don't need SPF but the architecture of DiffServ. :)
You may refer to RFC 2475 for some explanation.

I myself is also a newbie of DiffServ. Hope I did help to clarify the point. :)

Best,

Brenda

Zhuang Shixin, Brenda
Electrical & Electronics Engineering Department
Hong Kong University of Science & Technology
Kowloon, Hong Kong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of shen jing
Sent: 2001年5月16日 9:15
To: [email-masked]
Subject: [Diffserv] DiffServ & CAC

Thanks a lot.

James Shen

---

From: Nguyen Thi Mai Trang <[email-masked]>
Date: Wed, 16 May 2001 12:38:04 +0200

Hi all,

I have a question about the qosRandomDropEntry in diffserv-pib-03 :

There are two units for the threshold of queues : [packet] and [byte]. For exemple, there
are two attributes qosRandomDropMinThreshBytes and qosRandomDropMinThreshPkts. Can these two
units be used at the same time? If I install an instance of qosRandomDropEntry with
MinThreshBytes = 1280000 and qosRandomDropMinThreshPkts = 100, the PEP will use which value
to measure the queue or it will return an error ?

Thanks a lot.

Mai Trang

---

From: Hermann DE MEER <[email-masked]>
Date: Wed, 16 May 2001 11:43:24 +0100

James,

> relies on  SPF method,  it is not possible to avoid congestion on some

I would in principle agree on the issue you are raising.

we have a paper on that at 9th IEEE IWQoS 2001, June 6--8, Karlsruhe, Germany.

the paper iwqos01.pdf, entitled "Segmented Adaptation of Traffic Aggregates"
can be down loaded from:

ftp://cs.ucl.ac.uk/mice/hermann

Please feel free to comment as the topic seems to call for further study.

cheers,
Hermann

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 16 May 2001 09:20:24 -0400

Mai Trang:
PEPs normally support either Bytes or Packets queue measurements.
The PEP needs to indicate which one it will support.
In the next PIB revision, we will add an attribute to the
qosIfAlgDropCapsEntry to indicate which queue measurement the PEP
supports.
Thank you very much for pointing this out!
-- Kwok --

At 12:38 PM 5/16/01 +0200, Nguyen Thi Mai Trang wrote:
>are two attributes qosRandomDropMinThreshBytes and
qosRandomDropMinThreshPkts. Can these two
>Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 May 2001 10:23:50 -0500

It is assumed that the diffserv ingress routers will not admit
more traffic to a given traffic aggregate than it can handle; there is some 
discussion of this in RFC 3086 in addition to the general discussion in 
RFC 2475. The diffserv architecture is *intentionally* agnostic on how the
network is provisioned and on how its traffic engineering is performed.
That is a separate problem from the low-level mechanisms standardised by
diffserv, and it is not a problem that this working group is chartered to
solve. See RFC 2990 for general discussion.

Regards
   Brian Carpenter
   diffserv co-chair

---

From: Giuseppe Bianchi <[email-masked]>
Date: Thu, 17 May 2001 18:53:31 +0200 (MET DST)

> solve. See RFC 2990 for general discussion.

Dear Brian, 

I fully agree with you that the diffserv architecture should not be 
involved in topics such as how its traffic engineering is performed.
However, I have the feeling that this does not *automatically* imply
that admission control (and more in general resource management) is 
a completely separate topic from low level mechanisms.

Let me try to argument. Typically, admission control is managed at a
different level from packet forwarding, e.g. via explicit signalling.
However, explicit signalling is not the only way to support a per-flow
admission control function. Some proposals have recently come out, which
base admission control on packet differentiation and "implicit"
signalling. Here the term "implicit" stems from the fact that packets
dedicated to signalling are not actually parsed within each router, which
delivers them as normal packets, i.e. via low level forwarding mechanisms.
Instead, the information extracted from their forwarding within the
network (e.g. their loss in the network) can be used at the network edge
to determine whether a call may be admitted (It is quite interesting to
note that the underlying philosopy closely resembles that of TCP
congestion control, although the control function - i.e. admission control
- is quite different).

For technical details and discussion, the interested reader may refer to 
our own proposal, 

http://www.ietf.org/internet-drafts/draft-bianchi-blefari-admcontr-over-af-phb-00.txt

where we have detailed the above approach within the context of Diffserv.  
More specifically, we have argued that per-flow admission control can be
supported on top of the diffserv framework, and based on
diffserv-compatible low level mechanisms (specifically, on a suitable
configuration of the AF PHB dropping operation).

Implicit signalling can also play a crucial role in the quantitative
definition of PDBs: an homogeneous configuration, within a given domain,
of the low level queueing/dropping mechanisms devised to handle
"signalling" packets may provide a consistent traffic control
specification for the considered domain (e.g. in terms of link
utilization). Note that this does not imply that the diffserv architecture
needs to be involved in traffic engineering. Rather, the diffserv
framework appears to provide (surprisingly?) the core mechanisms that
allow each domain operation to independently engineer its service
provisioning.

Based on the above arguments, I feel that implicit signaling (i.e. based
on low level mechanisms configurable within a router) might be an
inportant (and related) topic for discussion in the DiffServ WG. I would
sincerely appreciate positive/negative feedbacks!

With best regards,

Giuseppe

---
Giuseppe Bianchi
[email-masked]
http://cerbero.elet.polimi.it/people/bianchi