Stateful vs. Stateless Admission Control: which can be the gap in utilization efficiency? N. Blefari-Melazzi, M. Femminella D.I.E.I. Department, Via G. Duranti 93, 06125 Perugia  Italy Ph. +39 075 585 3630, e-mail: {blefari, femminella}@diei.unipg.it AbstractIETF developed two main approaches to provide QoS aware services in the Internet: Integrated Services (IntServ) and Differentiated Services (DiffServ). Both have well known pros and cons (e.g., [1][2]). The stateful IntServ has a greater level of accuracy and a finer level of granularity. The stateless DiffServ possesses excellent scaling properties, but lacks a standardized admission control scheme and, upon overload in a given service class, degradation of service can occur. To provide QoS in DiffServ, three possible strategies are: i) plain and heavy over-dimensioning; ii) admission control at the borders of the DiffServ region, coupled with suitable assumptions on the distribution of the traffic within the region, which can lead to over-dimensioning, even if less severe than the previous one; iii) per-node (i.e., within the region) admission control. Following RFC2990, we recently proposed an "admission control function which can determine whether to admit a service differentiated flow along the nominated network path [1]", i.e., the third of the above strategies. This function, named GRIP (Gauge & Gate Reservation with Independent Probing), can provide strict QoS guarantees by means of stateless DiffServ-compliant procedures. This feature is paid with a potential loss of efficiency, with respect to an ideal, stateful admission control. The goal of this paper is to evaluate analytically such loss of efficiency, in a specific scenario. In other words, we want to estimate how much resources we can waste if we go stateless and avoid state maintenance functions. The comparison between stateless and stateful approaches is performed under the constraint of strictly offering the same performance levels, in terms of, e.g., loss probability and delay. I. INTRODUCTION The IntServ QoS framework can provide strict QoS guarantees, due to its stateful approach. On the other side, the DiffServ paradigm is stateless and can offer different treatments to different traffic classes, without QoS guarantees within each class. In fact, the DiffServ way of operation, by itself, does not intrinsically solve the problem of controlling congestion. Upon overload in a given service class, all flows in that class may suffer a degradation of service. To guarantee pre-defined levels of performance to single flows it is necessary to deploy an admission control function, in a DiffServ domain, to admit or reject flow setup requests. Following this line of reasoning, we recently proposed an admission control scheme, named GRIP (Gauge & Gate Reservation with Independent Probing), which provides strict QoS guarantees by means of stateless DiffServ-compliant procedures. GRIP is described in details in [3][4] and further elaborated in [5]; here we give only the basic concepts of GRIP, to ease the readers effort. GRIP combines an admission control operation, driven by end-points, with run-time traffic measurements, performed within each router to detect congestion. Thus, GRIP is completely described by two logical components: i) GRIP end-nodes operation, and ii) GRIP router operation. GRIPs end nodes operation is extremely simple. When a user terminal requests a connection with a destination terminal, the source node transmits a probing packet. Meanwhile, the source node activates a probing phase timeout, lasting for a reasonable time. If no response is received from the destination node before the timeout expiration, the source node enforces rejection of the connection setup attempt. Otherwise, if a feedback packet is received in time, the connection is accepted, and control is given back to the user application, which starts a data phase, simply consisting in the transmission of information packets. In DiffServ, packets belonging to different traffic classes are tagged with different values of the DSCP field, in the IP packet header [6]. In GRIP, we assume that packets belonging to a given class are further differentiated between probing and information packets. Thus, in our view, the DSCP field codes both the class and the role of the packets. These different tags given to probing and information packets allow internal routers to apply them different forwarding behaviors and enforce probing packet dropping (and thus block the setup attempt) when congestion arises. The role of the destination node simply consists in monitoring the incoming IP packets, intercepting the ones labeled as probing, reading their source address, and, for each incoming probing packet, just relaying with the transmission of a feedback packet, if the destination is willing to accept the set-up request 1 . As regards the GRIP router operation, packets incoming to a DiffServ router output port are dispatched to suitable queues according to their DSCP tag. Several GRIP modules, devised to support different traffic classes, may co-exist within a router. Each of such GRIP modules is in charge of handling both probing packets and information packets belonging to a given traffic class. Information packets are generated by traffic sources which have already passed an admission 1 For clarity of presentation, we identified the source and destination user terminals as the network end-nodes, taking admission control decisions. However, for obvious security reasons, such end-nodes should be the ingress and egress nodes, under the control of the network operator(s). If GRIP is seen as a domain specific mechanism, then such end-nodes are suitable nodes, located at the edge of the considered domain.