TSV working group Internet Draft Naotaka MORITA Document: draft-morita-tsvwg-mfverify-00.txt NTT Corporation Expires: April 2004 October 2003 Verification scenarios for Measurable Forwarding PHB (Per-Hop Behavior) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. The PPS is based on a new per-hop forwarding behavior, called measurable forwarding (MF-PHB), which will use the DiffServ architecture. Morita Expires - April 2004 [Page 1] MF-Verification October 2003 In this document, we propose a way to verify whether MF-PHB is realizable by elaborating configurations of existing equipment. Conventions used in this document 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 [2]. Table of Contents 1. Introduction...................................................2 2. Verification of MF-PHB.........................................3 2.1 Consideration on test items................................3 2.2 Test scenarios.............................................4 2.3 Remarks....................................................6 Security Considerations...........................................7 References........................................................7 Author's Addresses................................................7 1. Introduction The Priority Promotion Scheme (PPS) [3] is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The main target is interactive multimedia services such as VoIP, video chatting, and video conferencing, which are usually controlled using SIP. In this context, "priority" means priority or precedence in the IP layer as represented by the DiffServ Code Point (DSCP). The scheme is based on end-to-end measurement of network resources through coordination of the end systems. Before a session is established and even during sessions under certain conditions, the source end system senses, measures, or probes the availability of network resources by sending packets with priority one level lower than that of the non-probe packets, i.e. those for established streams. The result is an adjustment of the DiffServ Code Point (DSCP) value for the succeeding IP packets: the priority is raised or promoted to firmly establish the session, lowered to leave resources with existing sessions, or otherwise adjusted to control the amount of packets so that the traffic fits the available capacity. The network, i.e. output links of the routers or L2 switches, is only required to support per-class priority control. The prioritization allows the end systems to measure remaining resources without affecting exiting streams. Having all end systems behave in the way described above ensures that the end-to-end QoS is achieved without maintaining per-flow states in individual items of network equipment. Morita Expires - April 2004 [Page 2] MF-Verification October 2003 The key point of this scheme is "measurable forwarding", a new per- hop forwarding behavior (transport function of the network), referred to as MF-PHB [4]. In this document, we introduce a way to verify whether or not a router achieves the static mode of MF-PHB. 2. Verification of MF-PHB We believe that it will be possible to realize MF-PHB on certain existing routers by simply elaborating queue configurations or slightly modifying queuing mechanisms. We propose a set of verification tests that indicate whether or not a router can realize MF-PHB. Since the purpose of this test is to assist the understanding of the definition of MF-PHB and to obtain a hint of the possibility of the realization of MF-PHB, the test is not exhausted and some parameters are free to choose. In the following tests, we concentrate on the static mode of MF-PHB. 2.1 Consideration on test items The test items are derived from the definition of MF-PHB [4]. Minimum bandwidth guarantee: test items include checking of MF-class throughput in the presence of non MF-PHB classes, i.e. an overload of BE-class packets, and an overload of EF-class packets. At an initial step, All offered MF-class packets are either M-subclass or H- subclass, i.e. mixtures are not offered. This is a kind of simple throughput test. Maximum bandwidth limitation: In the presence of an overload of non MF- classes and MF-classes, the router has to pass MF-class packets up to the threshold corresponding to this limitation and discard extra MF-class packets beyond the limitation. Then, the flows of non PPS-class traffic are stopped, and the router still has to discard the same volume of extra MF-class packets. Again, all offered MF- class packets are either M-subclass or H-subclass. Priority transmission: While H-packets of MF-class are arriving at the rate BWmf, extra M packets are offered. All M packets should be discarded, while all H packets should be passed. Test items include cases with no packets of other classes and overloading with packets of other classes. Real-time nature: Data on the delay and jitter in the above test scenarios should be collected. Sequence integrity: Packet ordering in the above test scenarios should be monitored. Morita Expires - April 2004 [Page 3] MF-Verification October 2003 2.2 Test scenarios Figure 1 describes network configuration used for the test. The purpose of the test is to check the output port capability to meet the definition of MF-PHB. Physical interface speed is 100 Mbps. Generated traffic is CBR with 1500 Byte packets as IP packet size. In addition, 200 Byte packets should be used. After five-minute leading time, throughput should be monitored for about 10,000-packet duration. Input ports +---------+ => +-----+ | |-------------| | |Traffic |-------------|Unit | |generator|-------------|under| | |-------------|test | | |-------------| | +---------+ +-----+ | |Output port | <= |(Bottle neck) +---------------------+ Figure 1. Network configuration for MF-PHB verification Table 1 describes test scenarios. The row "Rate limit" indicates parameter values to be set for each queue at the output port if applicable. In the test, the parameters are supposed to be fixed across different inputs. In the scenarios, it is assumed that EF or AF is configurable to emulate MF-H and MF-M. Those are categorized in Types of Queue. The validity of all four types depends on the flexibility of the unit under testing. In Type A, for example, MF-H and MF-M are emulated by two queues of AFs. Since rate limit is a mandatory function, the maximum bandwidth limitation as well as the minimum bandwidth guarantee are set to 40 Mbps. In Type B, one AF queue with discard threshold is used. In Type C, two extra EFs are used to emulated MF- H and MF-M. In Type D, one EF queue with discard threshold is used. The detailed configuration is explained in [4]. Usages of policer and shaper are included. If the shaper is used, minimum token interval should be used to reduce jitter. Queue length for MF-H is 100 and for MF-M 1 in general. For MF-M, if the throughput degradation is severe, queue length for MF-M may be longer to show the correct functionality of such configuration. With regard to the specific test items, input and output are described. For output, the correct and possible wrong results are shown. Morita Expires - April 2004 [Page 4] MF-Verification October 2003 In order to analyze real time nature and packet sequence integrity, departure and arrival time of packets at the traffic generator should be collected. For real time nature, delay which is the difference between the arrival and departure times and its density distribution is used. For sequence integrity, the density distribution of packet interval between two packets whose sequence numbers are adjacent at source and sink should be used. Table 1. Test scenarios to verify MF-PHB +-------------------------------------------------------------------+ | | EF |MF-H|MF-M|AF3 |AF4 | BE | comments | |------------+----+---------+----+----+----+------------------------| |Rate Limit | 30 | 40 | 10 | 5 |none| | |-----+------+----+---------+----+----+----+ | | |Type A| EF |AF1 |AF2 |AF3 |AF4 | BE | | | +------+----+---------+----+----+----+ | |Queue|Type B| EF | AF1 |AF3 |AF4 | BE | | | +------+----+---------+----+----+----+ | | |Type C| EF |EF-1|EF-2|AF3 |AF4 | BE | | | +------+----+---------+----+----+----+ | | |Type D| EF | EF1 |AF3 |AF4 | BE | | |=====+======+====+=========+====+====+====+========================| | | |input | 90 | 40 | 0 | 90 | 90 | 90 | The background load | | | | | | | | | | | should be greater than | | | | | | | | | | | the link. | | | +------+----+----+----+----+----+----+------------------------| | |1-1|output| 30 | 40 | 0 | 10 | 5 | 15 | Packets of class MF-H | | | |(good)| | | | | | | were passed w/out loss.| | | +------+----+----+----+----+----+----+------------------------| | | |output| 30 |29.1| 0 |16.4| 8.2|16.3| AF packets were being | | | |(bad) | | | | | | | read out according to | | | | | | | | | | | the input rate. | | |---+------+----+----+----+----+----+----+------------------------| | | |input | 90 | 0 | 40 | 90 | 90 | 90 | The background load | | | | | | | | | | | should be greater than | | | | | | | | | | | the link. | | | +------+----+----+----+----+----+----+------------------------| |T|1-2|output| 30 | 0 | 40 | 10 | 5 | 15 | Packets of class MF-M | | | |(good)| | | | | | | were passed w/out loss.| |E| +------+----+----+----+----+----+----+------------------------| | | |output| 30 | 0 |29.1|16.4| 8.2|16.3| AF packets were being | |S| |(bad) | | | | | | | read out according to | | | | | | | | | | | the input rate. | |T|---+------+----+----+----+----+----+----+------------------------| | | |input | 0 | 90 | 0 | 0 | 0 | 0 | There must be an | | | | | | | | | | | overload of H packets. | | | +------+----+----+----+----+----+----+------------------------| Morita Expires - April 2004 [Page 5] MF-Verification October 2003 | |2-1|output| 0 | 40 | 0 | 0 | 0 | 0 | Packets in excess of | | | |(good)| | | | | | | the rate limit were | | | | | | | | | | | discarded. | | | +------+----+----+----+----+----+----+------------------------| |I| |output| 0 | 90 | 0 | 0 | 0 | 0 | The rate limit was | | | |(bad) | | | | | | | not applied. | |T|---+------+----+----+----+----+----+----+------------------------| | | |input | 0 | 0 | 90 | 0 | 0 | 0 | There must be an | |E| | | | | | | | | overload of M packets. | | | +------+----+----+----+----+----+----+------------------------| |M|2-2|output| 0 | 0 | 40 | 0 | 0 | 0 | Packets in excess of | | | |(good)| | | | | | | the rate limit were | | | | | | | | | | | discarded. | | | +------+----+----+----+----+----+----+------------------------| | | |output| 0 | 0 | 90 | 0 | 0 | 0 | The rate limit was not | | | |(bad) | | | | | | | applied. | | |---+------+----+----+----+----+----+----+------------------------| | | |input | 90 | 40 | 90 | 90 | 90 | 90 | Bandwidth up to BWmf is| | | |(Note | | | | | | | filled solely by MF-H | | | |1,2) | | | | | | | packets. | | | +------+----+----+----+----+----+----+------------------------| | | 3 |output| 30 | 40 | 0 | 10 | 5 | 15 | All MF-M packets were | | | |(good)| | | | | | | discarded.(Note 3) | | | +------+----+----+----+----+----+----+------------------------| | | |output| 30 | 39 | 1 | 10 | 5 | 10 | Some MF-H packets were | | | |(bad) | | | | | | | lost and some MF-M ones| | | | | | | | | | | were carried. | +-------------------------------------------------------------------+ Note 1: Input for MF-M should be variable interval. Note 2: As an option, MF-H with 1500 Bytes and MF-M with 200 Bytes should be used as IP packet size. Note 3: Packet loss for MF-H should be monitored. 2.3 Remarks For test item 3, the packet interval of MF-M should be variable. This is to check the incorrect behavior such that some extra MF-M packets are passed and MF-H packets are discarded. This might be an issue when a policer is used to limit the rate of MF class. For test item 3, the mixture of short MF-M and long MF-H packets should be checked. Short MF-M packets might be carried rather than long MF-H packets. For test item 3, the number of lost MF-H packets should be counted in addition to the throughput. Since the amount of MF-H is equal to the threshold BWmf, no MF-H packets must be dropped. Morita Expires - April 2004 [Page 6] MF-Verification October 2003 Security Considerations To be described. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 N. Morita and G. Karlsson, "Framework of Priority Promotion Scheme," Internet draft, October 2003. 4 N. Morita, "Measurable Forwarding: A New per-Hop Behavior (PHB)," Internet draft, October 2003. Author's Addresses Naotaka MORITA Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan EMail: morita.naotaka@lab.ntt.co.jp Morita Expires - April 2004 [Page 7]