Working Group: G. Bianchi Internet Draft University of Palermo, Italy N. Blefari-Melazzi Document: University of draft-bianchi-blefari-admcontr-over-af-phb-00.txt Perugia, Italy Category: Informational March 2000 Per Flow Admission Control over AF PHB Classes Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This memo shows that an AF PHB class, as defined in RFC 2597, is capable of supporting explicit per flow admission control. Admission control is obtained by a suitable use of two out of the three drop precedence levels. Level 1 is dedicated to conforming accepted traffic, i.e. traffic that has passed admission control test and conforms to edge-policing functions. Level 2 is used as an implicit signaling pipe and acts as the core network support for the admission control procedure. Table of Contents 2. Introduction ................................................. 2 3. Related work ................................................. 2 4. AF PHB class management and implicit signaling ............... 3 5. End Point Admission Control operation ........................ 5 6. Appendix A: Possible roles of the AFx3 level ................. 6 7. Appendix B: Arguments for new PHB definitions? ............... 7 8. Appendix C: Performance issues ............................... 7 9. Appendix D: Security considerations .......................... 8 10. References .................................................. 9 11. Author's Address ........................................... 10 12. Full Copyright Statement ................................... 10 Bianchi&Blefari Informational - Expires September 2001 1 Per Flow Admission Control over AF PHB groups March 2001 2. Introduction There is a growing feeling [RFC2990, RFC2998] that the basic DiffServ architectural model [RFC2474, RFC2475] lacks the capability of providing service accuracy. Quoting [RFC2990] Œboth the Integrated Services architecture and the Differentiated Services architecture have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment... There appears to be no single comprehensive service environment that possesses both service accuracy and scaling propertiesŽ. Also, in [RFC2998], it is pointed out that Œfurther refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model with the associated task of resource reservationŽ. To this purpose, [RFC2990] recommends to define an Œadmission control function which can determine whether to admit a service differentiated flow along the nominated network pathŽ. In fact, without per flow admission control, prevention of overload in a given service class, e.g. by means of pure inter-domain service level agreements, does not appear to be an easy task. Upon overload in a given service class, all flows in that class suffer a potentially harsh degradation of service. The Assured Forwarding Per Hop Behavior (AF PHB, [RFC2597]) has been devised to provide different levels of forwarding assurances. The example services presented in the appendix of [RFC2597] show that the primary intent of AF is to promote packet loss differentiation, either among different traffic classes, e.g., marked with different drop levels, as well as within the same traffic class, e.g. marking traffic conforming to a policy specification with a lower drop level than non conforming traffic. While low loss and low latency traffic support, such as that achievable with a strict admission control function, appears to be out of the scopes of the AF model, the class-based structure of the AF PHB has intrinsic (unforeseen?) capabilities to support per flow admission control. Our key idea (originally proposed - although not specifically envisioned over an AF PHB class - in [BBM01], under the name GRIP - Gauge&Gate Reservation with Independent Probing) is to rely the decision to admit a new connection upon the successful delivery of probes, tagged with a higher AF drop level mark than accepted traffic, independently generated by end points during each flow setup phase. It is quite interesting to remark that the idea of pushing traffic control to the edge and basing the connection request acceptance/refusal on packet loss detection is close to what TCP congestion control technique does, but it is used in the novel context of admission control. 3. Related work Several literature proposals describe a promising novel framework for admission control, generally referred to as Endpoint Admission Control (EAC - see [BKS00] and references therein contained). In Bianchi&Blefari Informational - Expires Jul 2001 2 Per Flow Admission Control over AF PHB groups March 2001 EAC, the explicit decisions whether to accept or refuse a connection request are taken by edge devices, rather than by devices within the network (e.g. core routers or bandwidth brokers). The driving idea of EAC schemes is to convey the congestion status of network nodes to the end-points, either in an implicit manner (i.e. by means of endpoint traffic measurements [BOR99, ELE00]), or explicitly (e.g. by requiring that network devices mark packets in a way that is load dependent [KEL00]). Both approaches have their pitfalls. Endpoint measurements appear unreliable when performed over the very short time frame given by the flow setup time. Explicit congestion notification mechanisms, instead, require to actively involving core routers in the process of marking packets, an activity that appears contrary to the spirit of DiffServ. Moreover, to be effective, such solutions need to be supported by all DiffServ routers at once, and a uniform marking protocol needs to be specified, e.g. by identifying a set of bits (one or more) in the IP packet header. An apparently un-related issue is how to perform admission control in a core router. We argue that this problem does not stay in the fact that the network has to be oblivious of individual flows. In fact recent literature has shown that admission control schemes driven by load measurements are extremely robust and efficient [GRO99, BJS00]. These schemes do not base the accept/reject decision on per-flow state information and related traffic specifications. Instead, they operate on the basis of per-node aggregate traffic measurements carried out at the packet level. The robustness of these schemes stays in the fact that, in suitable conditions (e.g. flow peak rates small with respect to link capacities), they are barely sensitive to uncertainties on traffic profile parameters. As a consequence, it seems that scalable decisions can be independently taken by the routers. Our aim is to integrate the effectiveness of measurement-based approaches with the simplicity of EAC. In other words, we want to implicitly convey the status of core routers (evaluated by means of aggregate measurements) to the end points so that the latter devices can take learned admission control decisions. The main open issue is then how to define and handle the signaling information needed to exchange information between end-points and core routers, without relying on explicit signaling and thus violating the DiffServ paradigm. 4. AF PHB class management and implicit signaling Four AF PHB classes have been standardized, each composed of three drop levels. In what follows, we will use the notation AFxj to indicate packet marks belonging to the AF class x, with drop level j. Conforming to [RFC2597], within a class x, if i| measurement |----| | | module | | input | |--------------| | |-----------| output ----->| || |->|FIFO queue |-------> | \/ | |-----------| |AFx2 |--------------| | |----->| AFx2 dropper |----| |--------------| Figure 1: logical handling of an AF class x A measurement module is devised to run-time measure the aggregate AFx1 traffic. The measurement module depicted in the figure does not interact with the AFx1 packets forwarding, i.e., these packets are forwarded to the FIFO buffer placed at the output regardless of the measurements taken. On the basis of such measurements, this module triggers a suitable dropping algorithm on the AFX2 traffic. With respect to the general AF PHB operation, we are restricting the AFX2 dropping algorithm to depend only on AFX1 traffic measurements. The simplest dropping algorithm is represented by a ŒgateŽ (smoother dropping algorithms for AFx2 packets - e.g. RED-like algorithms - may be considered to improve stability). When the measurement module does not detect congestion on the AFx1 traffic, being the notion of congestion implementation-dependent, it keeps the gate opened (we call this ŒACCEPTŽ state). When the gate is open no AFx2 packet is dropped. Conversely, the measurement module keeps the gate closed (ŒREJECTŽ state) when congestion is detected, i.e. it enforces a 100% drop probability over AFx2 packets. Note that this operation does not violate the AF drop level relationship, as AFx1 dropping probability is lower than the AFx2 one. While the above description is simply a particular implementation of an AF class, we now show its interpretation in terms of implicit signaling, which has important consequences for the definition of an overlay admission control function. In fact, let us assume that: i) the considered AF class x, is devoted to the support of QoS aware flows, requiring an admission control procedure; ii) traffic labeled AFx1 is generated by flows which have already passed an admission control test, iii) AFx2 packets are ŒsignalingŽ packets injected in the network by flows during the setup phase (in principle, one AFx2 packet per flow). Bianchi&Blefari Informational - Expires Jul 2001 4 Per Flow Admission Control over AF PHB groups March 2001 According to the described operation, an AFx2 packet is delivered to its destination ONLY IF it encounters all the routers along the path in the ACCEPT state. This operation provides an implicit binary signaling pipe, semantically equivalent to a one-bit explicit congestion notification scheme. 5. End Point Admission Control operation The above interpretation of the AF PHB allows deploying an admission control function, whose operation is concentrated in the flow end points, and which does not relies on state management and explicit signaling exchange in DiffServ network routers (both core routers within a DS domain and border routers among different DS domains). The admission control function is triggered by explicit signaling exchanges between the source terminal (SRC in figure 2) and the access router (ARin) to the local DS domain. Assume that a one way connection is offered from user terminal SRC to user terminal DST, in principle belonging to different DS domains (see figure 2). Upon setup request, the ARin node starts a connection setup attempt by sending, in principle, just one packet labeled AFx2 through the network. In the same time, a probing phase timeout is started. --------- --------- --------- / \ / \ / \ |---| |----| |---| |---| |-----| |---| |SRC|--|ARin|---DS1---|BR1|---DS2---|BR2|---DS3---|ARout|--|DST| |---| |----| |---| |---| |-----| |---| \ / \ / \ / --------- --------- --------- Figure 2: Sample Network Configuration We recall that, when an AFx2 packet reaches the destination, it implicitly conveys the information that all routers encountered across the path have been locally declared themselves in the ACCEPT state, i.e. capable of admitting new flows without QoS degradation. It is up to each specific router/domain to quantitatively determine its QoS target, and link this QoS target to the runtime measurements carried on the AFx1 traffic (see Appendix C for further discussion). If the AFx2 packet eventually reaches the ARout destination node, an explicit signaling is executed between the Arout and the DST node to verify that the DST terminal is capable (and willing) of accepting the call. We remark that a by-product of this operation is to allow a receiver capability negotiation function procedure, which is deemed necessary in [RFC2990]. Once this test is performed with successful response, the ARout router replies with a feedback packet, labeled AFx1. The choice of the AFx1 mark to transmit the feedback packet is motivated by the fact that, for one way flows, it is not necessary to test the reverse path (from DST to SRC), and thus the AFx1 tag provides better guarantees that the feedback packet is correctly received at Bianchi&Blefari Informational - Expires Jul 2001 5 Per Flow Admission Control over AF PHB groups March 2001 the SRC. Indeed, when full duplex flows are considered, the feedback packet shall be tagged as AFx2, since in this case reverse path testing is also necessary. The decision whether to admit or reject the incoming call is driven by the eventual reception of the feedback. When a feedback packet is received in response, the source node labels the flow as accepted, and starts transmitting packets marked as AFx1. Conversely, by not receiving a feedback packet within the probing phase timeout, the source node is made able to implicitly determine that at least one router along the path has declared itself not capable of accommodating additional flows, and thus the source node can abort the flow setup attempt (or reiterate the setup attempt according to some suitable backoff mechanism). 6. Appendix A: Possible roles of the AFx3 level In the above description, the AFx3 drop level appears in principle unnecessary. However, it may be convenient to use this level. A first possibility is that the AFx3 level be used to mark non- conforming packets, which can be eventually delivered if network resources are available. Second, AFx3 packet marking can be enforced over flows that have not successfully passed the described admission control test. This allows deploying a service model where high QoS is provided to flows that pass the admission control test, while best effort delivery is provided to initially-rejected flows. These latter flows may occasionally retry the setup procedure, by simply marking occasional packets as AFx2 (e.g. by adhering to a suitable backoff procedure), and may eventually receive the upgraded AFx1 marking when network resources become available (as testified by the eventual reception of an AFx1 feedback). The usage of the AFx3 level as described above is targeted to increase the link utilization. However, [RFC2597] requires the drop probability for AFx3 to be greater (or at most equal) than AFx2. This implies that the link utilization is bounded by the possibly strict mechanism that triggers AFx2 packets dropping: when AFx2 packets receive a 100% dropping probability, all AFx3 packets must also be dropped to conform to the [RFC2597] specification. A more effective mechanism would consist in implementing a dropping algorithm for the AFx3 traffic not directly related to the AFx2 drop algorithm. However, this usage of the AFx3 level does not conform with the AF specification, since the AFx3 dropping probability may be eventually lower than AFx2. A more interesting possible usage of the AFx3 level consists in providing a second control (probing) channel in addition to AFx2. According to this solution, AFx1 traffic measurements trigger a dropping algorithm on the AFx3 traffic, with stricter dropping conditions than the AFx2 dropping algorithm (i.e. AFx3 packets are assumed to detect congestion, and notify it via packet drop, before AFx2 packets). This AFx3 probing class could request admission for flows with e.g., higher peak rate and bandwidth requirements than flows supported via the AFx2 probing class (i.e., we are adding a Bianchi&Blefari Informational - Expires Jul 2001 6 Per Flow Admission Control over AF PHB groups March 2001 second implicit signaling pipe). Also, being the AFx3 channel more reactive to congestion conditions, its usage can be envisioned to provide lower access priority to network resources. This would improve fairness and avoid some kinds of sources to ŒstealŽ a large part of network resources. 7. Appendix B: Arguments for new PHB definitions? Although this memo leaves untouched the basic AF PHB semantic, we feel that our suggested usage of AF is different (and quite unexpected) from what intended in RFC 2597. The services that are expected to make use of admission control are RTP/UDP streams with delay and loss performance requirements, whose support is currently envisioned by means of the EF PHB. On the contrary, AF appears designed to provide better than best effort support for generic TCP/UDP traffic. Thus, our study raises the case for the transformation of the (single) EF PHB into a PHB class (i.e. by adding an associated, "paired", probing pipe with a different DSCP). An alternative is defining new "paired" PHBs. On a different prospective, paired PHBs can be envisioned to support more general control functions than admission control. For example, the TCP fast retransmission and recovery algorithm might take advantage of isolated data packets labeled as ŒcontrolŽ, and thus expected to encounter loss if (controlled) congestion is encountered in the network. 8. Appendix C: Performance issues The described admission control semantic provides a reference framework compatible with "current" AF implementations, although poor performance are most likely provided over RED-like queueing management mechanisms. An explicit traffic measurement module implementation appears thus necessary. Quantitative and tunable performance may be independently provided and specified by each administrative entity. Uniform implementation across a specific domain allows defining a quantitative view (e.g., a PDB) of the performance achievable within the considered domain. In this way, the refinements deemed necessary in [RFC2990] to provide service accuracy in the DiffServ architectural model can be considered as accomplished. In fact, the performance achievable by the described end point admission control operation depends on the notion of congestion as the triggering mechanism for AFx2 packet discarding, which is left to each specific implementation. Each administrative entity may arbitrarily tune the optimal throughput-delay/loss operational point supported by its routers, by simply determining the aggregate AFx1 traffic target supported in each router. The mapping of AFx1 throughput onto loss/delay performance in turns depends on the link capacities and on the traffic flow characteristics offered on the AFx class. Bianchi&Blefari Informational - Expires Jul 2001 7 Per Flow Admission Control over AF PHB groups March 2001 With this approach, it is possible to construct PDBs offering quantitative guarantees. A building block of such PDBs is the definition of specific measurement modules and AFX2 dropping algorithms. A generic dropping algorithm is based on suitable rules (or decision criteria). An example of a trivial decision criterion is to accept all AFx2 packets when the measured throughput is lower than a given threshold and reject all AFx2 packets when the AFx1 measurements overflow this threshold. The resulting delay performance depends upon the link capacity and the traffic model. For instance, with 32 Kbps peak rate Brady on-off voice calls offered to a 2 Mbps (20 Mbps) link, a target link utilization of 75% (92%) leads to a 99th percentile per hop delay lower than 5ms - see figure 4 in [BCP00]. Tighter forms of traffic control are possible. As a second example of a decision criterion, we demonstrated that hard (loss and/or delay) QoS guarantees can be provided, under suitable assumptions on the offered traffic (i.e., traffic sources regulated by standard Dual Leaky Buckets, as in the IntServ framework) and with ad hoc defined measurement modules in the routers [BBM01]. Finally, we note that the AFX2 dropping algorithm must not be necessarily driven by traffic measurements. In fact, it can be driven by lower layers QoS capabilities, (e.g., ATM). 9. Appendix D: Security considerations As all admission control functions, our solution presents the risk of theft of resources through the unauthorized admission of traffic. Although, logically, user terminals are the natural nodes where the endpoint admission control should operate, this is clearly not realistic, for the obvious reason that the user may bypass the admission control test and directly send AFx1 packets. Identity authentication and integrity protection are therefore needed in order to mitigate this potential for theft of resources [RFC2990]. Administrators are then expected to protect network resources by configuring secure policers at interfaces (e.g. access routers) with untrusted customers. Similar protections must be provided at the interface between different domains. In particular, it may be necessary to restrict the access to the AF class(es) used for admission controlled traffic. For example, a DS domain should re- mark AF packets when they come from an un-trusted adjacent DS domain. In more generality, we remark that policing and conditioning rules enforced at the border routers of each domain depend on the usage of the considered AF PHB class within the specific domain and thus have to be accounted of in the definition of each specific PDB supporting admission control. A quite obvious security hazard is flooding the network with AFx2 packets. The objective is twofold. On one side, denial of service situations can be easily created, as a massive loading of the network with AFx2 packets prevent the setup of normal connection. On the other side, the goal might be to affect fairness: the continuous Bianchi&Blefari Informational - Expires Jul 2001 8 Per Flow Admission Control over AF PHB groups March 2001 transmission of AFx2 packets at a rate higher than normal connection requests is a mean to gain faster access to resources when these are made available by a router along the path. This implies that some form of traffic conditioning and policing is necessary over AFx2 streams. While it is simple to recognize an hard attack, by monitoring the AFx2 packets crossing an edge router (the AFx2 traffic ± at most a few packets per originating connection - is minimal in normal conditions, and thus sudden increments of the AFx2 load are suspicious), it may be not straightforward for DS boundary routers to recognize smoother fairness attacks. However, note that the same fairness problem is present also in more complex reservation mechanisms, such as RSVP (malicious users can continuously require setup to increase their access possibility with respect to normal users). Finally, all the security considerations expressed in [RFC2990] apply also to our solution. 10. References [BBM01] G. Bianchi, N. Blefari-Melazzi: " A Migration Path for the Internet: from Best-Effort to a QoS Capable Infrastructure by means of Localized Admission Control", Lecture Notes on Computer Science, Springer-Verlag, volume 1989, January 2001. This paper and a more detailed technical report can be requested to the authors, by writing to blefari@diei.unipg.it. [BCP00] G. Bianchi, A. Capone, C. Petrioli, ŒPacket Management Techniques for Measurement Based End-to-end Admission ControlŽ, KICS/IEEE Journal on Communications and Networking, June 2000. [BJS00] L. Breslau, S. Jamin, S. Schenker: "Comments on the performance of measurement-based admission control algorithms", IEEE Infocom 2000, Tel-Aviv, March 2000. [BKS00] L. Breslau, E. W. Knightly, S. Schenker, I. Stoica, H. Zhang: "Endpoint Admission Control: Architectural Issues and Performance", ACM SIGCOMM 2000, Stockholm, Sweden, August 2000. [BOR99] F. Borgonovo, A. Capone, L. Fratta, M. Marchese, C. Petrioli, "PCP: A Bandwidth Guaranteed Transport Service for IP networks", IEEE ICC'99, June 1999. [ELE00] V. Elek, G. Karlsson, "Admission Control Based on End-to-End Measurements", Proc. of IEEE Infocom 2000, Tel Aviv, Israel, March 2000. [GRO99] M. Grossglauser, D. N. C. Tse: "A Framework for Robust Measurement Based Admission ControlŽ, IEEE/ACM Transactions on Networking, Vol. 7, No. 3, June 1999. [KEL00] F. P. Kelly, P. B. Key, S. Zachary: " Distributed Admission Control", IEEE JSAC, Vol. 18, No. 12, December 2000. Bianchi&Blefari Informational - Expires Jul 2001 9 Per Flow Admission Control over AF PHB groups March 2001 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definitions of the Differentiated Service Field (DS Field) in the Ipv4 and Ipv6 Headers", RFC2474, December 1998. [RFC2475] S. Blade, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998. [RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, ŒAssured Forwarding PHB GroupŽ, RFC 2597, June 1999. [RFC2990] G. Huston, "Next Steps for the IP QoS Architecture", RFC2990, November 2000. [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000. 11. Author's Addresses Giuseppe Bianchi DIE, University of Palermo Viale delle Scienze, Parco d'Orleans 90128 Palermo, ITALY Tel: +39 091 6566 276 E-mail: bianchi@elet.polimi.it Nicola Blefari-Melazzi DIEI, University of Perugia Via G. Duranti 93, 06125 Perugia, ITALY Tel: +39 075 585 3630 e-mail: blefari@diei.unipg.it 12. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Bianchi&Blefari Informational - Expires Jul 2001 10