Network Working Group A. Charny Internet-Draft Cisco Systems, Inc. Intended status: Standards Track J. Zhang Expires: September 6, 2007 Cisco Systems, Inc. and Cornell University F. Le Faucheur V. Liatsos Cisco Systems, Inc. March 5, 2007 Pre-Congestion Notification Using Single Marking for Admission and Pre- emption draft-charny-pcn-single-marking-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] approach proposes the use of an Admission Control mechanism to limit Charny, et al. Expires September 6, 2007 [Page 1] Internet-Draft PCN with Single Marking March 2007 the amount of real-time PCN traffic to a configured level during the normal operating conditions, and the use of a Pre-emption mechanism to tear-down some of the flows to bring the PCN traffic level down to a desirable amount during unexpected events such as network failures, with the goal of maintaining the QoS assurances to the remaining flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- emption use two different markings and two different metering mechanisms in the internal nodes of the PCN region. This draft proposes a mechanism using a single marking and metering for both Admission and Pre-emption, and presents a preliminary analysis of the tradeoffs. A side-effect of this proposal that a different marking and metering Admission mechanism than that proposed in[I-D.briscoe-tsvwg-cl-architecture] may be also feasible. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Charny, et al. Expires September 6, 2007 [Page 2] Internet-Draft PCN with Single Marking March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Changes from -00 version . . . . . . . . . . . . . . . . . 4 1.2. Background and Motivation . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. The Single Marking Approach . . . . . . . . . . . . . . . . . 6 2.1. High Level description . . . . . . . . . . . . . . . . . . 6 2.2. Operation at the PIN . . . . . . . . . . . . . . . . . . . 7 2.3. Operation at the Egress PEN . . . . . . . . . . . . . . . 7 2.4. Operation at the Ingress PEN . . . . . . . . . . . . . . . 8 2.4.1. Admission Decision . . . . . . . . . . . . . . . . . . 8 2.4.2. Pre-emption Decision . . . . . . . . . . . . . . . . . 9 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Tradeoffs, Issues and Discussion . . . . . . . . . . . . . 10 3.2.1. Restrictions on Pre-emption-to-admission Thresholds . 10 3.2.2. Assumptions on Loss . . . . . . . . . . . . . . . . . 10 3.2.3. Effect of Reaction Timescale of Admission Mechanism . 10 3.2.4. Performance Implications and Tradeoffs . . . . . . . . 11 3.2.5. Effect on Proposed Anti-cheating Mechanisms . . . . . 11 3.2.6. Standards Implications . . . . . . . . . . . . . . . . 12 4. Performance Evaluation Comparison . . . . . . . . . . . . . . 12 4.1. Relationship to other drafts . . . . . . . . . . . . . . . 12 4.2. Limitations, Conclusions and Direction for Future Work . . 12 4.2.1. High Level Conclusions . . . . . . . . . . . . . . . . 12 4.2.2. Future work . . . . . . . . . . . . . . . . . . . . . 13 5. Appendix A: Simulation Details . . . . . . . . . . . . . . . 14 5.1. Network and Signaling Model . . . . . . . . . . . . . . . 14 5.2. Traffic Models . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. CBR Voice (CBR) . . . . . . . . . . . . . . . . . . . 17 5.2.2. VBR Voice (VBR) . . . . . . . . . . . . . . . . . . . 17 5.2.3. "Synthetic Video": High Rate ON-OFF traffic with Video-like Mean and Peak Rates ("SVD") . . . . . . . 17 5.2.4. Real Video Traces (VTR) . . . . . . . . . . . . . . . 17 5.3. Parameter Settings . . . . . . . . . . . . . . . . . . . . 18 5.3.1. Queue-based settings . . . . . . . . . . . . . . . . . 18 5.3.2. Token Bucket Settings . . . . . . . . . . . . . . . . 18 5.4. Simulation Details . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Queue-based Results . . . . . . . . . . . . . . . . . 19 5.4.2. Token Bucket-based Results . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Charny, et al. Expires September 6, 2007 [Page 3] Internet-Draft PCN with Single Marking March 2007 1. Introduction 1.1. Changes from -00 version Added miscellaneous clarifications based on comments received on version -00. Added simulation results for multi-hop topologies and video trace data to the Appendix. 1.2. Background and Motivation Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] approach proposes to use an Admission Control mechanism to limit the amount of real-time PCN traffic to a configured level during the normal operating conditions, and to use a Pre-emption mechanism to tear-down some of the flows to bring the PCN traffic level down to a desirable amount during unexpected events such as network failures, with the goal of maintaining the QoS assurances to the remaining flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- emption use different two different markings and two different metering mechanisms in the internal nodes of the PCN region. Admission Control algorithms for variable-rate real-time traffic such as video have traditionally been based on the observation of the queue length, and hence re-using these techniques and ideas in the context of pre-congestion notification is highly attractive, and motivated the virtual-queue-based marking and metering approach specified in [I-D.briscoe-tsvwg-cl-architecture] for Admission. On the other hand, for Pre-emption, it is desirable to know how much traffic needs to be pre-empted, and that in turn motivates rate-based Pre-emption metering. This provides some motivation for employing different metering algorithm for Admission and for Preemption. Furthermore, it is frequently desirable to trigger Pre-emption at a substantially higher traffic level than the level at which no new flows are to be admitted. There are multiple reasons for the requirement to enforce a different Admission Threshold and Preemption Threshold. These include, for example: o End-users are typically more annoyed by their established call dying than by getting a busy tone at call establishment. o There are often very tight (possibly legal) obligations on network operators to not drop established calls. o Voice Call Routing often has the ability to route/establish the call on another network (e.g., PSTN) if it is determined at call establishment that one network (e.g., packet network) can not accept the call. Therefore, not admitting a call on the packet network at initial establishment may not impact the end-user. In Charny, et al. Expires September 6, 2007 [Page 4] Internet-Draft PCN with Single Marking March 2007 contrast, it is usually not possible to reroute an established call onto another network mid-call. This means that call Preemption can not be hidden to the end-user. o Preemption is typically useful in failure situations where some loads get rerouted thereby increasing the load on remaining links. Because the failure may only be temporary, the operator may be ready to tolerate a small degradation during the interim failure period. o A congestion notification based Admission scheme has some inherent inaccuracies because of its reactive nature and thus may potentially over admit in some situations (such as burst of calls arrival). If the Preemption scheme reacted at the same Threshold as the Admission Threshold, calls may get routinely dropped after establishment because of over admission, even under steady state conditions. These considerations argue for metering for Admission and Pre-emption at different traffic levels and hence, implicitly, for different markings and metering schemes. Different marking schemes require different codepoints. Thus, such separate markings consume valuable real-estate in the packet header, especially scarce in the case of MPLS Pre-Congestion Notification [I-D.davie-ecn-mpls] . Furthermore, two different measurement/ metering techniques involve additional complexity in the datapath of the internal routers of the PCN domain. To this end, [I-D.briscoe-tsvwg-cl-architecture] proposes an approach, referred to as implicit pre-emption marking, that does not require separate pre-emption marking. However, it does require two separate measurement schemes: one measurement for Admission and another measurement for Preemption/Dropping. Furthermore, this approach mandates that the configured preemption rate be set to a drop rate. This approach effectively uses dropping as the way to convey information about how much traffic can "fit" under the preemption limit, instead of using a separate preemption marking. This is a significant restriction in that it results in preemption only taking effect once packets actually get dropped. This document presents an approach that allows the use of a single PCN marking and a single metering technique at the internal devices without requiring that the dropping and pre-emption thresholds be the same. This document also investigates some of the tradeoffs associated with this approach. Charny, et al. Expires September 6, 2007 [Page 5] Internet-Draft PCN with Single Marking March 2007 1.3. Terminology o Pre-Congestion Notification (PCN): two algorithms that determine when a PCN-enabled router Admission Marks and Pre-emption Marks a packet, depending on the traffic level. o Admission Marking condition- the traffic level is such that the router Admission Marks packets. The router provides an "early warning" that the load is nearing the engineered admission control capacity, before there is any significant build-up in the queue of packets belonging to the specified real-time service class. o Pre-emption Marking condition- the traffic level is such that the router Pre-emption Marks packets. The router warns explicitly that pre-emption may be needed. o Configured-admission-rate - the reference rate used by the admission marking algorithm in a PCN-enabled router. o Configured-pre-emption-rate - the reference rate used by the pre- emption marking algorithm in a PCN-enabled router. o CLE - congestion level estimate computed by the egress node by estimating as the fraction of admission-marked packets it receives. o PIN - PCN internal node - an internal node in the PCN region. o PEN - PCN edge node - an ingress or egress edge node of the PCN region. o SAR - Sustainable Admission rate - the rate of unmarked traffic received by the Ingress PEN from the egress PEN o SPR - Sustainable Preemption rate 2. The Single Marking Approach 2.1. High Level description The proposed approach is based on several simple ideas: o Replace virtual-queue-based marking for Admission Control by excess rate marking: * meter traffic exceeding the Admission Threshold and mark excess traffic (e.g. using a token bucket with the rate configured to Charny, et al. Expires September 6, 2007 [Page 6] Internet-Draft PCN with Single Marking March 2007 Admission Rate Threshold) * at the edges, stop admitting traffic when the fraction of marked traffic for a given edge-to-edge aggregate exceeds a configured threshold (e.g. stop admitting when 3% of all traffic in the edge-to-edge aggregate received at the ingress is marked) o Impose a PCN-region-wide constraint on the ratio between the Admission threshold on a link and Pre-emption threshold on that link (e.g. pre-emption threshold is 20% higher than Admission threshold on all links in the PCN region) o The edge PCN device determines whether Pre-emption level is reached anywhere in the network *implicitly* by measuring the amount of unmarked traffic (assuming the marked traffic actually is above the threshold triggering blocking admission), i.e. the traffic that did not get admission marked. This is analogous to the notion of sustainable pre-emption rate in [I-D.briscoe-tsvwg-cl-architecture]. The rate of unmarked traffic in this case signifies the bottleneck admission threshold. The bottleneck pre-emption threshold is by design within the chosen ratio of that admission threshold. The ingress PCN edge device preempts all traffic above the bottleneck preemption threshold. The remaining part of this section gives more detailed of a possible operation of the system. 2.2. Operation at the PIN The PCN Internal Node (PIN) meters the aggregate PCN traffic and marks the excess rate. A number of implementations are possible to achieve that. A token bucket implementation is particularly attractive because of its relative simplicity, and even more so because a token bucket implementation is readily available in the vast majority of existing equipment. The rate of the token bucket is configured to correspond to the target Admission rate, and the depth of the token bucket can be configured by an operator based on the desired tolerance to PCN traffic burstiness. Note that no preemption threshold is explicitly configured at the PIN, and the PIN does nothing at all to enforce it or mark traffic based on Pre-emption threshold. 2.3. Operation at the Egress PEN The PCN Egress Node (PEN) measures the rate of both marked and unmarked traffic on a per-ingress PEN basis, and reports to the Charny, et al. Expires September 6, 2007 [Page 7] Internet-Draft PCN with Single Marking March 2007 ingress PEN two values: the rate of unmarked traffic from this ingress PEN, which we deem Sustainable Admission Rate (SAR) and the Congestion Level Estimate (CLE), which is the fraction of the marked traffic received from this ingress PEN. Note that Sustainable Admission Rate is analogous to the sustainable pre-emption rate of [I-D.briscoe-tsvwg-cl-architecture], except in this case it is based on the admission threshold rather than pre-emption threshold, while the CLE is exactly the same as that of [I-D.briscoe-tsvwg-cl-architecture]. The details of the rate measurement are outside the scope of this draft. 2.4. Operation at the Ingress PEN 2.4.1. Admission Decision Just as in [I-D.briscoe-tsvwg-cl-architecture], the admission decision is based on the CLE. The ingress PEN stops admission of new flows if the CLE is above a pre-defined threshold (e.g. 3%). Note that although the logic of the decision is exactly the same as in the case of [I-D.briscoe-tsvwg-cl-architecture], the detailed semantics of the marking is different. This is because the marking used for admission in this proposal reflects the excess rate over the admission threshold, while in [I-D.briscoe-tsvwg-cl-architecture], the marking is based on exceeding a virtual queue threshold. Notably, in the current proposal, if the average sustained rate of admitted traffic is 5% over the admission threshold, then 5% of the traffic is expected to be marked, whereas in the context of [I-D.briscoe-tsvwg-cl-architecture] a steady 5% overload should eventually result in 100% of all traffic being admission marked. A consequence of this is that for smooth traffic, the approach presented here will not mark any traffic at all until the rate of the traffic exceeds the configured admission threshold by the amount corresponding to the chosen CLE threshold. At first glance this may seem to result in a violation of the pre-congestion notification premise that attempts to stop admission before the desired traffic level is reached. However, in reality one can simply embed the CLE level into the desired configuration of the admission threshold. That is, if a certain rate X is the actual target admission threshold, then one should configure the rate of the metering device (e.g. the rate of the token bucket) to X-y where y corresponds to the level of CLE that would trigger admission blocking decision. A more important distinction is that virtual-queue based marking reacts to short-term burstiness of traffic, while the excess-rate based marking is only capable of reacting to rate violations at the timescale chosen for rate measurement. Based on our investigation, it seems that this distinction is not crucial in the context of PCN when no actual queuing is expected even if the virtual queue is full. Charny, et al. Expires September 6, 2007 [Page 8] Internet-Draft PCN with Single Marking March 2007 More discussion on this is presented later in the draft. 2.4.2. Pre-emption Decision When the ingress observes a non-zero CLE and Sustainable Admission Rate (SAR), it first computes the Sustainable Pre-Emption rate (SPR) by simply multiplying SAR by the system-wide constant u, where u is the system-wide ratio between pre-emption and admission thresholds on all links in the PCN domain: SPR = SAR*u. The ingress PEN then performs exactly the same operation as is proposed in [I-D.briscoe-tsvwg-cl-architecture] with respect to SPR. Namely, it pre-empts the appropriate number of flows to ensure that the rate of traffic it sends to the corresponding egress PEN does not exceed SPR. Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], an implementation may decide to slow down the pre-emption process by preempting fewer flows than is necessary to cap its traffic to SPR by employing a variety of techniques such as safety factors or hysteresis. In summary, the operation of pre-emption at the ingress PEN is identical to that of [I-D.briscoe-tsvwg-cl-architecture], with the only exception that the sustainable pre-emption rate is computed from the sustainable admission rate rather than derived from a separate marking. As discussed earlier, this is enabled by imposing a system-wide restriction on the pre-emption-to-admission thresholds ratio and changing the semantics of the admission marking. 3. Discussion 3.1. Benefits The key benefits of using a single metering/marking scheme for both Admission and Preemption presented in this document are summarized below: o Reduced implementation requirements on core routers due to a single metering implementation instead of two different ones. o Ease of use on existing hardware: given that the proposed approach is particularly amenable to a token bucket implementation, the availability of token buckets on virtually all commercially available routers makes this approach especially attractive. o Reduced number of codepoints which need to be conveyed in the packet header. If the PCN-bits used in the packets header to convey the congestion notification information are the ECN-bits in an IP core and the EXP-bits in an MPLS core, as is currently proposed in [put marking draft reference here] and [I-D.davie-ecn-mpls], those are very expensive real-estate. The Charny, et al. Expires September 6, 2007 [Page 9] Internet-Draft PCN with Single Marking March 2007 current proposals need 5 codepoints, which is especially important in the context of MPLS where there is only a total of 8 EXP codepoints which must also be shared with Diffserv. Eliminating one codepoint considerably helps. o A possibility of using a token-bucket-, excess-rate- based implementation for admission provides extra flexibility for the choice of an admission mechanism, even if two separate markings and thresholds are used. 3.2. Tradeoffs, Issues and Discussion While the benefits of the proposed approach are attractive, there are several issues and tradeoffs that need to be carefully considered. 3.2.1. Restrictions on Pre-emption-to-admission Thresholds An obvious restriction necessary for the single-marking approach is that the ratio of (implicit) pre-emption and admission thresholds remains the same on all links in the PCN region. While clearly a limitation, this does not appear to be particularly crippling, and does not appear to outweigh the benefits of reducing the overhead in the router implementation and savings in codepoints in the case of a single PCN domain, or in the case of multiple concatenated PCN regions. The case when this limitation becomes more inconvenient is when an operator wants to merge two previously separate PCN regions (which may have different admission-to-preemption ratios) into a single PCN region. In this case it becomes necessary to do a network-wide reconfiguration to align the settings. 3.2.2. Assumptions on Loss Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], the approach presented in this draft assumes that the Admission Threshold is configured at each link below the service rate of the traffic using PCN. This assumption is significant because the algorithm relies on the fact that if admission threshold is exceeded, enough marked traffic reaches the egress PEN to reach the configured CLE level. If this condition does not hold, then traffic may get dropped without ever triggering admission decision. 3.2.3. Effect of Reaction Timescale of Admission Mechanism As mentioned earlier in this draft, there is a potential concern that slower reaction time of admissions mechanism presented in this draft compared to [I-D.briscoe-tsvwg-cl-architecture] may result in overshoot when the load grows rapidly, and undershoot when the load drops rapidly. While this is a valid concern theoretically, it Charny, et al. Expires September 6, 2007 [Page 10] Internet-Draft PCN with Single Marking March 2007 should be noted that at least for the traffic and parameters used in the simulation study reported here, there was no indication that this was a problem. However, the comparison has so far been done for Poisson arrivals only. Future work would look in performing a similar comparison for burstier arrivals. 3.2.4. Performance Implications and Tradeoffs Replacement of a relatively well-studied queue-based measurement- based admission control approach by a cruder excess-rate measurement technique raises a number of algorithmic and performance concerns that need to be carefully evaluated. For example, a token-bucket excess rate measurement is expected to be substantially more sensitive to traffic burstiness and parameter setting, which may have a significant effect in the case of lower levels of traffic aggregation, especially for variable-rate traffic such as video. In addition, the appropriate timescale of rate measurement needs to be carefully evaluated, and in general it depends on the degree of expected traffic variability which is frequently unknown. In view of that, an initial performance comparison of the token- bucket based measurement is presented in the following section. Within the constraints of this preliminary study, the performance tradeoffs observed between the queue-based technique suggested in [I-D.briscoe-tsvwg-cl-architecture] and a simpler token-bucket-based excess rate measurement do not appear to be a cause of substantial concern for cases when traffic aggregation is reasonably high at the bottleneck links as well as on a per ingress-egress pair basis. Details of the simulation study, as well as additional discussion of its implications are presented in section 4. Also, one mitigating consideration in favor of the simpler mechanism is that in a typical DiffServ environment, the real-time traffic is expected to be served at a higher priority and/or the target admission rate is expected to be substantially below the speed at which the real-time queue is actually served. If these assumptions hold, then there is some margin of safety for an admission control algorithm, making the requirements for admission control more forgiving to bounded errors - see additional discussion in section 4. 3.2.5. Effect on Proposed Anti-cheating Mechanisms Replacement of the queue-based admission control mechanism of [I-D.briscoe-tsvwg-cl-architecture] by an excess-rate based admission marking changing the semantics of the pre-congestion marking, and consequently interfereres with mechanisms for cheating detection discussed in [I-D.briscoe-tsvwg-re-ecn-border-cheat]. Implications of excess-rate based marking on the anti-cheating mechanisms need to Charny, et al. Expires September 6, 2007 [Page 11] Internet-Draft PCN with Single Marking March 2007 be considered. 3.2.6. Standards Implications The change of the meaning of admission marking for pre-congestion notification from the queue-based to excess-rate marking poses a question of coexistence of devices having different interpretation of admissions marking (and hence different metering and marking mechanisms in the core. The question of how and if the two mechanisms can co-exist in one PCN region has obvious impact on standardization efforts, and needs to be carefully considered. 4. Performance Evaluation Comparison 4.1. Relationship to other drafts Initial simulation results of admission and pre-emption mechanisms of [I-D.briscoe-tsvwg-cl-architecture] were reported in [I-D.briscoe-tsvwg-cl-phb]. A follow-up study of these mechanisms is presented in a companion draft draft-zhang-cl-performance-evaluation-01.txt. The current draft concentrates on a performance comparison of the admission control mechanism of [I-D.briscoe-tsvwg-cl-phb] and the token-bucket-based admission control described in section 2 of this draft. 4.2. Limitations, Conclusions and Direction for Future Work Due to time constraints, the study performed so far was limited to a small set of topologies, described in the Appendix. The key questions that have been investigated are the comparative sensitivity of the two schemes to parameter settings and the effect of traffic burstiness and of the degree of aggregation on a per ingress-egress pair on the performance of the admission control algorithms under study. The study is limited to the case where there is no packet loss. While this is a reasonable initial assumption for an admission control algorithm that is supposed to maintain the traffic level significantly below the service capacity of the corresponding queue, nevertheless future study is necessary to evaluate the effect of packet loss. 4.2.1. High Level Conclusions The results of this (preliminary) study indicate that there is a potential that a reasonable complexity/performance tradeoff may be viable for the choice of admission control algorithm. In turn, this suggests that using a single codepoint and metering technique for admission and pre-emption may be a viable option. Charny, et al. Expires September 6, 2007 [Page 12] Internet-Draft PCN with Single Marking March 2007 The key high-level conclusions of the simulation study comparing the performance of queue-based and token-based admission control algorithms are summarized below: 1. At reasonable level of aggregation at the bottleneck and per ingress-egress pair traffic, both algorithms perform reasonably well for the range of traffic models considered (see section 4.3. for detail). 2. Both schemes are stressed for small levels of ingress-egress pair aggregation levels of bursty traffic (e.g. a single video-like bursty SVD flow per ingress-egress pair). However, while the queue-based scheme results in tolerable performance even at low levels of per ingress-egress aggregation, the token-bucket-based scheme is substantially more sensitive to parameter setting than the queue-based scheme, and its performance for the high rate bursty SVD traffic with low levels of ingress-egress aggregation is quite poor unless parameters are chosen carefully to curb the error. It should be noted that the SVD traffic model used in this study is expected to be substantially more challenging for both admission and pre-emption mechanisms that the actual video traffic, as the latter is expected to be much smoother than the busrty on-off model with high peak-to-mean ratio we used. This expectation is confirmed by the fact that simulations with actual video traces reported in this version of the draft reveal that the performance of the video traces is much closer to that of VBR voice than of our crude SVD on-off model. 3. Even for small per ingress-egress pair aggregation, reasonable performance across a range of traffic models can be obtained for both algorithms (with a narrower range of parameter setting for the token-bucket based approach) . 4. The absolute value of round-trip time (RTT) or the RTT difference between different ingress-egress pair within the range of continental propagation delays does not appear to have a visible effect on the performance of both algorithms. 4.2.2. Future work This study is but the first step in performance evaluation of the token-bucket based admission control. Further evaluation should include a range of investigation, including the following: o fairness issues (how different ingress-egress pairs get access to bottleneck bandwidth) Charny, et al. Expires September 6, 2007 [Page 13] Internet-Draft PCN with Single Marking March 2007 o interactions between admission control and preemption o effect of loss of marked packets o much more 5. Appendix A: Simulation Details 5.1. Network and Signaling Model Network topologies used in this study are shown in the Figures below. The network is modeled as either Single Link (Fig. A.1), Multi Link Network with a single bottleneck (termed "RTT", Fig. A.2), or a range of multi-bottleneck topologies shown in Fig. A.3 (termed "Parking Lot"). A --- B Figure A.1: Simulated Single Link Network. A \ B - D - F / C Figure A.2: Simulated Multi Link Network. A--B--C A--B--C--D A--B--C--D--E--F | | | | | | | | | | | | | | | | | | | | | | | | | | D E F E F G H G H I J K L (a) (b) (c) Figure A.3: Simulated Multiple-bottleneck (Parking Lot )Topologies. Figure A.1 shows a single link between an ingress and an egress node, all flows enter at node A and depart at node B. In Figure A.2, A set Charny, et al. Expires September 6, 2007 [Page 14] Internet-Draft PCN with Single Marking March 2007 of ingresses (A,B,C) connected to an interior node in the network (D). The number of ingresses varied in different simulation experiments in the range of 2-100. All links have generally different propagation delays, in the range 1ms - 100 ms. This node D in turn is connected to the egress (F). In this topology, different sets of flows between each ingress and the egress converge on the single link D-F, where pre-congestion notification algorithm is enabled. The capacities of the ingress links are not limiting, and hence no PCN is enable on those. The bottleneck link D-F is modeled with a 10ms propagation delay in all simulations. Therefore the range of round-trip delays in the experiments is from 22ms to 220ms. Our simulations concentrated primarily on capacities of 'bottleneck' links with sufficient aggregation - OC3 for voice and for SVD traffic, up to 1 Gbps. In the simulation model, a call requests arrive at the ingress and immediately sends a message to the egress. The message arrives at the egress after the propagation time plus link processing time (but no queuing delay). When the egress receives this message, it immediately responds to the ingress with the current Congestion-Level-Estimate. If the Congestion-Level- Estimate is below the specified CLE-threshold, the call is admitted, otherwise it is rejected. An admitted call sends packets according to one of the chosen traffic models for the duration of the call (see next section). Propagation delay from source to the ingress and from destination to the egress is assumed negligible and is not modeled. Another type of network of interest is multi-bottleneck (or Parking Lot, PLT for short) topology. The simplest PLT with 2 bottlenecks is illustrated in Fig A.3(a). An example traffic matrix with this network on this topology is as follows: o an aggregate of "2-hop" flows entering the network at A and leaving at C (via the two links A-B-C) o an aggregate of "1-hop" flows entering the network at D and leaving at E (via A-B) o an aggregate of "1-hop" flows entering the network at E and leaving at F (via B-C) In the 2-hop PLT shown in Fig. A.3(a) the points of congestion are links A--B and B--C. Capacity of all other links is not limiting. We also experiment with larger PLT topologies with 3 bottlenecks(see Fig A.3(b)) and 5 bottlenecks ( Fig A.3 (c)). In all cases, we simulated one ingress-egress pair that carries the aggregate of "long" flows traversing all the N bottlenecks (where N is the number of bottleneck links in the PLT topology), and N ingress-egress pairs that carry flows traversing a single bottleneck link and exiting at the next "hop". In all cases, only the "horizontal" links in Fig. Charny, et al. Expires September 6, 2007 [Page 15] Internet-Draft PCN with Single Marking March 2007 A.3 were the bottlenecks, with capacities of all "vertical" links non-limiting. Propagation delays for all links in all PLT topologies are set to 1ms. Due to time limitations, other possible traffic matrices (e.g. some of the flows traversing a subset of several bottleneck links) have not yet been considered and remain the area for future investigation. Our simulations concentrated primarily on the range of capacities of 'bottleneck' links with sufficient aggregation - above 10 Mbps for voice and 622 Mbps for SVD, up to 2.4 Gbps. But we also investigated slower 'bottleneck' links down to 512 Kbps in some experiments. In the simulation model of admission control, a call request arrives at the ingress and immediately sends a message to the egress. The message arrives at the egress after the propagation time plus link processing time (but no queuing delay). When the egress receives this message, it immediately responds to the ingress with the current Congestion Level Estimate. If the Congestion Level Estimate is below the specified CLE- threshold, the call is admitted, otherwise it is rejected. For preemption, once the ingress node of a PCN region decides to preempt a call, that call is preempted immediately and sends no more packets from that time on. The life of a call outside the domain described above is not modelled. Propagation delay from source to the ingress and from destination to the egress is assumed negligible and is not modelled. 5.2. Traffic Models Four types of traffic were simulated (CBR voice, on-off traffic approximating voice with silence compression, and on-off traffic with higher peak and mean rates (we termed the latter synthetic video (SDV) as the chosen peak and mean rate was similar to that of an MPEG video stream, although no attempt was made to match any other parameters of this traffic to those of a video stream), and finally real video traces. The distribution of flow duration was chosen to be exponentially distributed with mean 1min, regardless of the traffic type. In most of the experiments flows arrived according to a Poisson distribution with mean arrival rate chosen to achieve a desired amount of overload over the configured-admission-limit in each experiment. Overloads in the range 1x to 5x and underload with 0.95x have been investigated. Note that the rationale for looking at the load 1and below is to see if any significant amount of "false rejects" would be seen (i.e. one would assume that all traffic should be accepted if the total demand is below the admission threshold). For on-off traffic, on and off periods were exponentially distributed with the specified mean. Traffic parameters for each type are summarized below: Charny, et al. Expires September 6, 2007 [Page 16] Internet-Draft PCN with Single Marking March 2007 5.2.1. CBR Voice (CBR) o Average rate 64 Kbps o Packet length 160 bytes o packet inter-arrival time 20ms 5.2.2. VBR Voice (VBR) o Packet length 160 bytes o Long-term average rate 21.76 Kbps o On Period mean duration 340ms; during the on period traffic is sent with the CBR voice parameters described above o Off Period mean duration 660ms; no traffic is sent during the off period. 5.2.3. "Synthetic Video": High Rate ON-OFF traffic with Video-like Mean and Peak Rates ("SVD") This model is on-off traffic with video-like mean-to-peak ratio and mean rate approximating that of an MPEG-2 video stream. No attempt is made to simulate any other aspects of a video stream, and this model is merely that of on-off traffic. Although there is no claim that this model represents the performance of video traffic under the algorithms in question adequately, intuitively, this model should be more challenging for a measurement-based algorithm than the actual MPEG video, and as a result, 'good' or "reasonable" performance on this traffic model indicates that MPEG traffic should perform at least as well. We term this type of traffic SVD for "Synthetic Video". o Long term average rate 4 Mbps o On Period mean duration 340ms; during the on-period the packets are sent at 12 Mbps (1500 byte packets, packet inter-arrival: 1ms) o Off Period mean duration 660m 5.2.4. Real Video Traces (VTR) We used a publicly available library of frame size traces of long MPEG-4 and H.263 encoded video obtained from http://www.tkn.tu-berlin.de/research/trace/trace.html (courtesy Telecommunication Networks Group of Technical University of Berlin). Charny, et al. Expires September 6, 2007 [Page 17] Internet-Draft PCN with Single Marking March 2007 Each trace is roughly 60 minutes in length, consisting of a list of records in the format of . Among the 160 available traces, we picked the two with the highest average rate (averaged over the trace length, in this case, 60 minutes. In addition, the two also have a similar average rate). The trace file used in the simulation is the concatenation of the two. Since the duration of the flow is much smaller than the length of the trace, we need to check how does the expect rate of flow related the trace's long term average. To do so, we simulate a number of flows starting from random locations in the trace with duration chosen to be exponentially distributed with mean 1min. The results show that the expected rate of flow is roughly the same as the trace's average. Traffic characteristics are summarized below: o Average rate 769 Kbps o Each frame is sent with packet length 1500 bytes and packet inter- arrival time 1ms o No traffic is sent between frames. 5.3. Parameter Settings 5.3.1. Queue-based settings All the queue-based simulations were run with the following Virtual Queue thresholds: o virtual-queue-rate: configured admission rate, 1/2 link speed o min-marking-threshold: 5ms at virtual-queue-rate o max-marking-threshold: 15ms at virtual-queue-rate o virtual-queue-upper-limit: 20ms at virtual-queue-rate At the egress, the CLE is computed as an exponential weighted moving average (EWMA) on an interval basis, with 100ms measurement interval chosen in all simulations. We simulated the weight ranging 0.1 to 0.9. The CLE threshold is chosen to be 0.05, 0.15, 0.25, and 0.5. 5.3.2. Token Bucket Settings The token bucket rate is set to the configured admission rate, which is half of the link speed in all experiments. Token bucket depth ranges from 64 to 512 packets. Our simulation results indicate that depth of token bucket has no significant impact on the performance of the algorithms and hence, in the rest of the section, we only present Charny, et al. Expires September 6, 2007 [Page 18] Internet-Draft PCN with Single Marking March 2007 the result with 256 packets bucket depth. The CLE is calculated in the same way as in queue-based approach with weights from 0.1 to 0.9. The CLE thresholds are chosen to be 0.0001, 0.001, 0.01, 0.05 in this case. Note that the since meaning of the CLE is different for the Token bucket and queue-based algorithms, so there is no direct correspondence between the choice of the CLE thresholds in the two cases. 5.4. Simulation Details To evaluate the performance of the algorithms, we recorded the actual admitted load at a granularity of 50ms, from which the mean admitted load over the duration of the simulation run can be computed. We verified that the actual admitted load at any time does not deviate much from the mean admitted load in each experiment by computing the coefficient of variation (CV is consistently 0.07 for CBR, 0.15 for VBR, 0.17 for VTR and 0.51 for SVD for all experiments). Finally, the performance of the algorithms is evaluated using a metric called over-admission-percentage, which is calculated as a percentage difference between the mean admitted load and the configured admission rate. Given reasonably small deviation of the admitted rate from the mean admitted in the experiments, this seems reasonable. 5.4.1. Queue-based Results We found that the virtual-queue admission control algorithm works reliably with the range of parameters we simulated, for all four types of traffic. In addition, for both CBR, VBR and VTR traffic, the performance is insensitive to the parameters change under all tested topologies. Table A.1 summarized over-admission-percentage values from 15 experiments with different [weight, CLE threshold] settings for CBR, VBR and VTR traffic. For the single bottleneck topologies (S. Link and RTT) the overload column represents the ratio of the demand on the bottleneck link to the configured admission threshold. For parking lot topologies we report the worst case result across all bottlenecks. While in our simulations we tested the range of overload from 0.95 to 5, we present here only the results of the endpoints of this overload interval. For the intermediate values of overload the results are even closer to the expected ones than at the two boundary loads. The statistics show that for CBR, VBR and VTR traffic these over- admission-percentage values are rather similar across these traffic types, with the admitted load roughly staying within -2%+2% range of Charny, et al. Expires September 6, 2007 [Page 19] Internet-Draft PCN with Single Marking March 2007 the desired admission threshold, with quite limited variability across the experiments (see the Standard Deviation column). Note also that this is not always true for all experiments with 0.95 average load due to the variability of traffic generation. Charny, et al. Expires September 6, 2007 [Page 20] Internet-Draft PCN with Single Marking March 2007 ---------------------------------------------------------- | Over Admission Perc Stats | Over | Topo | Type | | Min | Mean | Max | SD | Load | | | ---------------------------------------------------------- | 0 | 0 | 0 | 0 | 0.95 | | | |------------------------------------------| S.Link | | | 0.224 | 0.849 | 1.905 | 0.275 | 5 | | | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | | | |------------------------------------------| RTT | CBR | | 0.200 | 0.899 | 1.956 | 0.279 | 5 | | | |---------------------------------------------------| | | -1.06 | -0.33 | -0.15 | 0.228 | 0.95 | | | |------------------------------------------| PLT | | | -0.58 | 0.740 | 1.149 | 0.404 | 5 | | | |---------------------------------------------------------- | -1.45 | -0.98 | -0.86 | 0.117 | 0.95 | | | |------------------------------------------| S.Link | | | -0.07 | 1.405 | 1.948 | 0.421 | 5 | | | |---------------------------------------------------| | | -1.56 | -0.80 | -0.69 | 0.16 | 0.95 | | | |------------------------------------------| RTT | VBR | | -0.11 | 1.463 | 2.199 | 0.462 | 5 | | | |---------------------------------------------------| | | -3.49 | -2.23 | -1.80 | 0.606 | 0.95 | | | |------------------------------------------| PLT | | | -1.37 | 0.978 | 1.501 | 0.744 | 5 | | | ---------------------------------------------------------- | 0 | 0 | 0 | 0 | 0.95 | | | |------------------------------------------| S.Link | | | -0.53 | 1.004 | 1.539 | 0.453 | 5 | | | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | | | |------------------------------------------| RTT | VTR | | -0.21 | 1.382 | 1.868 | 0.503 | 5 | | | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | | | |------------------------------------------| PLT | | | -0.86 | 0.686 | 1.117 | 0.452 | 5 | | | ---------------------------------------------------------- Table A.1 Summarized performance for CBR, VBR and VTR across different settings. For SVD, the algorithms does show certain sensitivity to the tested parameters. Table A.2 recorded the over-admission-percentage for each combination of weights and CLE threshold. Charny, et al. Expires September 6, 2007 [Page 21] Internet-Draft PCN with Single Marking March 2007 ------------------------------------------------------------------- | | EWMA Weights | Over | Topo | | | 0.1 | 0.3 | 0.5 | 0.7 | 0.9 | Load | | ------------------------------------------------------------------- | 0.05 | -4.87 | -3.05 | -2.92 | -2.40 | -2.40 | | | | 0.15 | -3.67 | -2.99 | -2.40 | -2.40 | -2.40 | 0.95 | | | 0.25 | -2.67 | -2.40 | -2.40 | -2.40 | -2.40 | | | | -------------------------------------------------------| Single | | C 0.05 | -4.03 | 2.52 | 3.45 | 5.70 | 5.17 | | Link | | L 0.15 | -0.81 | 3.29 | 6.35 | 6.80 | 8.13 | 5 | | | E 0.25 | 2.15 | 5.83 | 6.81 | 8.62 | 7.95 | | | | ---------------------------------------------------------------- | T 0.05 | -11.77 | -8.35 | -5.23 | -2.64 | -2.35 | | | | H 0.15 | -9.71 | -7.14 | -2.01 | -2.21 | -1.13 | 0.95 | | | R 0.25 | -5.54 | -6.04 | -3.28 | -0.88 | -0.27 | | | | E -------------------------------------------------------| RTT | | S 0.05 | -5.04 | -0.65 | 4.21 | 6.65 | 9.90 | | | | S 0.15 | -1.02 | 1.58 | 7.21 | 8.24 | 10.07 | 5 | | | H 0.25 | -0.76 | 1.96 | 7.43 | 9.66 | 11.26 | | | | E ---------------------------------------------------------------- | L 0.05 | -2.51 | -0.85 | -0.63 | 0.025 | -0.00 | | | | D 0.15 | -1.50 | -0.63 | -0.02 | 0.052 | -0.02 | 0.95 | | | 0.25 | -0.26 | 0.122 | 0.041 | -0.02 | 0.132 | | | | -------------------------------------------------------| PLT | | 0.05 | -3.50 | 0.422 | 1.899 | 3.339 | 3.770 | | | | 0.15 | -1.04 | 2.016 | 3.251 | 3.880 | 3.991 | 5 | | | 0.25 | 0.449 | 2.965 | 3.066 | 4.107 | 4.737 | | | ------------------------------------------------------------------- Table A.2 Over-admission-percentage for SVD It follows from these results that while performance is tolerable across the entire range of parameters, choosing the CLE and EWMA weights in the middle of the tested range appear to be more beneficial for the overall performance across the chosen range of overload, assuming the chosen values for the remaining parameters. The high level conclusion that can be drawn from Table A.2. is that (predictably) high peak-to-mean ratio SVD traffic is substantially more stressful to the queue-based admission control algorithm, but a set of parameters exists that keeps the overadmission within about -3% - +10% of the expected load even for the bursty SVD traffic. Note that for SVD traffic these results hold even though there is no aggregation at all on a per-ingress-egress pair in the chosen RTT topology there is only a single SVD flow per ingress. In addition, there seems to be no visible influence by multiple bottleneck topology, as the results appears to be comparable to the ones in single bottleneck cases. (Note that it may seem from the data in A.2, PLT out-performs the Single Link. The reason is that the Charny, et al. Expires September 6, 2007 [Page 22] Internet-Draft PCN with Single Marking March 2007 bottleneck links in PLT happen to be twice the size of the ones in SingleLink cases. Given the same admission threshold, this implies that level of aggregation in PLT is twice as much as in the SingleLink. Hence, the better results in PLT should be viewed as the effect of the aggregation rather than the effect multi-bottleneck topology.) 5.4.2. Token Bucket-based Results Just as for the case of the queue-based algorithm, under the under- loaded conditions for voice-like CBR, VBR and VTR traffic the sensitivity to the tested parameters remains limited for the token- bucket as well (the latter is summarized in Table A.3). ---------------------------------------------------------- | Over Admission Perc Stat | Load | Topo | Type | | Min | Mean | Max | SD | | | | ---------------------------------------------------------- | 0 | 0 | 0 | 0 | 0.95 | S.Link | | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | RTT | CBR | |---------------------------------------------------| | | -1.17 | -0.24 | 0.023 | 0.294 | 0.95 | PLT | | ---------------------------------------------------------- | -2.00 | -0.78 | -0.95 | 0.268 | 0.95 | S.Link | | |---------------------------------------------------| | | -2.83 | -0.70 | -1.20 | 0.510 | 0.95 | RTT | VBR | |---------------------------------------------------| | | -6.19 | -2.43 | -1.32 | 1.223 | 0.95 | PLT | | ---------------------------------------------------------- | 0 | 0 | 0 | 0 | 0.95 | S.Link | | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | RTT | VTR | |---------------------------------------------------| | | 0 | 0 | 0 | 0 | 0.95 | PLT | | ---------------------------------------------------------- Table A.3 Summarized performance for CBR, VBR and VTR across different settings for under-loaded conditions. However, for the overload conditions (overload greater than 1), the token bucket-based admission control algorithm shows substantially higher sensitivity to the parameter settings compared to the virtual queue based algorithm. Table A.4 shows over-admission-percentage for different settings. It is important to note here that for the token bucket-based admission control no traffic will be marked until the rate of traffic exceeds the configured admission rate by the chosen CLE. As a consequence, even with the ideal performance of the algorithms, the over-admission-percentage will not be 0, rather it is Charny, et al. Expires September 6, 2007 [Page 23] Internet-Draft PCN with Single Marking March 2007 expected to equal to CLE threshold if the algorithm performs as expected. Therefore, a more meaningful metric for the token-based results is actually the over-admission-percentage (listed below) minus the corresponding (CLE threshold * 100). For example, for CLE = 0.05, one would expect that 5% overadmission is inherently embedded in the algorithm, with the algorithm by design reacting to 5% overload (or more) only. Hence, with CLE = 0.05 a 10% over-admission in the token-bucket case should be compared to a 5% overadmission in the queue-based algorithm. When comparing the performance of token bucket (with the adjusted over-admission-percentage) to its corresponding virtual queue result, we found that token bucket performs only slightly worse for voice-like CBR VBR, and VTR traffic. The results for SVD traffic require some additional commentary. Note from the results in Table A.4. that even for SVD traffic, in the Single Link topology the performance of the token-based solution is comparable to the performance of the queue-based scheme in table A.2, (adjusted by the CLE as discussed above). However, for the RTT topology, especially for the larger EWMA weights, the performance for SVD traffic becomes very bad, with up to 42% (adjusted by CLE) over- admission in a high overload situation (5x). We investigated two potential causes of this drastic degradation of performance by concentrating on two key differences between the Single Link and the RTT topologies: the difference in the round-trip times and the degree of aggregation in a per ingress-egress pair aggregate. To investigate the effect of the difference in round-trip times, we also conducted a subset of the experiments described above using the RTT topology that has the same RTT across all ingress-egress pairs rather than the range of RTTs in one experiment. We found out that neither the absolute nor the relative difference in RTT between different ingress-egress pairs appear to have any visible effect on the over-load performance or the fairness of both algorithms (we do not present these results here as their are essentially identical to those in Table A.4). In view of that and noting that in the RTT topology we used for these experiments for the SVD traffic, there is only 1 highly bursty flow per ingress, we believe that the severe degradation of performance in this topology is directly attributable to the lack of traffic aggregation on the ingress-egress pair basis. We also note that even for this highly challenging scenario, it is possible to find a range of parameters that limit the overadmission case for SVD traffic to quite a reasonable range of -3% + 10% (adjusted by the CLE). Luckily, these are the same parameter settings that work quite well for the other types of traffic tested. The overall performance on the multiple-bottleneck topology, for all types of traffic, is comparable to the ones on the SingleLink, just as shown in the queue-based results. Again, the results for the PLT Charny, et al. Expires September 6, 2007 [Page 24] Internet-Draft PCN with Single Marking March 2007 topology may appear better than those of the SingleLink in the table below. As discussed earlier, this is due to the fact that the bottleneck capacity of the PLT topology in these experiments is higher than that of the SingleLink and RTT, topologies (2.4Gbps vs 1Gbps), so the bottleneck aggregation is higher for PLT than for both single bottleneck topologies. The ingress-egress aggregation of the PLT topology corresponds to that of a SingleLink. ------------------------------------------------------------------- | | EWMA Weights |Over| Topo | Type| | | 0.1 | 0.3 | 0.5 | 0.7 | 0.9 |Load| | | ------------------------------------------------------------------- | C 0.0001| -0.99 | 0.09 | 0.24 | 0.41 | 0.43 | | | | | L 0.001 | 0.02 | 0.37 | 0.43 | 0.46 | 0.45 | 5 | S. | | | E 0.01 | 1.37 | 1.32 | 1.32 | 1.31 | 1.31 | | Link | | | ---------------------------------------------------------- | | T 0.0001| 6.50 | 7.96 | 8.37 | 8.42 | 8.84 | | | | | H 0.001 | 7.07 | 8.54 | 8.65 | 8.55 | 8.66 | 5 | RTT | CBR | | R 0.01 | 7.93 | 9.08 | 8.71 | 8.63 | 9.40 | | | | | S ---------------------------------------------------------- | | H 0.0001| -1.88 | 0.21 | 0.58 | 0.65 | 0.62 | | | | | L 0.001 | -0.31 | 0.69 | 0.63 | 0.61 | 0.56 | 5 | PLT | | | D 0.01 | 2.032 | 1.98 | 1.97 | 1.99 | 1.96 | | | | ------------------------------------------------------------------- ------------------------------------------------------------------- | C 0.0001| -2.95 | -1.39 | -0.63 | 0.23 | 0.78 | | | | | L 0.001 | -1.51 | -0.23 | 0.44 | 0.63 | 1.39 | 5 | S. | | | E 0.01 | 1.37 | 2.01 | 2.29 | 2.60 | 2.76 | | Link | | | ---------------------------------------------------------- | | T 0.0001| -1.93 | -0.23 | 0.99 | 2.09 | 3.38 | | | | | H 0.001 | -0.75 | 0.89 | 2.07 | 3.12 | 4.27 | 5 | RTT | VBR | | R 0.01 | 1.91 | 3.42 | 4.35 | 5.36 | 6.38 | | | | | S ---------------------------------------------------------- | | H 0.0001| -3.78 | -0.57 | 0.35 | 1.08 | 1.82 | | | | | L 0.001 | -1.64 | 0.46 | 1.28 | 1.89 | 2.37 | 5 | PLT | | | D 0.01 | 1.871 | 2.74 | 3.24 | 3.39 | 3.86 | | | | ------------------------------------------------------------------- ------------------------------------------------------------------- | C 0.0001| -2.37 | 0.00 | 0.79 | 0.83 | 1.07 | | | | | L 0.001 | -0.64 | 0.67 | 0.79 | 1.04 | 1.08 | 5 | S. | | | E 0.01 | 1.59 | 1.64 | 1.66 | 1.79 | 2.04 | | Link | | | ---------------------------------------------------------- | | T 0.0001| -1.09 | 0.86 | 1.29 | 1.57 | 1.98 | | | | | H 0.001 | 0.00 | 1.39 | 1.63 | 1.86 | 2.58 | 5 | RTT | VTR | | R 0.01 | 1.99 | 2.32 | 2.88 | 3.54 | 4.35 | | | | | S ---------------------------------------------------------- | | H 0.0001| -1.99 | 0.09 | 0.58 | 0.96 | 1.15 | | | | | L 0.001 | -0.55 | 0.57 | 1.09 | 1.30 | 1.49 | 5 | PLT | | Charny, et al. Expires September 6, 2007 [Page 25] Internet-Draft PCN with Single Marking March 2007 | D 0.01 | 2.22 | 2.44 | 2.42 | 2.61 | 2.65 | | | | ------------------------------------------------------------------- ------------------------------------------------------------------- | 0.0001| -10.67|-10.58 | -7.95 | -6.27 | -4.99 | | | | | 0.001 | -8.67 | -8.04 | -7.61 | -4.37 | -2.89 |0.95| | | | 0.01 | -4.28 | -2.59 | -4.44 | -2.13 | -2.20 | | S. | | | C ---------------------------------------------------| Link | | | L 0.0001| -16.36|-10.24 | -6.50 | -2.17 | 2.74 | | | | | E 0.001 | -10.54| -5.63 | -2.70 | 0.94 | 3.54 | 5 | | | | 0.01 | -4.11 | 1.26 | 5.38 | 5.75 | 8.82 | | | | | ---------------------------------------------------------- | | T 0.0001| -15.83|-10.35 | -2.96 | 0.17 | 5.42 | | | | | H 0.001 | -12.82| -7.62 | -0.47 | 2.24 | 6.59 |0.95| | | | R 0.01 | -6.17 | -0.11 | 2.16 | 5.28 | 10.34 | | | | | E ---------------------------------------------------| RTT | SVD | | S 0.0001| -8.51 | 1.86 | 11.14 | 22.51 | 30.24 | | | | | S 0.001 | -4.80 | 1.49 | 15.35 | 24.56 | 33.96 | 5 | | | | H 0.01 | 0.56 | 8.26 | 25.71 | 35.63 | 42.72 | | | | | O ---------------------------------------------------------- | | L 0.0001| -12.35| -8.73 | -7.46 | -5.97 | -5.95 | | | | | D 0.001 | -9.06 | -7.66 | -5.99 | -5.19 | -4.77 |0.95| | | | 0.01 | -5.13 | -4.77 | -4.62 | -3.54 | -3.52 | | | | | ---------------------------------------------------| PLT | | | 0.0001| -10.07| -5.05 | -3.17 | 0.75 | 2.138 | | | | | 0.001 | -7.41 | -3.38 | -0.53 | 1.89 | 5.071 | 5 | | | | 0.01 | -0.81 | 2.816 | 5.115 | 6.03 | 6.421 | | | | ------------------------------------------------------------------- Table A.4. Token bucket admission control performance. An additional differences in token-bucket case vs the queue-based admissions in the PLT topology case revealed in our experiments is that there appears to be a consistent relationship between the position of the bottleneck link (how far downstream it is) and its over-admission-percentage. In Table A.5, we show a snapshot of the behavior with 5 bottleneck topology. Here, the over-admission- percentage displayed is an average across all 15 experiments with different [weight, CLE] setting. (We do observe the same behavior in each of the individual experiment, hence providing a summarized statistics does not invalidate the results). The data shows the further downstream the bottleneck is, the more it tends to over- admit, regardless the type of the traffic. The exact cause of this phenomenon is yet to be explained, but the effect of it seems to be insignificant in magnitude, at least in the experiments we ran. Charny, et al. Expires September 6, 2007 [Page 26] Internet-Draft PCN with Single Marking March 2007 -------------------------------------------------------- | Traffic | Bottleneck LinkId | Over | | Type | 1 | 2 | 3 | 4 | 5 | Load | -------------------------------------------------------- | CBR | 0.270 | 0.421 | 0.529 | 0.669 | 0.791 | 5 | |-------------------------------------------------------- | VBR | 0.152 | 0.512 | 0.715 | 0.901 | 1.169 | 5 | |-------------------------------------------------------- | VTR | 0.350 | 0.492 | 0.756 | 0.874 | 1.125 | 5 | -------------------------------------------------------- Table A.5 Summarized performance for CBR, VBR and VTR across the links in the PLT topology for Token Bucket Admission 6. IANA Considerations This document places no requests on IANA. 7. Security Considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.briscoe-tsvwg-cl-architecture] Briscoe, B., "An edge-to-edge Deployment Model for Pre- Congestion Notification: Admission Control over a DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 (work in progress), October 2006. [I-D.briscoe-tsvwg-cl-phb] Briscoe, B., "Pre-Congestion Notification marking", draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006. [I-D.briscoe-tsvwg-re-ecn-border-cheat] Briscoe, B., "Emulating Border Flow Policing using Re-ECN on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01 Charny, et al. Expires September 6, 2007 [Page 27] Internet-Draft PCN with Single Marking March 2007 (work in progress), June 2006. [I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-03 (work in progress), October 2006. [I-D.davie-ecn-mpls] Davie, B., "Explicit Congestion Marking in MPLS", draft-davie-ecn-mpls-01 (work in progress), October 2006. [I-D.lefaucheur-emergency-rsvp] Faucheur, F., "RSVP Extensions for Emergency Services", draft-lefaucheur-emergency-rsvp-02 (work in progress), June 2006. Authors' Addresses Anna Charny Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA Email: acharny@cisco.com Xinyang (Joy) Zhang Cisco Systems, Inc. and Cornell University 1414 Mass. Ave. Boxborough, MA 01719 USA Email: joyzhang@cisco.com Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 , 400 Avenue de Roumanille, 06410 Biot Sophia-Antipolis, France Email: flefauch@cisco.com Charny, et al. Expires September 6, 2007 [Page 28] Internet-Draft PCN with Single Marking March 2007 Vassilis Liatsos Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA Email: vliatsos@cisco.com Charny, et al. Expires September 6, 2007 [Page 29] Internet-Draft PCN with Single Marking March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Charny, et al. Expires September 6, 2007 [Page 30]