idnits 2.17.1 draft-bianchi-blefari-end-to-end-qos-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 114 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2002) is 8040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Working Group: G. Bianchi 2 Internet Draft University of 3 Palermo, Italy 4 Document: N. Blefari-Melazzi 5 draft-bianchi-blefari-end-to-end-qos-02.txt University of 6 Perugia, Italy 8 Category: Informational November 2001 9 Expires April 2002 11 A Migration Path to provide End-to-End QoS over Stateless Networks by 12 Means of a Probing-driven Admission Control 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. Internet-Drafts are draft 21 documents valid for a maximum of six months and may be updated, 22 replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet-Drafts as reference material or to 24 cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1 Abstract 33 This document proposes an admission control paradigm, called GRIP 34 (Gauge&Gate Reservation with Independent Probing), devised to 35 transparently operate over DiffServ domains. GRIP relies the 36 decision to admit a new flow upon the successful and time 37 delivery, through the Internet, of probe packets independently 38 generated by the end points. The key idea is to use failed 39 receptions of probes to discover, at the end points, that a 40 congestion condition occurs in the network, and to reject the new 41 admission request. This idea is extremely close to what TCP 42 congestion control technique does, but it is used in the novel 43 context of admission control. While GRIP can be seamlessly applied 44 to DiffServ (and even legacy) Internet, a marginal increase in QoS 45 is envisioned in these existing scenarios. The performances of GRIP 46 are in fact related to the capability of routers to locally take 47 decisions about the degree of congestion in the network, and 48 suitably drop probe packets when congestion conditions are detected. 50 GRIP can be applied in a "decoupled" framework where admission 52 control is categorized as: 54 Bianchi&Blefari Informational - Expires April 2002 1 55 A Migration Path to provide End-to-End QoS over Stateless Networks by 57 Means of a Probing-driven Admission Control November 2001 59 - End-to-end, where the end points of the admission control; 61 procedure are two end hosts; 63 - Cross-domain, or inter-domain, where the end points of the 65 reservation are located in different administrative domains but 67 not on end hosts; 69 - Edge-to-edge, or intra-domain where the end points of the 71 admission control procedure are two edge nodes located in the 73 same administrative domain. 75 Finally, we are fully aware that the possible application of the 77 principles described in this draft in the Internet raises many 79 issues, which we do not address. 81 Our aim, then, is not proposing a full-fledged solution for the 83 Internet, but contributing to the on-going discussions in the 85 international arena on these matters, by means of what we may see as 87 a problem statement document. 89 Table of Contents 91 1 Abstract ...........................................................1 93 2 Introduction .......................................................2 95 3 Related work .......................................................3 97 4 A "Decoupled" Approach to Admission Control ........................5 99 5 The Concept of Implicit Signaling and its Use in Admission Control .6 101 6 Implicit Cross-Domain Signaling ...................................11 103 7 Appendix D: Security considerations ...............................14 105 8 References ........................................................15 107 9 Author's Addresses ................................................16 109 10Full Copyright Statement ..........................................17 111 2 Introduction 113 Two QoS architectures are being discussed in the Internet arena: 115 Integrated Services and Differentiated Services. Nevertheless, 117 quoting the recent RFC [RFC2990], "both the Integrated Services 119 architecture and the Differentiated Services architecture have some 121 critical elements in terms of their current definition, which appear 123 to be acting as deterrents to widespread deployment... There appears 125 to be no single comprehensive service environment that possesses 127 both service accuracy and scaling properties". Our agreement with 129 the above statement is motivated as follows. 131 The IntServ/RSVP paradigm [RFC2205, RFC2210] is devised to establish 133 reservations at each router along a new connection path, and provide 135 "hard" QoS guarantees. The common criticism to RSVP is related to 137 its complexity and lack of scalability. In the heart of large-scale 139 networks, the cost of RSVP soft state maintenance and of processing 141 and signaling overhead in the routers is significant. 143 Bianchi&Blefari Informational - Expires April 2002 2 144 A Migration Path to provide End-to-End QoS over Stateless Networks by 146 Means of a Probing-driven Admission Control November 2001 148 Moreover, we argue that complexity and scalability are not the 150 unique problem of RSVP. RSVP needs to be deployed in all the 152 involved routers, to provide end-to-end QoS guarantees; hence this 154 approach is not easily and smoothly compatible with existing 156 infrastructures. What we are trying to say is that complexity and 158 scalability are really important issues, but that backward 160 compatibility and smooth Internet upgrade in a multi-domain Internet 162 market scenario is probably even more important. 164 Following this line of reasoning, we argue that the success of the 166 DiffServ framework [RFC2474, RFC2475] does not uniquely stays in the 168 fact that it is an approach devised to overcome the scalability 170 limits of IntServ. As in the legacy Internet, the DiffServ network 172 is oblivious of individual flows. Each router merely implements a 174 suite of scheduling and buffering mechanisms, to provide different 176 aggregate service assurances to different traffic classes whose 178 packets are accordingly marked with a different value of the 180 Differentiated Services Code Point (DSCP) field in the IP packet 182 header. By leaving untouched the basic Internet principles, DiffServ 184 provides supplementary tools to further move the problem of Internet 186 traffic control up to the definition of suitable pricing/service 188 level agreements (SLAs) between peers. However, DiffServ lacks a 190 standardized admission control scheme, and does not intrinsically 192 solve the problem of controlling congestion in the Internet. Upon 194 overload in a given service class, all flows in that class suffer a 196 potentially harsh degradation of service. RFC [RFC2998] recognizes 198 this problem and points out that "further refinement of the QoS 200 architecture is required to integrate DiffServ network services into 202 an end-to-end service delivery model with the associated task of 204 resource reservation". It is thus suggested [RFC2990] to define an 206 "admission control function which can determine whether to admit a 208 service differentiated flow along the nominated network path". 210 3 Related work 212 Recent literature (see [BRE00] and references therein contained) has 214 shown that such an admission control function can possibly be 216 provided over stateless networks by means of the so-called Endpoint 218 Admission Control (EAC). EAC builds upon the idea that admission 220 control can be managed by pure end-to-end operation, involving only 222 the source and destination host. At connection set-up, each sender- 224 receiver pair starts a Probing phase whose goal is to determine 226 whether the considered connection can be admitted to the network. In 228 some EAC proposals [BOR99, ELE00, BRE00], during the Probing phase, 230 the source node sends packets that reproduce the characteristics (or 232 a subset of them) of the traffic that the source wants to emit 234 through the network. Upon reception of the first probing packet, the 236 destination host starts monitoring probing packets statistics (e.g., 238 loss ratio, probes interarrival times) for a given period of time. 240 At the end of the measurement period and on the basis of suitable 242 Bianchi&Blefari Informational - Expires April 2002 3 243 A Migration Path to provide End-to-End QoS over Stateless Networks by 245 Means of a Probing-driven Admission Control November 2001 247 criteria, the receiver takes the decision whether to admit or reject 249 the connection and notifies back this decision to the source node. 251 Although the described scheme looks elegant and promising (it is 253 scalable, it does not involve inner routers), a number of issues 255 come out when we look for QoS performance. A scheme purely based on 257 endpoint measurements suffers of performance drawbacks mostly 259 related to the necessarily limited (few hundreds of ms, for 261 reasonably bounded call setup times) measurement time spent at the 263 destination. Measurements taken over such a short time and on an 265 end-to-end basis cannot capture stationary network states, and thus 267 the decision whether to admit or reject a call is taken over a 269 snapshot of the network status, which can be quite an unrealistic 271 picture of the network congestion level. 273 The simplest solution to the above issue (other solutions are being 275 explored, but their complete discussion and understanding is way out 277 of the aims of the present paper) is to attempt to convey more 279 reliable network state information to the edge of the network. 281 Several solutions have been proposed in the literature. [CKN00] 283 proposes to drive EAC decisions from measurements performed on a 285 longer time scale among each ingress/egress pair of nodes within a 287 domain. [GKE99, SZH99, KEL00] use packet marking to convey explicit 289 congestion information to the relevant network nodes in charge of 291 taking admission control decisions. [MOR00] performs admission 293 control at layers above IP (i.e., TCP), by imposing each core router 295 to parse and capture TCP SYN and SYN/ACK segments, and forward such 297 packets only if local congestion conditions allow admission of a new 299 TCP flow. [ALM98] proposes a lightweight signaling protocol, with 301 explicit reservation messages, which requires network routers to 303 actively manage packets (via remarking of signaling packets when 305 congestion occurs), and thus it does not fit within a DiffServ 307 framework, where the core routers duty is strictly limited to 309 forwarding packets at the greatest possible speed (see e.g., what 311 stated in [BRE00]). 313 To summarize the above discussion, and to proceed further, we can 315 state that an abstract and general EAC can be defined as the 317 combination of three logically distinct components (although, in 319 some specific solutions the following issues are not clearly 321 distinct, this does not mean at all that these three specific issues 323 are not simultaneously present): 325 1: edge nodes in charge of taking explicit per flow accept/reject 327 decisions; 329 2: physical principles and measures on which decisions are based 331 (e.g., congestion status of an internal link or an 333 ingress/egress path, and particular measurement technique - if 335 any - adopted to detect such status); 337 3: the specific mechanisms adopted to convey internal network 339 information to edge nodes (e.g., received probing bandwidth 341 measurement, IP packet marking, exploitation of layers above IP 343 with a well-defined notion of connection or even explicit 345 signaling). 347 Bianchi&Blefari Informational - Expires April 2002 4 348 A Migration Path to provide End-to-End QoS over Stateless Networks by 350 Means of a Probing-driven Admission Control November 2001 352 In such a view, and with reference to each of the above points, we 354 argue that: 356 1: to allow edge nodes to take learned accept/reject decisions, the 358 congestion status of the network can not be inferred only on an 360 end-to-end basis; inner routers must be actively involved, but 362 without adding functionality other than that of the DiffServ 364 paradigm, in the basic IP forwarding scheme. 366 2: inner routers can determine whether a new call can be locally 368 admitted (i.e. as far as the local router is concerned) by means 370 of suitable Measurement Based Admission Controls (MBAC). Such 372 MBAC schemes operate according to some specific criteria (which 374 can be as simple as non performing any measure at all, and 376 taking a snapshot of the link state, or as complex as some of 378 the techniques proposed in [BJS00, GRO99]). These schemes do not 380 exploit per-flow state information and related traffic 382 specifications. Instead, they operate on the basis of per-node 384 aggregate traffic measurements carried out at the packet level. 386 The robustness of these schemes stays in the fact that, in 388 suitable conditions (e.g. flow peak rates small with respect to 390 link capacities), they are barely sensitive to uncertainties on 392 traffic profile parameters. As a consequence, it seems that 394 scalable estimations can be independently carried out by the 396 routers as far as local decisions are concerned. As a matter of 398 fact we propose one of such schemes in [BBFP01]. 400 3: An important problem is then how to convey the status of inner 402 routers to the end points so that the latter devices can take 404 learned admission control decisions, without violating the 406 DiffServ paradigm. For obvious reasons, we cannot use explicit 408 per flow signaling. Similarly, we do not want to modify the 410 basic router operation, by introducing packet marking schemes or 412 forcing routers to parse and interpret higher layer information. 414 What we want to do is to implicitly convey the status of core 416 routers to the end points, by means of scalable, DiffServ 418 compliant procedures. 420 4 A "Decoupled" Approach to Admission Control 422 We feel that the way to QoS provisioning in the Internet should be 424 outlined following an evolutionary approach. For evolutionary 426 approach, we mean that each individual domain should be put in the 428 condition of independently and asynchronously upgrade its network 430 components and management schemes to provide support for QoS. 432 This implies that the point 3) above must be decoupled in the 434 following elements: 436 1. Intra-domain resource reservation mechanisms. These mechanisms 438 should be limited to provide admission and congestion control 440 functions whose scope is limited to a single administrative domain, 442 and whose design is related to the specific requirements of the 444 Bianchi&Blefari Informational - Expires April 2002 5 445 A Migration Path to provide End-to-End QoS over Stateless Networks by 447 Means of a Probing-driven Admission Control November 2001 449 considered domain (e.g. a radio access network, a core backbone, a 451 small campus LAN, etc). The degree of QoS support provided within 453 each domain will depend on the tightness of control that the edge- 455 to-edge mechanism will be capable to support. Schemes ranging from 457 explicit per-flow resource reservation mechanisms (such as RSVP), 459 down to aggregate forms of traffic control (e.g. via measurement 461 based mechanisms, such as the one of GRIP) should be allowed to 463 independently operate in different domains. The ultimate goal is 465 that each domain should be placed in the ideal condition of 467 determining the suitable throughput/QoS support tradeoff within the 469 domain. 471 2. Inter-domain signaling mechanisms. To allow heterogeneous domain 473 to exchange basic control information, a cross-domain signaling 475 procedure should be deployed. Our view of such a cross domain 477 signaling exchange is twofold: 479 a: one possibility is to deploy a novel standard to allow domains 481 to exchange control information (e.g. whether a flow can be 483 admitted in the considered domain). The drawback of such a 485 solution is that the format and the contents of these control 487 packets needs to be standardized, and this may limit the timely 489 deployment of this cross-domain mechanism. 491 b: a much more simple, and in our opinion, appealing possibility, 493 is to define an IMPLICIT cross-domain signaling scheme, based on 495 drop of signaling packets. More discussion about this solution 497 is given in section 5 and 6. 499 5 The Concept of Implicit Signaling and its Use in Admission Control 501 Implicit signaling has been adopted to control network congestion 503 since the introduction of TCP congestion control in 1986. The idea 505 of implicit signaling is to allow the network endpoints to 507 autonomously determine whether congestion occurs along the network 509 path, and to react accordingly. 511 Congestion conditions are discovered at the end points by analyzing 513 packet losses. Upon congestion within a network node, packets are 515 lost, and this information is implicitly conveyed to the end nodes. 517 In particular, the authors of this draft have recently proposed an 519 implicit signaling paradigm, called GRIP (Gauge&Gate Reservation 521 with Independent Probing), devised to be compatible with DiffServ 523 scenarios [BB01, BBFP01]. GRIP is DiffServ compliant since all 525 traffic is managed according to the DS Code Point field only. In 527 particular, [BB01] shows that the GRIP way of operation is 529 semantically compatible with the AF PHB [RFC2597]. GRIP is briefly 531 described below. 533 5.1 GRIP End nodes operation 535 Bianchi&Blefari Informational - Expires April 2002 6 536 A Migration Path to provide End-to-End QoS over Stateless Networks by 538 Means of a Probing-driven Admission Control November 2001 540 GRIP's end nodes operation is extremely simple. Let us consider the 542 setup of an "uplink" (source to destination) monodirectional flow. 544 When a user terminal requests a connection with a destination 546 terminal, the Source Node starts a Probing Phase, by injecting in 548 the network in principle just one Probe Packet. Meanwhile, it 550 activates a probing phase timeout, lasting for a reasonably low 552 time. If no response is received from the destination node before 554 the timeout expiration, the source node enforces rejection of the 556 connection setup attempt. Otherwise, if a Feedback packet is 558 received in time, the connection is accepted, the probing phase is 560 terminated, and control is given back to the user application which 562 starts a Data Phase, simply consisting in the transmission of 564 information packets. 566 The role of the Destination Node simply consists in monitoring the 568 incoming IP packets, intercepting the ones labeled as Probes, 570 reading their source address, and, for each incoming probe packet, 572 just relaying with the transmission of a feedback packet, if the 574 destination is willing to accept the set-up request. 576 The only mandatory requirement is that Probes and Information 578 packets are labeled with different values of the DS codepoint field 580 in the IP packet header. This enables DiffServ routers to provide 582 different forwarding methods for Probes and Information packets, 584 e.g. granting service priority to Information packets. In this case, 586 the Feedback packet shall be labeled as an Information packet (i.e., 588 prioritary). Probing packets do not carry information describing the 590 characteristics of the associated data traffic (e.g. peak 592 bandwidth). This information is eventually conveyed by means of the 594 DSCP tag (i.e. a given kind of data traffic is associated with a 596 given DSCP tag). 598 Note that the described GRIP operation is trivially extended to 600 provide setup for bidirectional connections. In such a case, the 602 destination node will simply relay with a Probe packet instead than 604 with a Feedback packet. A Feedback will be ultimately sent back by 606 the source node upon reception of the destination Probe (to close 608 the three way connection setup handshake - independent probing 610 mechanisms are clearly needed to test both uplink and downlink 612 network paths, which generally differ). Finally, GRIP can be adapted 614 to support "downlink" (destination to source) flows. The source node 616 needs to issue a Trigger Packet to drive (by mean of application- 618 level protocol information, contained in the Trigger Packet payload) 620 the destination node to start a Probing Phase on its own. 622 To protect GRIP from possible route changes, due to the eventual 624 dynamics of routing protocols, we can think to additional Probing 626 packets periodically sent after the setup of a flow to "refresh" the 628 end-to-end path. On the other side, DiffServ will be probably 630 deployed in the core network where forwarding mechanisms such as 632 Bianchi&Blefari Informational - Expires April 2002 7 633 A Migration Path to provide End-to-End QoS over Stateless Networks by 635 Means of a Probing-driven Admission Control November 2001 637 MPLS, will limit the frequency of route changes below typical 639 session duration. Note also that lost or severely delayed probe 641 packets are interpreted as congestion. A probe packet may be lost if 643 the (wireless) link has high error rates, or delayed if 645 retransmission at lower layers occurs. However, this problem is 647 common to other admission control frameworks and can be overcome by 649 defining more complex probing phase operations, e.g., by including 651 reattempt procedures after a setup failure, multiple timers and 653 probes during the probing phase, etc. This could lead to too much 655 extra traffic generated by probes, which is a phenomenon that could 657 occur also for instance with HTTP session where multiple TCP 659 connections are initiated. To alleviate the problem, Probes could be 661 piggybacked on TCP SYN packets. 663 Finally, we point out that a priority among probing packets 665 belonging to different traffic classes could be introduced by means 667 of different DSCP tags. This way, higher service class users would 669 receive favorite treatment. Still another issue is re-negotiation of 671 the flow parameters and requested performance after the flow is 673 accepted. 675 5.2 GRIP over a GRIP-unaware domain 677 The rationale of GRIP is to reject a new flow setup when a feedback 679 does not return to the source node before that the probing timeout 681 expires. When GRIP is operated over a GRIP-unaware domain, flow 683 rejection is purely driven by internal network congestion. Upon 685 congestion, the round trip delay (Probe plus Feedback) may become 687 larger than the probing phase timeout, and thus a flow setup is 689 rejected. Stability is guaranteed by the fact that, when network 691 congestion increases, a corresponding decrease in the probability 693 that setup is successful occurs. Therefore, a lower number of new 695 flows set up, and this allows the network to smoothly decongest. 697 Routers may be in principle oblivious of Probes, and may treat them 699 as normal IP packets. When packet differentiation is possible, as in 701 the DiffServ scenario, GRIP operation can be enhanced. This 703 particularly occurs when DiffServ routers are configured to 705 distinguish information packets from Probes on the basis of their 707 DSCP value, and serve information packets with higher service 709 priority (i.e. before) than probing packets. This operation has the 711 advantage that the delay experienced by Probing packets is 713 necessarily worse (and thus is a conservative measure) than that 715 experienced by packets belonging to accepted connections. Thus, 717 probes may detect internal router congestion earlier than data 719 packets, and earlier drive reject decisions at the end points. 721 The performance of GRIP over DiffServ routers has been preliminarily 723 evaluated in a previous paper of ours. Such results lead to the 725 conclusion that the throughput performance is marginally dependent 727 on the probing packet timeout setting, at least when this timeout is 729 kept in the order of at most few hundreds of ms. This implies that 731 Bianchi&Blefari Informational - Expires April 2002 8 732 A Migration Path to provide End-to-End QoS over Stateless Networks by 734 Means of a Probing-driven Admission Control November 2001 736 the probing timeout is not an effective and tunable mean to 738 precisely control the QoS. 740 5.3 GRIP over a GRIP-aware domain 742 Despite the above discussed performance drawbacks, our strongest 744 argument in favor of GRIP is that it opens a smooth migration path 746 toward a future QoS capable global infrastructure. Our thesis is 748 that GRIP widespread deployment may start over the actual best- 750 effort Internet to provide marginal performance improvements (i.e. 752 similar to the ones relevant to the Controlled Load service), with 754 the promise that QoS will be provided in the future by independent 756 router upgrades in independent IP domains. 758 To justify our statement, we assume that network routers are able to 760 recognize that packets labeled as Probes are managed at the network 762 end points for the sake of flow admission control. Hence, they may 764 intelligently enforce Probe dropping, on the basis of suitable 766 estimation of the QoS provided to the already admitted flows, and on 768 the basis of suitable predictions of emerging congestion conditions. 770 As, thanks to the GRIP operation, internal probe losses drive setup 772 rejections at the distributed end points, independent, localized and 774 proprietary decisions taken at the network routers may substantially 776 improve the QoS provided within a domain. The GRIP-aware router 778 operation is illustrated in Fig. 1. 780 -------------------------- ----- 782 | / \ 784 Data Queue |/ Server \--------- 786 |\ / | 788 -------------------------- \ / | 790 || ------ | 792 || Measure | 794 \/ | 796 ------------------------ --------\/---------- 798 | Decision Criterion | | | Packets 800 | Controller Module | | Priority Server |--------> 802 ------------------------ | | 804 || -------------------- 806 || /\ 808 || Accept/Reject Switch | 810 \/ | 812 ------------------------- ------ | 814 | / \ | 816 Probe Queue |/ Server \----------- 818 |\ / 820 ------------------------- \ / 822 ------ 824 Figure 1: GRIP router operation 826 Bianchi&Blefari Informational - Expires April 2002 9 827 A Migration Path to provide End-to-End QoS over Stateless Networks by 829 Means of a Probing-driven Admission Control November 2001 831 For convenience of presentation, we assume that the router handles 833 only GRIP controlled traffic. Other traffic classes (e.g., best- 835 effort traffic) can be handled by means of additional queues, 837 eventually with lower priority. At each router output port, GRIP 839 implements two distinct queues, one for data packets, i.e. belonging 841 to flows that have already passed an admission control test, and one 843 for probing traffic. Packets are dispatched to the respective 845 buffers according to the probe/data DSCP tag. The GRIP router 847 measures the aggregate accepted traffic. On the basis of the running 849 traffic measurements, the router enforces a Decision Criterion, 851 which continuously drives the router to switch between two states: 853 ACCEPT and REJECT. When in the ACCEPT state, the Probing queue 855 accommodates Probe packets, and serves them according to the 857 described priority mechanism. Conversely, when the router switches 859 to the REJECT state, it discards all the Probing packets contained 861 in the Probing queue, and blocks all new Probing packets arriving. 863 In other words, the router acts as a gate for the probing flow, 865 where the gate is opened or closed on the basis of the traffic 867 estimates (hence the Gauge&Gate in the acronym GRIP). 869 This mechanism provides an implicit signaling pipe to the end 871 points, of which the network remains unaware. Each router is locally 873 in charge of deciding, on the basis of its own criteria, whether it 875 can admit new flows, or it is congested. The internal router 877 decision is summarized in the router state (ACCEPT vs. REJECT), and 879 it is implicitly advertised to the end points (whose flow setup path 881 crosses the considered router) by letting Probes cross through the 883 router (ACCEPT) or blocking probes (REJECT). 885 With reference to the performance achievable, it is easy to conclude 887 that the level of QoS support provided depends on the degree of 889 effectiveness of the Decision Criterion implementation. Several 891 Measurement-Based mechanisms [BJS00] have been described in the 893 literature and may be applied to the GRIP routers [e.g., GRO99]. 895 An example of a trivial decision criterion is to accept all Probe 897 packets when the measured throughput is lower than a given threshold 899 and reject them packets when the measurements overflow this 901 threshold. The resulting delay performance depends upon the link 903 capacity and the traffic model. 905 Tighter forms of traffic control are possible. As a second example 907 of a decision criterion, we demonstrated that hard (loss and/or 909 delay) QoS guarantees can be provided, within a specific domain, 911 under suitable assumptions on the offered traffic (i.e., traffic 913 sources regulated by standard Dual Leaky Buckets, as in the IntServ 915 framework) and with ad hoc defined measurement modules in the 917 routers [BBFP01]. 919 Bianchi&Blefari Informational - Expires April 2002 10 920 A Migration Path to provide End-to-End QoS over Stateless Networks by 922 Means of a Probing-driven Admission Control November 2001 924 Finally, we note that the decision criterion must not be necessarily 926 driven by traffic measurements. In fact, it can be driven by lower 928 layers QoS capabilities, (e.g., ATM, MAC) or by tunable proprietary 930 schemes. 932 A last consideration is that GRIP shares with common MBAC schemes 934 the problem of defining precise admission control criteria when the 936 admitting flows are very different between each other in their 938 characteristics and in their required performance. To maintain the 940 advantages of GRIP, probes should not contain signaling information 942 to be parsed at core routers (while edge routers could execute this 944 function, see section 6). A possible way to solve this problem is to 946 impose that a given admission controlled traffic class is composed 948 of flows with homogeneous (or at least similar) characteristics and 950 requirements. In other words, QoS enabled sources are divided in 952 traffic classes, each comprising homogeneous (or similar) sources. 954 By envisioning a very small number of traffic classes (e.g., a class 956 could be IP telephony), each class could be handled in a 958 differentiated way, (according to the DiffServ approach, with its 960 own pair of DS codepoints for probing and data), by means of 962 suitable scheduling mechanisms, similar to those already defined 964 (e.g., WFQ, separate queues). Further details on this issue can be 966 found in [BB01]. 968 We conclude by remarking that GRIP does not require any specific 970 protocol implementation in the core routers, which are stateless and 972 remain oblivious to individual flows. Scalability is guaranteed by 974 the fact that (i) no state information is stored in any router, 976 which handle traffic aggregates and not single flows, and that (ii) 978 the whole operation is fully distributed: the procedures have a 980 local scope and each network device operates autonomously. 982 6 Implicit Cross-Domain Signaling 984 The principle of packet losses as a way to notify congestion can be 986 extended to heterogeneous domains, each running independent intra- 988 domain reservation mechanisms. The foundation for implicit signaling 990 is only the capability for each ingress node of a domain to 992 recognize whether a packet contains signaling information versus 994 data payload, regardless of which specific signaling information is 996 actually contained. Note that this feature is possible by using 998 suitable packet marking in the DSCP field of the packet header [see 1000 also BB01]. 1002 To better clarify, consider the scenario depicted in figure 2. 1004 Here, the source to destination path comprises three different 1006 domains, namely A, B, and C, each running a different - fictitious - 1008 intra-domain reservation protocol (namely RP1, RP2, RPX). Each 1010 Bianchi&Blefari Informational - Expires April 2002 11 1011 A Migration Path to provide End-to-End QoS over Stateless Networks by 1013 Means of a Probing-driven Admission Control November 2001 1015 reservation protocol has its own scheme, and is triggered by a 1017 signaling packet eventually containing suitable information. 1019 __________ __________ __________ 1021 / \ / \ / \ 1023 / \ / \ / \ 1025 |---| |--| |---| |---| |--| |---| 1027 |SRC|--|R1| domain A | R2| domain B | R3| domain C |R4|--|DST| 1029 |---| |--| (RP1) |---| (RP2) |---| (RPX) |--| |---| 1031 \ / \ / \ / 1033 \__________/ \__________/ \__________/ 1035 Figure 2: Multi-domain scenario 1037 When the source needs to setup a flow to the destination, it injects 1039 in the network a signaling (probe) packet. Similarly to what 1041 described above in GRIP, the source node is in charge to wait for a 1043 feedback packet, and then activate the flow by emitting data 1045 packets. In case the feedback packet does not arrives back in due 1047 time, the flow setup is aborted. 1049 The signaling packet injected in the network can carry application- 1051 level information to be used at the destination node. In addition, 1053 it can eventually carry information that can be read by some 1055 reservation protocols, e.g. RP1. 1057 First, the signaling packet arrives at the ingress node of domain A. 1059 This node recognizes, in the order, that 1061 a: the packet is a signaling packet, and 1063 b: it contains information usable by the specific reservation 1065 protocol RP1 (e.g. RSVP). 1067 This packet thus triggers the specific edge-to-edge reservation 1069 mechanism RP1 running through domain A. At the end of the 1071 reservation procedure, if the domain is capable of admitting the 1073 flow, then the signaling packet is forwarded out of the domain by 1075 the egress node. Otherwise, it is dropped. 1077 The same approach is adopted at domain B. Here, the difference is 1079 that the specific reservation protocol triggered by the arrival of 1081 the signaling packet is different from that adopted in the previous 1083 domain (e.g., domain B adopts a DS framework augmented with GRIP 1085 admission control functionality, as its inner reservation scheme). 1087 However, the result is semantically consistent with the previous 1089 domain operation, i.e. the triggering packet is forwarded if the 1091 connection can be accepted, and dropped otherwise. No explicit 1093 signaling information is exploited, with the exception of the one 1095 carried by the DS codepoint of the triggering packet [see BB01]. 1097 Finally, the triggering packet arrives at the ingress node of domain 1099 C. Here, the ingress node recognizes that the packet is for 1101 Bianchi&Blefari Informational - Expires April 2002 12 1102 A Migration Path to provide End-to-End QoS over Stateless Networks by 1104 Means of a Probing-driven Admission Control November 2001 1106 signaling, but it finds that the packet does not carry information 1108 useful for the reservation protocol RPX (i.e. the packet and even 1110 the relevant DS codepoint is incompatible with this domain inner DS 1112 procedures). Therefore, domain C can decide to: 1114 a: run a "generic" (e.g. un-parameterized) edge-to-edge signaling 1116 procedure 1118 b: drop the packet (i.e. drop the entire flow). 1120 c: simply forward the packet, with no admission control, on a best 1122 effort basis. 1124 Although the above example is very loose, and several problems need 1126 a thorough investigation, nevertheless it appears that such an 1128 implicit signaling approach can be the "glue" for the coexistence of 1130 highly heterogeneous edge-to-edge reservation mechanisms. 1132 Moreover, note that the outlined approach allows the coexistence of 1134 domains running a reservation protocol with best effort domains. 1136 Clearly, the QoS provisioned to the considered end-to-end flow will 1138 be bottlenecked by the worst case domain. But in the same time, 1140 domains that run a reservation mechanism are capable of limiting the 1142 traffic admitted, and thus locally guaranteeing QoS support. 1144 A thorough understanding of this latter issue is of importance. The 1146 cross-domain reservation scheme described above is not necessarily 1148 aimed at providing an end-to-end QoS support or performance 1150 guarantees. Conversely, it is devised to guarantee each domain that 1152 the performance encountered by packets crossing the given domain are 1154 kept under control (depending on the degree of tightness of the 1156 reservation protocol adopted). In other words, our view of the 1158 performance provided is domain-centric, rather than an end-to-end 1160 guaranteed performance view. Eventually, suitable routing schemes 1162 and SLAs can find a path that comprises only QoS aware domains. 1164 Note that this is line with the way of operation of other functions 1166 in the Internet (e.g. routing), which allow different domains to 1168 adopt different schemes. 1170 A last issue regards the definition of DS codepoints to identify 1172 probe (signaling) packets and data packets. In [BB01] we proposed to 1174 use two dropping levels of a given AF class to this purpose. 1176 However, we are aware that our suggested usage of AF is different 1178 (and quite unexpected) from what intended in RFC 2597. The services 1180 that are expected to make use of admission control are RTP/UDP 1182 streams with delay and loss performance requirements, whose support 1184 is currently envisioned by means of the EF PHB. On the contrary, AF 1186 appears designed to provide better than best effort support for 1188 generic TCP/UDP traffic. Thus, our study raises the case for the 1190 transformation of the (single) EF PHB into a PHB class (i.e. by 1192 adding an associated, "paired", probing pipe with a different DSCP). 1194 An alternative is defining new "paired" PHBs. 1196 Bianchi&Blefari Informational - Expires April 2002 13 1197 A Migration Path to provide End-to-End QoS over Stateless Networks by 1199 Means of a Probing-driven Admission Control November 2001 1201 On a different prospective, "paired" PHBs can be envisioned to 1203 support more general control functions than admission control. For 1205 example, the TCP fast retransmission and recovery algorithm might 1207 take advantage of isolated data packets labeled as "control", and 1209 thus expected to encounter loss if (controlled) congestion is 1211 encountered in the network. 1213 7 Appendix D: Security considerations 1215 As all admission control functions, our solution presents the risk 1217 of theft of resources through the unauthorized admission of traffic. 1219 Although, logically, user terminals are the natural nodes where the 1221 endpoint admission control should operate, this is clearly not 1223 realistic, for the obvious reason that the user may bypass the 1225 admission control test and directly send probe packets. Identity 1227 authentication and integrity protection are therefore needed in 1229 order to mitigate this potential for theft of resources [RFC2990]. 1231 Administrators are then expected to protect network resources by 1233 configuring secure policers at interfaces (e.g. access routers) with 1235 untrusted customers. Similar protections must be provided at the 1237 interface between different domains. In particular, it may be 1239 necessary to restrict the access to the DS class(es) used for 1241 admission controlled traffic. For example, a DS domain should re- 1243 mark packets when they come from an un-trusted adjacent DS domain. 1245 In more generality, we remark that policing and conditioning rules 1247 enforced at the border routers of each domain depend on the usage of 1249 the considered class within the specific domain and thus have to be 1251 accounted of in the definition of each specific PDB supporting 1253 admission control. 1255 A quite obvious security hazard is flooding the network with probe 1257 packets. The objective is twofold. On one side, denial of service 1259 situations can be easily created, as a massive loading of the 1261 network with probe packets prevent the setup of normal connection. 1263 On the other side, the goal might be to affect fairness: the 1265 continuous transmission of probe packets at a rate higher than 1267 normal connection requests is a mean to gain faster access to 1269 resources when these are made available by a router along the path. 1271 This implies that some form of traffic conditioning and policing is 1273 necessary over probe streams. While it is simple to recognize an 1275 hard attack, by monitoring the probe packets crossing an edge router 1277 (the probe traffic - at most a few packets per originating 1279 connection - is minimal in normal conditions, and thus sudden 1281 increments of the probe load are suspicious), it may be not 1283 straightforward for DS boundary routers to recognize smoother 1285 fairness attacks. However, note that the same fairness problem is 1287 present also in more complex reservation mechanisms, such as RSVP 1289 (malicious users can continuously require setup to increase their 1291 access possibility with respect to normal users). 1293 Bianchi&Blefari Informational - Expires April 2002 14 1294 A Migration Path to provide End-to-End QoS over Stateless Networks by 1296 Means of a Probing-driven Admission Control November 2001 1298 Finally, all the security considerations expressed in [RFC2990] 1300 apply also to our solution. 1302 8 References 1304 [ALM98] W.Almesberger, T.Ferrari, J. Y. Le Boudec: "SRP: a Scalable 1306 Resource Reservation Protocol for the Internet", IWQoS'98, Napa 1308 (California), May 1998. 1310 [BB01] G. Bianchi, N. Blefari-Melazzi: "Per Flow Admission Control 1312 over AF PHB Classes", Internet draft, 1314 draft_bianchi_blefari_admcontr_over_af_phb.txt, March 2001, work in 1316 progress. 1318 [BBFP01] G. Bianchi, N. Blefari-Melazzi, M. Femminella, F. Pugini: 1320 "GRIP: Technical report", work in progress, 1322 (http://conan.diei.unipg.it/netweb/GRIP_tech_rep.pdf). 1324 [BJS00] L. Breslau, S. Jamin, S. Schenker: "Comments on the 1326 performance of measurement-based admission control algorithms", IEEE 1328 Infocom 2000, Tel-Aviv, March 2000. 1330 [BOR99] F. Borgonovo, A. Capone, L. Fratta, M. Marchese, C. 1332 Petrioli, "PCP: A Bandwidth Guaranteed Transport Service for IP 1334 networks", IEEE ICC'99, June 1999. 1336 [BRE00] L. Breslau, E. W. Knightly, S. Schenker, I. Stoica, H. 1338 Zhang: "Endpoint Admission Control: Architectural Issues and 1340 Performance", ACM SIGCOMM 2000, Stockholm, Sweden, August 2000. 1342 [CKN00] C. Cetinkaya, E. Knightly, "Egress Admission Control", Proc. 1344 of IEEE Infocom 2000, Tel-Aviv, March 2000. 1346 [ELE00] V. Elek, G. Karlsson, "Admission Control Based on End-to-End 1348 Measurements", Proc. of IEEE Infocom 2000, Tel Aviv, Israel, March 1350 2000. 1352 [GKE99] R. J. Gibbens, F. P. Kelly, "Distributed Connection 1354 Acceptance Control for a Connectionless Network", 16 ITC, Edimburgh, 1356 June 1999. 1358 [GRO99] M. Grossglauser, D. N. C. Tse: "A Time-Scale Decomposition 1360 Approach to Measurement-Based Admission Control", Proc. of IEEE 1362 Infocom 1999, New York, USA, March 1999. 1364 [KEL00] F. P. Kelly, P. B. Key, S. Zachary: " Distributed Admission 1366 Control", IEEE JSAC, Vol. 18, No. 12, December 2000. 1368 Bianchi&Blefari Informational - Expires April 2002 15 1369 A Migration Path to provide End-to-End QoS over Stateless Networks by 1371 Means of a Probing-driven Admission Control November 2001 1373 [MOR00] R. Mortier, I. Pratt, C. Clark, S. Crosby: "Implicit 1375 Admission Control", IEEE JSAC, Vol. 18, No. 12, December 2000. 1377 [RFC2205] R. Braden, L Zhang, S. Berson, S. Herzog, S. Jamin, 1379 "ResourceReSerVation Protocol (RSVP) - Version 1 Functional 1381 Specification", RFC2205, September 1997. 1383 [RFC2210] J. Wroclawsky, "The use of RSVP with IETF Integrated 1385 Services", RFC2210, September 1997. 1387 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definitions of 1389 the Differentiated Service Field (DS Field) in the Ipv4 and Ipv6 1391 Headers", RFC2474, December 1998. 1393 [RFC2475] S. Blade, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1395 Weiss, "An Architecture for Differentiated Services", RFC2475, 1397 December 1998. 1399 [RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured 1401 Forwarding PHB Group", RFC 2597, June 1999. 1403 [RFC2990] G. Huston, "Next Steps for the IP QoS Architecture", 1405 RFC2990, November 2000. 1407 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1409 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, 1411 "A Framework for Integrated Services Operation Over DiffServ 1413 Networks", RFC 2998, November 2000. 1415 [SZH99] I. Stoica, H. Zhang, "Providing guaranteed services without 1417 per flow management", Proc. of ACM SIGCOMM 1999, Cambridge, MA, 1419 September 2000. 1421 9 Author's Addresses 1423 Giuseppe Bianchi 1425 DIE, University of Palermo 1427 Viale delle Scienze, Parco d'Orleans 1429 90128 Palermo, ITALY 1431 Tel: +39 091 6566 276 1433 E-mail: bianchi@elet.polimi.it 1435 Nicola Blefari-Melazzi 1437 DIEI, University of Perugia 1439 Via G. Duranti 93, 06125 Perugia, ITALY 1441 Tel: +39 075 585 3630 1443 e-mail: blefari@diei.unipg.it 1445 Bianchi&Blefari Informational - Expires April 2002 16 1446 A Migration Path to provide End-to-End QoS over Stateless Networks by 1448 Means of a Probing-driven Admission Control November 2001 1450 10 Full Copyright Statement 1452 "Copyright (C) The Internet Society (date). All Rights Reserved. 1454 This document and translations of it may be copied and furnished to 1456 others, and derivative works that comment on or otherwise explain it 1458 or assist in its implementation may be prepared, copied, published 1460 and distributed, in whole or in part, without restriction of any 1462 kind, provided that the above copyright notice and this paragraph 1464 are included on all such copies and derivative works. However, this 1466 document itself may not be modified in any way, such as by removing 1468 the copyright notice or references to the Internet Society or other 1470 Internet organizations, except as needed for the purpose of 1472 developing Internet standards in which case the procedures for 1474 copyrights defined in the Internet Standards process must be 1476 followed, or as required to translate it into languages other than 1478 English. 1480 The limited permissions granted above are perpetual and will not be 1482 revoked by the Internet Society or its successors or assignees. 1484 This document and the information contained herein is provided on an 1486 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1488 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1490 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1492 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1494 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1496 Bianchi&Blefari Informational - Expires April 2002 17