Subject: RE: [Diffserv] DiffServ & CAC

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 25 May 2001 16:39:07 +0200

Hi Giuseppe,

First of all, I agree that there is a need to extending Diffserv with new mechanisms for admission control and resource management. But, I believe that these mechanisms should initially solve a single domain edge-to-edge resource management as we have named it in our draft "Resource Management in Diffserv (RMD) Framework". This kind of approach would be beneficial looking from the service providers perspective and would also be in line with diffserv WG charter, i.e. no mention of end-to-end services. This in any case does not undermine the importance of end to end signalling mechanisms but also much more difficult to implement...Whether these signalling mechanisms need to be explicit or implicit is something that needs to be discussed a lot more I think. 
I've read your draft, your approach is quite interesting and maybe these questions are going to be trivial but I am trying to understand it a bit better :)... 
1. You are using AF PHB and its drop priorities for the purpose of implicit signalling and the way I understood it is that an AF class x is the one requiring the admission control procedure, where AFx1 is for the flows that have already successfully passed the procedure and AFx2 is for the signalling packets. Once a signalling packet AFx2 is received by a destination, a packet with AFx1 set is to be sent back to the source as a feedback on the correct admission, which when receiving this message will generate the flows marked with AFx1. In the process can it happen that the low level mechanisms in the router can remark or drop these packets due to e.g. unavailability of the resources or are they at all times forwarded into FIFO queue? 
2. Since your approach is measurement-based are you assuming that there will be some sort of admission control threshold value configured say for the AFx1 class depending on the link capacity? And if so is this value going to be statistically or dynamically configured?

Best Regards,
Vlora

|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-admco
|ntr-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
|
|
|
|
|_______________________________________________
|diffserv mailing list
[email-masked]
|http://www1.ietf.org/mailman/listinfo/diffserv
|Archive: 
|http://www2.ietf.org/mail-archive/working-|groups/diffserv/curre
|nt/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: Giuseppe Bianchi <[email-masked]>
Date: Mon, 28 May 2001 17:08:40 +0200 (MET DST)

Dear Vlora,

Besides the few technical details presented in the draft, our goal 
was to put into light that DiffServ, as it is now, MIGHT support 
per-flow admission control. The reason why I have posted my message 
in the DS mailing list is that our approach appears perfectly 
compatible with both the DS framework and the DS philosopy. So, 
I'm definitely surprised that no discussion has been followed up
after my email....

Anyway, to better clarify our ideas, I'd like to summarize our 
rationale in the following steps. More detailed answers to your 
questions follow later.

1) our starting question was: it is possible to ovelay, over the 
actual DS framework, a mechanism to support admission control (albeit 
with a possibly loose form of traffic control versus the strict 
guarantees of stateful approaches) without requiring any change 
in the DS philosophy? 

In particular, we wanted to avoid, within every domain, any 
standardized point of decision for admission control issues, 
e.g., bandwidth brokers. The rationale is that BB-like proposals 
need to explicitly address the issue of how CAC queries are 
structured, and how the response is notified to the network 
endpoints.

2) In such a scenario, we argue that the knowledge of the degree of
congestion in the network links is LOCALIZED within each router, and 
that there exist well understood packet level mechanisms (e.g.
measurement-based) to suitably estimate such a congestion status. In 
essence, IF a mechanism that allows each router to notify its 
congestion status (to whom it may concern... in our case the endpoints)
is adopted, there is no need to elect a special domain node to be in 
charge of controlling the resource management within the specific 
domain.
 
3) Our goal is now to envision a mechanism to notify congestion,
in the mean time avoiding ANY modification to the actual DS 
framework. Thus, we do not rely on packet marking (which definitely 
might be an efficient and excellent approach, as recent literature 
shows - Kelly et al, JSAC, Dec. 2000), since a marking standard 
across the entire network would be needed, in this case.

4) Instead, packet dropping may be a possible solution to convey 
information to the end points. This because:
a) droppers are already envisioned in the AF PHB, and may be 
tuned in full conformance with RFC 2597.
b) packet dropping is an information that necessarily reaches 
the network end points :-), and crosses the boundaries of a domain
without the need to adhere to any standard.
c) packet dropping is semantically equivalent to a 1 bit congestion 
notification information, and is an information well used in standard 
Internet mechanisms (e.g., TCP congestion control).

5) Our proposed approach is not aimed to provide a pre-determined 
degree of QoS support, but leaves every administrative domain in 
charge of tuning the degree of provisioning. Moreover, it is clearly
not necessary that all domains support admission control: if 
a flow crosses two domains where one supports CAC and the other 
doesn't, performance will be guaranteed only in the first domain (to 
the extents of the service provisioning - and related parameter tuning
- done by the first domain administrator), but not end to end, as the 
second domain may become congested (for example, in the second domain,
QoS performance would not be guaranteed if a "standard" RIO 
implementation of AF is adopted).

This last example allows some additional comments. The endpoint AC
logic we push can be deployed even if some DS domains remain unaware
of it. Th fact that these domains are not capable to achieve the
performance advantages deriving from the endpoint AC operation does 
not affect the endpoint logic, but only affects the performance of 
flows that cross the domain. Conversely, the DS domains that introduce
support for endpoint AC, e.g. via our proposed AF PHB management, 
guarantee edge to edge provisioning. Therefore, the end to end degree 
of QoS support is bottlenecked by the worst case support found in 
one of the crossed domains.

6) Finally, the fact that our proposal adopts AF is incidental, and 
unrelated to the traditional view of AF as a PHB devised to support
better than best effort services! The reason is simply due to the 
fact that the AF PHB is the only PHB that handles different packet
marking withn the same class. 

With best regards,

Giuseppe.

PS: Answers to your detailed questions (thanks for your Q!) 
follow.

> First of all, I agree that there is a need to extending Diffserv with
> new mechanisms for admission control and resource management. But, I
> believe that these mechanisms should initially solve a single domain
> edge-to-edge resource management as we have named it in our draft
> "Resource Management in Diffserv (RMD) Framework". This kind of
> approach would be beneficial looking from the service providers
> perspective and would also be in line with diffserv WG charter, i.e.
> no mention of end-to-end services. This in any case does not undermine
> the importance of end to end signalling mechanisms but also much more
> difficult to implement...Whether these signalling mechanisms need to
> be explicit or implicit is something that needs to be discussed a lot
> more I think.

> I've read your draft, your approach is quite interesting and maybe
> these questions are going to be trivial but I am trying to understand
> it a bit better :)...

> 1. You are using AF PHB and its drop priorities for the purpose of
> implicit signalling and the way I understood it is that an AF class x
> is the one requiring the admission control procedure, where AFx1 is
> for the flows that have already successfully passed the procedure and
> AFx2 is for the signalling packets. Once a signalling packet AFx2 is
> received by a destination, a packet with AFx1 set is to be sent back
> to the source as a feedback on the correct admission, which when
> receiving this message will generate the flows marked with AFx1. In
> the process can it happen that the low level mechanisms in the router
> can remark or drop these packets due to e.g. unavailability of the
> resources or are they at all times forwarded into FIFO queue?

Dropping of AFx2 packets are part of the mechanism, and are 
interpreted at the end points as incapability of the network 
to accept the flow as AFx1 (this means that the flow can be 
either rejected, or transmitted as best effort). 

Unexpected remarking should not create problems, unless AFx2 packets 
are remarked AFx1. 

Remarking of AF packets exiting from a CAC-aware domain A into best 
effort packets entering a CAC-unaware domain B breaks the possibility 
to use endpoint AC in domain A for flows that cross domain B, but 
still allows QoS provisioning for flows that do not cross domain B.

> 2. Since your approach is measurement-based are you assuming that
> there will be some sort of admission control threshold value
> configured say for the AFx1 class depending on the link capacity? And
> if so is this value going to be statistically or dynamically
> configured?

This is a tunable value (or values, if a range of thresholds with 
RED-like operation is implemented), that can be either configured 
statically by the domain administrator, or dynamically by traffic 
estimates. In the latter case the rationale is that, having in mind 
a given QoS target (e.g. 99th prcentile delay for accepted traffic),
this threshold depends not only on the link capacity, but also 
on the traffic correlation characteristics. While a high throughput 
can be achieved with voice-like sources, highly correlated sources
require a much lower utilization to provide the same delay 
performance.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 May 2001 10:43:13 -0500

Clearly a viable diffserv deployment requires admission control;
otherwise the traffic aggregates are exposed to overload, which is
not allowed for some PHBs. However, it's a separate question from
the basic diffserv mechanisms and therefore not in this WG's charter.

I do object to using the term CAC however. Admission control doesn't
have to be applied to flows or calls; it can perfectly well be applied
to all traffic passing a given MF classifier. Flow-based admission
control is a special case and not at all required in an IP network.
If you want flow-based admission control, I think RFC 2998 is already
a solution for the necessary protocol.

   Brian

---

From: demir <[email-masked]>
Date: Tue, 29 May 2001 15:56:48 -0700 (PDT)

> a solution for the necessary protocol.

I think this depends on how one defines a "connection"/"call" 
(traditionally, it has been used for micro-flows). I agree with that it
can be applied to all traffic passing a given any classifier (how about
TAC-traffic admission control?). I think RFC 2998 is a model for
Intserv-oriented quantitative QoS based on existing Intserv-related
protocols. 

Alper K. Demir