Network Working Group J. Babiarz Internet-Draft X-G. Liu Intended status: Informational K. Chan Expires: August 27, 2007 Nortel February 23, 2007 Explicit PCN Marking draft-babiarz-pcn-explicit-marking-00 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 August 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In this document, we propose to the PCN WG for review, discussion and evaluation of a method for marking real-time packets to indicate that removal (preemption) of excess real-time traffic from the network is needed. First, we define the marking behavior in the interior node followed with a brief description of how this marking would work in the edge-to-edge and application-control deployment models with simulations results for different conditions and traffic mixes. Babiarz, et al. Expires August 27, 2007 [Page 1] Internet-Draft Explicit PCN Marking February 2007 Then, we discuss the simulation results for voice, both constant rate and variable rate with silence suppression, and variable rate MPEG-4 like video traffic with large and small number of flows at the congestion point. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology used in this Document . . . . . . . . . . 3 2. Explicit Flow Termination Marking . . . . . . . . . . . . . . 4 2.1. Operation in Edge-to-Edge Solution . . . . . . . . . . . . 6 2.2. Operation in Application Controlled Solution . . . . . . . 6 2.3. Differences of this Approach . . . . . . . . . . . . . . . 7 2.4. Characteristics of Proposed Marking . . . . . . . . . . . 8 3. Simulation Results . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Simulation Setup for Voice Traffic . . . . . . . . . . . . 10 3.2. Large Number of Voice Flows . . . . . . . . . . . . . . . 11 3.3. Small Number of Voice Flows . . . . . . . . . . . . . . . 12 3.4. Large Number of Voice Flows with Packet Loss . . . . . . . 13 3.5. Small Number of Voice Flows with Packet Loss . . . . . . . 14 3.6. Corner Voice Cases Studied . . . . . . . . . . . . . . . . 15 3.7. Simulation Setup for Video Traffic . . . . . . . . . . . . 16 3.8. Excess Load Marking Algorithm Used in Simulation . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Informative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Babiarz, et al. Expires August 27, 2007 [Page 2] Internet-Draft Explicit PCN Marking February 2007 1. Introduction Pre-Congestion Notification (PCN) builds on the concepts of [RFC3168], "The addition of Explicit Congestion Notification (ECN) to IP". Pre-Congestion Notification is applied to real-time flows (such as voice, video and multimedia streaming) in DiffServ-enabled networks. The reader is referred to [I-D.briscoe-tsvwg-cl-architecture] and [I-D.babiarz-pcn-sip-cap] for description of how PCN enables "pre" congestion control through two procedures, flow admission control and flow termination (preemption). Flow admission control determines whether a new flow can be added into the network, whereas flow termination reduces the current traffic load by terminating selected flows. Note this document focuses on defining a marking behavior that explicitly indicates what *flows* (not packets or measured traffic rate) need to be removed from the congested path. This document provides an alternative for excess load (preemption) marking to what is documented in [I-D.briscoe-tsvwg-cl-phb]. The approach defined in this document explicitly marks a packet belonging to a flow that is in excess of the configured supportable service rate. The explicit marking of a packet is an indication that the flow is passing through a node where congestion has been encountered. We first discuss the metering and excess load (preemption) marking that is performed by the PCN capable router, followed with a brief description of action that needs to be taken in the edge nodes (boundary or hosts) to complete the excess load reduction action. Then we identify differences between the two approaches and explain the benefits of this marking approach. Finally we provide simulation results with explanation for the explicit excess load marking approach. 1.1. Requirements Notation 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 [RFC2119]. 1.1.1. Terminology used in this Document Here we provide a brief definition of the terminology used in this document as it applies to the PCN work. o PCN - Pre-Congestion Notification is a method for detecting the onset of congestion (before any packets are significantly queued or lost) and signalling to the edge nodes or endpoints via packet marking of the IP header. This method is applicable to real-time Babiarz, et al. Expires August 27, 2007 [Page 3] Internet-Draft Explicit PCN Marking February 2007 inelastic traffic, e.g., voice. The marking of bits in the IP header will need to be standardized. o ECN Field - Refers to the use of the standardized two bit field in the IP header that is used for signalling Explicit Congestion Notification [RFC3168]. In the PCN framework the ECN field maybe reused to signal two levels of Pre-Congestion Notification Marking [I-D.briscoe-tsvwg-cl-phb]. o Admissible Rate - A bandwidth or resource threshold configured in network elements that when crossed marking of packets occurs to indicate that additional flow/session should not be admitted on to that path. In Pre-Congestion Notification Marking [I-D.briscoe-tsvwg-cl-phb] this is called the "configured- admission-rate". o Supportable Rate - A bandwidth or resource threshold configured in network elements that when crossed marking of packets occurs to indicate that on-path traffic has exceeded the configured service level. Normally, this would be before any significant queuing or packet loss occurs for traffic being forwarded by this service class. In Pre-Congestion Notification Marking [I-D.briscoe-tsvwg-cl-phb] this is called the "configured- preemption-rate". o Service class - By service class we mean a grouping of packets belonging to one or more applications or services that generated traffic with similar characteristics and requiring similar QoS treatment. See [RFC4594] for details. o Endpoint - Application controlled media device such as a phone, a media gateway or a multi media terminal or host. o Admission Control - It is the action of blocking the adding of new flows or sessions in to the network in the attempt to prevent overload condition. o Preemption - During an overload condition, it is the action of removing excess traffic by randomly terminating flows or sessions. Some solution may have additional policies where termination of flows or sessions is performed in some controlled hierarchical fashion. 2. Explicit Flow Termination Marking We propose a simple excess load (preemption) marking approach for the PCN mechanism that explicitly identifies the real-time flow that is Babiarz, et al. Expires August 27, 2007 [Page 4] Internet-Draft Explicit PCN Marking February 2007 passing through an interior node (router) experiencing congestion. The metering and marking procedure for excess load (preemption) is described using token bucket approach, with octets being the unit of the token bucket size and its operations. The defined behavior can also be realized using virtual queue approach. o PCN capable routers perform metering of real-time packets that are identified as being PCN capable and mark packets when token bucket runs out of tokens. o Tokens are added to the token bucket at "Supportable Rate" (also called configured-preemption-rate), which is below the link rate and the relevant service class scheduling rate. o Tokens are removed when a real-time packet arrives; the amount removed is the same as the number of octets in the packet. o When the token bucket becomes empty or goes negative, the packet is marked and "x" tokens are added to the token bucket. The general guideline is that "x" should be several times larger than the octet size of packets being serviced. The amount of tokens added, "x", controls the aggressiveness of marking. The lager the value of "x", the amount of tokens added to the token bucket each time a packet is marked, the longer before the next packet is marked assuming that current traffic load is greater than Supportable Rate. When traffic level drops below Supportable Rate no packets are marked. In summary, a packet is marked every "x" octets of traffic that exceeds the Supportable Rate. In Figure 1 below the metering and marking procedure is visualized. +-----------------------------+ Yes Packet ------>| Are there sufficient tokens |-------> Forward arrives | in the token bucket? | packet +-----------------------------+ | | No | \/ +---------------------------+ | Mark packet and add "x" | | tokens to token bucket |-------> Forward +---------------------------+ packet Figure 1: Router Processing to Support Excess Flow Marking Babiarz, et al. Expires August 27, 2007 [Page 5] Internet-Draft Explicit PCN Marking February 2007 If traffic is sustained at a level greater than the Supportable Rate, then a packet is excess load (preemption) marked every "x" octets of traffic exceeding the Supportable Rate. However, a short burst of traffic that is greater than the Supportable Rate (measured over the burst) may not trigger any excess load (preemption) marking if the burst is sufficiently short that the token bucket doesn't run out of tokens. 2.1. Operation in Edge-to-Edge Solution The explicit excess load (preemption) marking approach can be used in the edge-to-edge framework described in [I-D.briscoe-tsvwg-cl-architecture], in the following way. First, as real-time packets travel across the edge-to-edge CL- region, PCN capable routers that encounter onset of congestion mark packets, as per algorithm described earlier. When the egress gateway of the region receives a excess load (preemption) marked packet, it sends a message to the ingress gateway indicating the IP source/destination address and port number of the market packet. The ingress gateway invokes the defined excess load (preemption) process for the identified flow. Under extreme overload conditions (link failures) where large number of flows may require termination, the egress gateway may collect IP source/destination address and port number of excess load (preemption) marked packet over a period of time and then sent all the information to the ingress gateway in one message. This approach reduces the number of messages sent between the egress and ingress gateways. Also if needed, the egress gateway of the region may count excess load (preemption) marked packet that it receives per ingress-egress aggregate, and calculate the amount of traffic that needs to be removed for each ingress-egress aggregate (number of excess load (preemption) marked packet received multiplied by "x" octets used in routers for excess load marking). The egress gateway signals to ingress gateway indicating the amount of traffic that needs to be removed over the measurement time interval. The excess load reduction process repeats until all the excess traffic flowing through the congestion point is removed. 2.2. Operation in Application Controlled Solution The explicit excess load (preemption) marking approach can also be used in the application-control framework described in [I-D.babiarz-pcn-sip-cap] in the following way. As real-time packets travel across the network, PCN capable routers that encounter onset of congestion mark packets, as per algorithm described earlier. Babiarz, et al. Expires August 27, 2007 [Page 6] Internet-Draft Explicit PCN Marking February 2007 When the endpoint (egress host) receives an excess load (preemption) marked packet, it invokes the defined excess load reduction (preemption) policy for that flow. Normally the endpoint verifies that the excess load (preemption) marked packet belongs to a flow that can be terminated. If the policy allows the flow to be terminated, the egress host initiates the flow termination procedure by signalling via application control signalling e.g., SIP to the ingress host (flow origination) to terminate the flow or stop sending packets. 2.3. Differences of this Approach The differences between explicit marking approach described by this document versus what is in [I-D.briscoe-tsvwg-cl-phb] the "marking draft" for excess load (preemption) are: In the "marking draft" any packet that exceeds the supportable rate is marked, where with the explicit marking approach only a packet every "x" octets of excess traffic is marked. The marking approach that is proposed in this draft is similar to what is used in [RFC3168], where a packet is marked based on average queue length exceeding a configured threshold, except that our approach does not use average queue length. The packet marking in [RFC3168] indicates for TCP application that source needs to halve its effective rate whereas with PCN, the feedback indicates excess load reduction through reducing the sending rate or through termination of that real-time flow. With PCN, flow termination action is more aggressive against the selected flows but the gain is that it enables the full QoS of the remaining flows to be preserved. Currently with the "marking draft" approach, when the egress gateway of the region detects a Pre-emption Marked packet, it measures the rate of real-time traffic *excluding* any packets that are Pre- emption Marked. Hence it measures the amount of traffic that the network can actually support safely (which is term Sustainable- Aggregate-Rate). The measurement is made for traffic from a particular ingress gateway, and then reported to that ingress gateway. When it receives this message, the ingress gateway measures the ingress-aggregate-rate of real-time traffic that is being sent towards the particular egress gateway. If this measured ingress- aggregate-rate exceeds the Sustainable-Aggregate-Rate, then the ingress gateway pre-empts sufficient number of real-time flow(s) to bring down the ingress-aggregate-rate to (approximately) the Sustainable-Aggregate-Rate. It should be pointed out that a deployment solution wishing to Babiarz, et al. Expires August 27, 2007 [Page 7] Internet-Draft Explicit PCN Marking February 2007 compute the excess rate using the explicit excess load marked where a marked packet represents "x" bytes of excess traffic, can do so if "x" is known. 2.4. Characteristics of Proposed Marking Here we highlight some of the characteristics and benefits that explicit excess load marking approach has: 1. Works with Equal Cost Multipath (ECMP) routing in the network (without additional complexity in the gateways). With the explicit excess load marking approach, a marked packet belongs to a flow that was routed through congested router. 2. Works reasonable well in presence of low and high packet loss. (See simulation results details). Packet loss only intrudes small delta delay for excess load reduction to be completed. If a marked packet is lost and the overload is still presented, the congested router will mark another packet. 3. This approach works well with small and large number of flows, constant bit rate, variable rate (on-off voice) and variable rate MPEG-4 like traffic. To date simulation results [SIM-07] indicate that this marking approach is not that sensitive to different flow counts and traffic characteristics. 4. Works reasonably well in presence of multiple congestion points in the path. The explicit excess load marking approach has an exponential decay marking property, therefore marking frequency decreases as the traffic load is decreases and it approaches the supportable rate. In other words, flow termination slows down as the excess load approaches that supportable rate traffic level. 5. With mixed traffic of different rates and packet sizes, the explicit excess load marking approach marks high BW flows more aggressively. Therefore after link failure condition the result is that more flows as total can be supported with the aggregate traffic being below the supportable rate. 6. Another benefit of explicit excess load marking approach and its exponential decay property is that it works well with bidirectional flows. When a bidirectional flows is terminated, excess load is removed from the congested router(s), therefore reducing the frequency of marking. This marking approach works with unidirectional and bidirectional flows (without additional complexity in the gateways). Babiarz, et al. Expires August 27, 2007 [Page 8] Internet-Draft Explicit PCN Marking February 2007 7. Works well over a wide range of round-trip times (RTTs) that are reasonable for real-time traffic. See [SIM-07] simulation results with different RTTs. The "x" value should be configured so that it is greater than the number of octets transmitted by a flow in RTT. For aggregation of voice flows that have various rates, using the mean rate should produce reasonable results. More work is required before any guidelines for "x" can be stated. 8. Stable behavior under most operating conditions. Simulations show very good accuracy both for constant rate and variable rate traffic with small and large number of overload conditions. 9. This approach works well in gateway-to-gateway and host-to-host deployment models. 10. The explicit excess load marking behavior is friendly to behavior in [RFC3168] and should PCN flow encounter a router that performs [RFC3168] marking, it would provide some protection against congestion. A packet belonging to a PCN flow that is CE marked would invoke the excess load reduction procedure for that flow. 11. If the egress edge node (gateway) reports which flows that need to be removed (preempted) versus bandwidth, than any reasonable value for "x" can be used. The value for "x" and the algorithm do not need to be standardized, but only the metering and marking behavior. Different algorithms may be used to obtain the described metering and marking behavior. 3. Simulation Results In this section we will provide explanation of our simulation setup and results. Detailed explanations and graphed results from the simulations can be viewed in [SIM-07] (http://standards.nortel.com/pcn/Simulation_EPCN.pdf). In Section 3.1 we provide a brief explanation of the simulations setup that was used to test flow termination of constant and variable rate (silence superseded) voice traffic, Section 3.2 to Section 3.6 discusses results of the voice-related simulation, and Section 3.7 briefly discusses the preliminary video-related simulation results. All the simulations were performed using the token bucket algorithm documented in Section 3.8. Note: Since the terminology for this work is evolving, we provide a brief explanation of terms used in the simulation results. Babiarz, et al. Expires August 27, 2007 [Page 9] Internet-Draft Explicit PCN Marking February 2007 Preemption = flow termination Preemption Threshold = Supportable Rate Preemption Level = traffic above this rate is marked as excess. Same as Supportable Rate. PM flag = explicit marking of packet to indicated excess load. In the simulation, the router sets both ECN bits to "11" in the IP header. Preemption Time = RTT + processing time of termination of a flow. This is how long it takes before a marked flow stops sending packets. pcn_px = represents marking a packet every "x" bytes of excess rate. 3.1. Simulation Setup for Voice Traffic Our simulations were done using OPNET see simulation results at [SIM-07] (http://standards.nortel.com/pcn/Simulation_EPCN.pdf). Pages 2 through 6 [SIM-07] provide details of the simulation setup: o Pages 2 and 3 [SIM-07] describe simulation setup. The source traffic generator (SRC) block produces flows and each flow has a flow ID, with each flow sending packets at its codec configured rate. Start time of packets between flows is asynchronous, representing different sources. Codec mix and number of flows enabled is programmable. o Pages 4 and 5 [SIM-07] describe characteristics of the 4 voice codecs used in the simulations and explanation of two methods used to simulate fail in the network to cause flow termination (preemption) to be invoked. During a failure, 100% of additional traffic is introduced on to the path (router that is performing metering and marking of packets). The additional load was introduced using two models. The first failure emulates a fast reroute, were all traffic is switched instantaneously. The second failure on the graph represents a condition where reroutes takes some time. We configured the simulation so that 80% of new traffic is added within 1 second and the remaining 20% within additional 5 seconds. Our simulations generated a traffic mix ratio of up to 15 to 1 for voice. The highest sending rate is 15 times the smallest. Babiarz, et al. Expires August 27, 2007 [Page 10] Internet-Draft Explicit PCN Marking February 2007 3.2. Large Number of Voice Flows First we provide simulation results when there are many flows at the congestion point (internal router), 500 to 4,250 flows depending on codec mix used. The violet trace on the graphs shows the number of flows that are sending packets. o The preemption marking threshold is set to 40Mbps, so when traffic exceeds this rate packets are marked every "x" bytes of excess rate. o The forwarding rate is configures such that there is no packet loss in these simulations. See Section 3.4 for results with packet loss. o We simulated with pcn_px = 2,064, 4,064 and 8,064 bytes sizes as well with preemption time set to 50ms, 200ms and 800ms to see the impact these parameters had on rate and behavior of flow termination (preemption). See page 7 [SIM-07] (http://standards.nortel.com/pcn/Simulation_EPCN.pdf) for more details. Pages 8 through 20 [SIM-07] show the simulation results. The left side of graph shows aggregate bandwidth. The bottom of the graph indicates time scale in 0.05 seconds resolution or 3 seconds between vertical dashed lines. The right side of the graph shows number of active flows (flows that are sending packets). The violet trace shows number of active flows. The orange trace shows aggregated transmitted rate that egresses the congested router. The blue trace shows aggregated transmitted rate that is flowing into the router. Note: The blue trace is only visible when there is packet loss. In simulations where there is no packet loss the orange trace over- writes the blue. Observations for large (500 - 4,250) number of flows with no packet loss: o The shorter the preemption time, the faster overload condition is restored back to supportable rate. o The smaller the pcn_px value (packet marked every "x" bytes of excess traffic), the faster the overload condition is restored back to supportable rate. o Packets where marked and flows where terminated when ever excess rate exceeded by pcn_px bytes the supportable rate. Babiarz, et al. Expires August 27, 2007 [Page 11] Internet-Draft Explicit PCN Marking February 2007 o The marking and flow termination (preemption) produced exponential decay behavior. When excess rate was high meaning many flows needed to be terminated, the marking was frequent but as excess load decreased so did the marking and flow termination frequency. Produce a stable behavior for both constant rate and silence supersede voice traffic. o Flow termination (preemption) of traffic generated by constant bit rate codecs is faster than when silence suppression was used since the model that we used to generate VBR voice had an exponential distribution that generated mean on period of 1 second and mean off period of 1.59 seconds (40 on / 60 off). o With VBR voice, during reroute condition some active flows were in silence mode (not sending any packets during off period that had exponential distribution) as can be observed by rounded peak for active flows during link failure. Therefore the total load was not presented instantaneously. o The defined token bucket measurement method, marked higher rate flows more aggressively then lower rate flows. See page 15 [SIM-07] for details. This can also be observed that with mixed codec the number of flows that can be supported after link fail is higher then before. 3.3. Small Number of Voice Flows Here we provide simulation results when there are small numbers of flows at the congestion point (internal router), 10 to 80 depending on codec mix used. The violet trace on the graphs shows the number of flows that are sending packets. o The preemption marking threshold is set to 800Kbps, so when traffic exceeds this rate packets are marked every "x" bytes of excess rate. o The forwarding rate is configures such that there is no packet loss in these simulations. See Section 3.5 for results with packet loss. o We simulated with pcn_px = 2,064 and 8,064 bytes sizes as well with preemption time set to 50ms, 200ms and 800ms to see the impact these parameters had on rate and behavior of flow termination (preemption). See page 21 [SIM-07] for more details. Pages 22 through 28 [SIM-07] show the simulation results when there are a low number of flows at the congested router. Babiarz, et al. Expires August 27, 2007 [Page 12] Internet-Draft Explicit PCN Marking February 2007 Observations for small (10 - 80) number of flows with no packet loss: o The shorter the preemption time, the faster overload condition is restored back to supportable rate. o The smaller pcn_px value (packet marked every "x" bytes of excess traffic), the faster the overload condition is restored back to supportable rate. o Packets where marked and flows where terminated when ever excess rate exceeded by pcn_px bytes the supportable rate. o When excess rate was high meaning many flows needed to be terminated, the marking was frequent but as excess load decreased so did the marking and flow termination frequency. Produce a stable behavior for both constant rate and silence supersede voice traffic. o Flow termination (preemption) of traffic generated by constant bit rate codecs is faster than when silence suppression was used since the model that we used to generate VBR voice had an exponential distribution that generated "mean on period" of 1 second and "mean off period" of 1.59 seconds (40 on / 60 off). o With VBR voice, during reroute condition some active flows were in silence mode (not sending any packets during off period that had exponential distribution) as can be observed by rounded peak for active flows during link failure. Therefore the total load was not presented instantaneously. o The defined token bucket measurement method, marked higher rate flows more aggressively then lower rate flows. See [SIM-07] page 28 for details. This can also be observed that with mixed codec the number of flows that can be supported after link fail is higher then before. The explicit marking behavior produced similar results when the number of constant rate and variable rate (silence suppressed) voice flows was small or high. These simulation results would indicated that for voice traffic this marking approach works independently of number of flows at the congestion point. 3.4. Large Number of Voice Flows with Packet Loss Now we analyze the impact of packet loss has on the explicate marking approach when there are many flows at the congestion point (internal router), 500 to 4,250 depending on codec mix used. The violet trace on the graphs shows the number of flows that are sending packets. Babiarz, et al. Expires August 27, 2007 [Page 13] Internet-Draft Explicit PCN Marking February 2007 o The preemption marking threshold is set to 40Mbps, so when traffic exceeds this rate packets are marked every "x" bytes of excess rate. o The forwarding rate is configures to 48Mbps (introducing up to 40% packet loss) or 40Mbps (introducing up to 50% packet loss). 50% packet loss occurs when forwarding rate of service class = supportable rate (or preemption level), current traffic level is at supportable rate and 100% of additional traffic is added to simulate traffic being switch or rerouted due to failure in the network. o We simulated with pcn_px = 8,064 bytes sizes as well with preemption time set to 200ms and 800ms to see the impact these parameters had on rate and behavior of flow termination (preemption). See page 29 [SIM-07] for more details. Pages 30 through 38 [SIM-07] show the simulation results. Observations for large (500 - 4,250) number of flows with up to 40% and 50% packet loss: o As can be observed the flow termination behaved is similar to when there was no packet loss, except that when there is packet loss the time it takes to terminate sufficient number of flows to the supportable rate (preemption threshold) takes longer. o We also observed that over preemption can occur see page 31 [SIM-07] for CBR (G.711 at 20ms) only traffic when pcn_px value of 8.064 bytes is used with preemption time of 800ms. Increasing pcn_px or decreasing preemption time will remove the over preemption condition for this traffic mix.. o This packet marking and flow termination approach works well even under high packet loss conditions. 3.5. Small Number of Voice Flows with Packet Loss Now we analyze the impact of packet loss has on the explicate marking approach when there are a small number of flows at the congestion point (internal router), 10 to 80 depending on codec mix used. The violet trace on the graphs shows the number of flows that are sending packets. o The preemption marking threshold is set to 800Kbps, so when traffic exceeds this rate packets are marked every "x" bytes of excess rate. Babiarz, et al. Expires August 27, 2007 [Page 14] Internet-Draft Explicit PCN Marking February 2007 o The forwarding rate is configures 960Kbps (introducing up to 40% packet loss) and 800Kbps (introducing up to 50% packet loss). 50% packet loss occurs when forwarding rate of service class = supportable rate (or preemption level), current traffic level is at supportable rate and 100% of additional traffic is added to simulate traffic being switch or rerouted due to failure in the network. o We simulated with pcn_px = 8,064 bytes sizes and preemption time set to 800ms to see the impact these parameters had on rate and behavior of flow termination (preemption). See page 39 [SIM-07] for more details. Pages 40 through 43 [SIM-07] show the simulation results when there are a low number of flows with up to 40% and 50% packet loss at the congested router. Observations for small (10 - 80) number of flows with up to 40% and 50% packet loss: o As can be observed the flow termination behaved is similar to when there was no packet loss, except that when there is packet loss the time it takes to terminate sufficient number of flows to the supportable rate (preemption threshold) takes longer. o We also observed that over preemption can occur see page 40 [SIM-07] for CBR (G.711 at 20ms) only traffic when pcn_px value of 8.064 bytes is used with preemption time of 800ms. Increasing pcn_px or decreasing preemption time will remove the over preemption condition for this traffic mix.. o This packet marking and flow termination approach works well even under high packet loss conditions. 3.6. Corner Voice Cases Studied Now we want to look at some corner cases where this method starts to breakdown. We looked at the configuration of parameters that caused the following conditions: o Over termination (preemption) of flows. This condition occurs when pcn_px parameter is too small for the time that it takes to terminate a flow (total preemption time). This condition is noticeable when there is CBR only traffic flowing through the router. Increasing pcn_px therefore slowing down flow termination can eliminate any possibility of over terminating flows. This is a parameter that can be configured by the network administrator. See simulation results [SIM-07], pages 45-48 of examples of this Babiarz, et al. Expires August 27, 2007 [Page 15] Internet-Draft Explicit PCN Marking February 2007 condition. o Synchronization of packet marking. This conditional occurs for CBR fixed packet size traffic at metering point and when pcn_px is an even multiple of payload packet size, e.g., packet size = 200 bytes and pcn_px = 2,000 bytes. Page 49 [SIM-07] shows that synchronization of marking condition. However, this undesirable behavior does not break the mechanism, but it takes longer to terminate flows. o Preemption takes to long. This condition can be created if pcn_px is configured to me x times larger than need. Page 50 [SIM-07] shows the impact of setting pcn_px to 2x bigger then needed. 3.7. Simulation Setup for Video Traffic In this section, we briefly discuss the preliminary video-related simulation results; for details, see pages 51-65 [SIM-07] (http://standards.nortel.com/pcn/Simulation_EPCN.pdf). The video simulation is based on the same token bucket algorithm as the voice simulation discussed in the previous sections. The main differences between our video simulation and voice simulation are the traffic source model and the selection of the pcn_tb and pcn_px values. In the video simulation, the traffic source model is based on the video model proposed by [Maglaris-88], which has the following properties: o a constant frame rate of F frames per sec (a fixed time interval between frames), o a constant number of P pixels per frame, o a random number of bits per frame calculated using the number of compressed bits per pixel in the n-th frame modeled by a first- order autoregressive Markov process. In our simulation, the packetization of the bits is modeled as follows, o the MTU of the video packet is 1356 bytes, including 40 bytes of the IP header; o only the positive bits calculated from the above video model can generate packets; Babiarz, et al. Expires August 27, 2007 [Page 16] Internet-Draft Explicit PCN Marking February 2007 o the first 1316*8 bits of the total bits of a frame is packed into the first MTU-sized packet; the second 1316*8 bits is packed into the second MTU-sized packet; this is done until all the bits are packed; the last packet likely smaller than MTU contains all the remainder bits plus the 40-byte IP header; o the packets generated from a frame are sent to the network one by one at the end of the time interval of 1/F seconds with a per- packet serialization time of (packet size / link speed); o when a source starts, the first frame is generated at a random time point in the 1/F-sec time interval. In our current video simulation, only a single type of video source is used for generating video flows, which has an expected average data rate of 400Kbps. The following flow settings are considered, similarly to those voice settings, where T is relative to the end of the simulation warm-up period, o Small sources with preemption threshold BW = 4Mpbs: start with 8 flows, add 10 flows at T = 3 sec; add another 10 flows at T = 24 sec; o Medium sources with preemption threshold BW = 40Mpbs: start with 80 flows, add 100 flows at T = 3 sec; add another 100 flows at T = 24 sec; o Large sources with preemption threshold BW = 200Mpbs: start with 400 flows, add 500 flows at T = 3 sec; add another 500 flows at T = 24. The simulation was run with these flow settings for three RTT (flow termination) times of 50, 200, and 800ms and four token bucket- marking interval combinations, o (pcn_tb = 400KB; pcn_px = 200KB); o (pcn_tb = 200KB; pcn_px = 100KB); o (pcn_tb = 300KB; pcn_px = 200KB); o (pcn_tb = 250KB; pcn_px = 50KB). In all the simulation runs, the forwarding rate of the router is set as two times the preemption threshold BW, and the buffer has unlimited space (i.e., there is no packet loss). We have the following observations from the simulations, Babiarz, et al. Expires August 27, 2007 [Page 17] Internet-Draft Explicit PCN Marking February 2007 o video flow preemption is achievable and behaves similarly to what is observed in the voice simulations; o the tested token bucket-marking interval combinations are similarly effective across the flow settings and RTT cases with combination (pcn_tb = 400 KB; pcn_px = 200 KB) seemingly the most stable; o It is difficult to measure the over-/under-preemption error, as offered traffic is constantly changing. However, we believe that (pcn_tb = 400 KB; pcn_px = 200 KB) provide more consistent results then (pcn_tb = 250 KB; pcn_px = 50 KB) parameter settings. 3.8. Excess Load Marking Algorithm Used in Simulation Below is the pseudo code of a token bucket algorithm that was used in our simulations for metering and marking for flow termination (preemption) of flows. This is an example of an metering and preemption marking function that would reside in PCN capable routers. Configuration parameters are per DSCP: pcn_pt = traffic rate at preemption threshold in bits per second pcn_tb = the size of token bucket in bytes for detection that preemption threshold is exceeded pcn_px = the measurement of excess rate, (sets ECN=11 every "x" bytes of excess traffic) Definition of terms used in the algorithm: delta_t is the time since the processing of the previous packet for this token bucket pktLen is the length of the packet being processed in unit of bytes Initialization of local variables: tokenCountP = pcn_tb //initialize token bucket to max. pcn_pt_B = pcn_pt / 8 //change preemption rate to bytes per second Babiarz, et al. Expires August 27, 2007 [Page 18] Internet-Draft Explicit PCN Marking February 2007 Preempt_Level_Metering_Marking routine, with length of current packet as input: Preempt_Meter ( pktLen) { tokenCountP = tokenCountP + (delta_t * pcn_pt_B) //this adds tokens to token bucket tokenCountP = Min (tokenCountP, pcn_tb) //keeps tb from growing pass full tokenCountP = tokenCountP - pktLen //subtracts tx bytes from bucket if (tokenCountP < = 0) //when tb becomes empty or negative { Set ECN = 11 //preemption mark packet, (Set ECN bits = 11) tokenCountP = tokenCountP + pcn_px //add "x" tokens to token bucket } return } // End of Preempt_Meter(). Figure 2 4. Security Considerations Not applicable for this draft. 5. Informative References [I-D.babiarz-pcn-sip-cap] Babiarz, J., "SIP Controlled Admission and Preemption", draft-babiarz-pcn-sip-cap-00 (work in progress), October 2006. [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. [Maglaris-88] Maglaris et al, "Performance Models of Statistical Babiarz, et al. Expires August 27, 2007 [Page 19] Internet-Draft Explicit PCN Marking February 2007 Multiplexing in Packet Video Communications, IEEE Transactions on Communications 36, pp. 834-844", July 1988. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [SIM-07] Liu, X-G. and J. Babiarz, "Simulation Results for Explicit PCN Marking and Flow Termination (http://standards.nortel.com/pcn/Simulation_EPCN.pdf)", February 2007. Authors' Addresses Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Email: babiarz@nortel.com Xiao-Gao Liu Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-7516 Email: xgliu@nortel.com Babiarz, et al. Expires August 27, 2007 [Page 20] Internet-Draft Explicit PCN Marking February 2007 Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1-978-288-8175 Email: khchan@nortel.com Babiarz, et al. Expires August 27, 2007 [Page 21] Internet-Draft Explicit PCN Marking February 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). Babiarz, et al. Expires August 27, 2007 [Page 22]