idnits 2.17.1 draft-ietf-bmwg-dsmterm-01.txt: -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(98): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(431): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2001) is 8349 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 679, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Perser 3 INTERNET-DRAFT Spirent 4 Expires in: December 2001 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 Telcordia 10 Scott Poretsky 11 Avici Systems 12 June 2001 14 Terminology for Benchmarking Network-layer 15 Traffic Control Mechanisms 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet- Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction ............................................... 2 43 2. Existing definitions ....................................... 3 44 3. Term definitions.............................................3 45 3.1 Channel Capacity..........................................3 46 3.2 Classification............................................4 47 3.3 Codepoint Set.............................................4 48 3.4 Conforming................................................5 49 3.5 Congestion................................................5 50 3.6 Congestion Management.....................................6 51 3.7 Delay.....................................................7 52 3.8 Expected Vector...........................................7 53 Network-layer Traffic Control Mechanisms 55 3.9 Flow......................................................8 56 3.10 Forwarding Vector .......................................9 57 3.11 Jitter...................................................9 58 3.12 Nonconforming...........................................10 59 3.13 Offered Vector..........................................11 60 3.14 Stream..................................................11 61 3.15 Tail dropping...........................................12 62 3.16 Test Sequence number....................................12 63 3.17 Unburdened Response.....................................13 64 4. Security Considerations.....................................13 65 5. References..................................................14 66 6. Author's Address............................................14 67 7. Full Copyright Statement....................................15 69 1. Introduction 71 Driven by Internet economics, service providers and enterprises 72 alike have shown strong interest in adding traffic-control 73 capabilities to network devices. These capabilities would enable 74 network operators to define and deliver minimum or maximum levels of 75 bandwidth, delay, and jitter for multiple classes of traffic. 76 Perhaps more importantly, network operators would be able to set 77 pricing according to the level of service delivered. 79 Networking device manufacturers have responded with a wide variety 80 of approaches for controlling network traffic. While there are 81 numerous �policy management� and �quality of service� frameworks, 82 many of them rely on one of two network-layer mechanisms for the 83 actual control of forwarding rate, delay, and jitter. These two 84 mechanisms are the IP precedence setting in the IP header and the 85 diff-serv code point (DSCP) defined in [3]. 87 This document describes the various terms to be used in benchmarking 88 devices that implement traffic control based on IP precedence or 89 DSCP criteria. This document is narrowly focused, in that it 90 describes only terms for measuring behavior of a device or a group 91 of devices using one of these two mechanisms. End-to-end and 92 service-level measurements are beyond the scope of this document. 94 This document introduces several new terms that will allow 95 measurements to be taken during periods of congestion. New 96 terminology is needed because most existing benchmarking terms 97 assume the absence of congestion. For example, throughput is one of 98 the most widely used measurements �- yet RFC 1242 defines throughput 99 as a rate in the absence of loss. As a result, throughput is not a 100 meaningful measurement where congestion exists. 102 Another key difference from existing benchmarking terminology is the 103 definition of measurements as observed on egress as well as ingress 104 of a device/system under test. Again, the existence of congestion 105 requires the addition of egress measurements as well as those taken 106 Network-layer Traffic Control Mechanisms 108 on ingress; without observing traffic leaving a device it is not 109 possible to say whether traffic-control mechanisms effectively dealt 110 with congestion. 112 The principal measurements introduced in this document are rate 113 vectors, delay, and jitter, all of which can be observed with or 114 without congestion of the DUT/SUT. 116 2. Existing definitions 118 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 119 and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" 120 should be consulted before attempting to make use of this document. 122 RFC 2474 "Definition of the Differentiated Services Field (DS Field) 123 in the IPv4 and IPv6 Headers" section 2, contains discussions of a 124 number of terms relevant to network-layer traffic control mechanisms 125 and should also be consulted. 127 For the sake of clarity and continuity this RFC adopts the template 128 for definitions set out in Section 2 of RFC 1242. Definitions are 129 indexed and grouped together in sections for ease of reference. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 133 this document are to be interpreted as described in RFC 2119. 135 3. Term definitions 137 3.1 Channel Capacity 139 Definition: 140 The maximum forwarding rate of a link or set of aggregated 141 links at which none of the offered packets are dropped by the 142 DUT/SUT. 144 Discussion: 145 Channel capacity measures the data rate at the egress 146 interface(s) of the DUT/SUT. In contrast, throughput as defined 147 in RFC 1242 measures the data rate is based on the ingress 148 interface(s) of the DUT/SUT. 150 Ingress-based measurements do not account for congestion of the 151 DUT/SUT. Channel capacity, as an egress measurement, does take 152 congestion into account. 154 Understanding channel capacity is a necessary precursor to any 155 measurement involving congestion. Throughput numbers can be 156 higher than channel capacity because of queueing. 158 Network-layer Traffic Control Mechanisms 160 Measurement units: 162 N-octet packets per second 164 Issues: 166 See Also: 167 Throughput [1] 169 3.2 Classification 171 Definition: 172 Selection of packets based on the contents of packet header 173 according to defined rules. 175 Discussion: 176 Packets can be selected based on the DS field or IP Precedence 177 in the packet header. Classification can also be based on 178 Multi-Field (MF) criteria such as IP Source and destination 179 addresses, protocol and port number. 181 Classification determines the per-hop behaviors and traffic 182 conditioning functions such as shaping and dropping that are to 183 be applied to the packet. 185 Measurement units: 187 n/a 189 Issues: 191 See Also: 192 Rules 194 3.3 Codepoint Set 196 Definition: 197 The set of all DS Code-points or IP precedence values used 198 during the test duration. 200 Discussion: 201 Describes all the code-point markings associated with packets 202 that are input to the DUT/SUT. For each entry in the codepoint 203 set, there are associated vectors describing the rate of 204 traffic containing that particular DSCP or IP precedence value. 206 The treatment that a packet belonging to a particular code- 207 point gets is subject to the DUT classifying packets to map to 208 Network-layer Traffic Control Mechanisms 210 the correct PHB. Moreover, the forwarding treatment in general 211 is also dependent on the complete set of offered vectors. 213 Measurement Units: 214 n/a 216 See Also: 218 3.4 Conforming 220 Definition: 221 Packets that lie within the bounds specified by a traffic 222 profile. 224 Discussion: 225 Rules may be configured that allow a given traffic class to 226 consume only X bit/s of channel capacity and no more. All 227 additional packets are dropped. All packets that constitute 228 the first X bits/s measured over a period of time specified by 229 the traffic profile, are then said to be conforming whereas 230 those exceeding the bound are non conforming. 232 In particular in a congestion scenario, some individual packets 233 will be conforming and others will not. 235 Measurement units: 237 n/a 239 Issues: 241 See Also: 242 Expected Vector 243 Forwarding Vector 244 Offered Vector 246 3.5 Congestion 248 Definition: 249 A condition in which one or more egress interfaces are offered 250 more packets than can be forwarded at any given instant. 252 Discussion: 253 This condition is a superset of the overload definition [2]. 254 That definition assumes the overload is introduced strictly by 255 the tester on ingress of a DUT/SUT. That may or may not be the 256 case here. 258 Network-layer Traffic Control Mechanisms 260 Another difference is that with multiple-DUT measurements, 261 congestion may occur at multiple points. For example, multiple 262 edge devices collectively may congest a core device. In 263 contrast, overload [1] deals only with overload on ingress. 265 Ingress observations alone are not sufficient to cover all 266 cases in which congestion may occur. A device with an infinite 267 amount of memory could buffer an infinite amount of packets, 268 and eventually forward all of them. However, these packets may 269 or may not be forwarded during the test duration. Even though 270 ingress interfaces accept all packets without loss, this 271 hypothetical device may still be congested. 273 The definition presented here explicitly defines congestion as 274 an event observable on egress interfaces. Regardless of 275 internal architecture, any device that cannot forward packets 276 on one or more egress interfaces is congested. 278 Measurement units: 280 n/a 282 Issues: 284 See Also: 286 3.6 Congestion Management 288 Definition: 289 An implementation of one or more per-hop-behaviors to avoid or 290 minimize the condition of congestion. 292 Discussion: 293 Congestion management may seek either to control congestion or 294 avoid it altogether. Such mechanisms classify packets based 295 upon IP Precedence or DSCP settings in a packet�s IP header. 297 Congestion avoidance mechanisms seek to prevent congestion 298 before it actually occurs. 300 Congestion control mechanisms gives one or more service classes 301 preferential treatment over other classes during periods of 302 congestion. 304 Measurement units: 306 n/a 308 Issues: 310 See Also: 312 Network-layer Traffic Control Mechanisms 314 3.7 Delay 316 Definition: 317 The time interval starting when the last bit of the input IP 318 packets reaches the input port of the DUT/SUT and ending when 319 the last bit of the output IP packets is seen on the output 320 port of the DUT/SUT. 322 Discussion: 323 Delay is measured the same regardless of the type of DUT/SUT. 324 Latency [1] require some knowledge of whether the DUT/SUT is a 325 "store and forward" or a "bit forwarding" device. The fact 326 that a DUT/SUT's technology has a lower delay than another 327 technology should be visible. 329 The measurement point at the end is more like the way an 330 internet datagram is processed. An internet datagram is not 331 passed up or down the stack unless it is complete. Completion 332 occurs once the last bit of the IP packet has been received. 334 Delay can be run at any offered load. Recommend at or below 335 the channel capacity for non-congested delay. For congested 336 delay, run the offered load above the channel capacity. 338 Measurement units: 340 Seconds. 342 Issues: 344 See Also: 346 3.8 Expected Vector 348 Definition: 349 A vector describing the expected output rate of packets having 350 a specific code-point. The value is dependent on the set of 351 offered vectors and configuration of the DUT. 353 Discussion: 354 The DUT is configured in a certain way in order that service 355 discrimination happens for behavior aggregates when a specific 356 traffic mix consisting of multiple behavior aggregates is 357 applied. This term attempts to capture the expected behavior, 358 for which the device is configured, when subjected to a certain 359 offered load. 361 Network-layer Traffic Control Mechanisms 363 The actual algorithms or mechanism, that the DUT uses to 364 achieve service discrimination, is not important in describing 365 the expected vector. 367 Measurement units: 368 N-octets packets per second 370 See Also: 371 Forwarding Vector 372 Offered Vector 373 Codepoint Set 375 3.9 Flow 377 Definition: 378 A flow is a one or more of packets sharing a common intended 379 pair of source and destination interfaces. 381 Discussion: 382 Packets are groups by the ingress and egress interfaces they 383 use on a given DUT/SUT. 385 A flow can contain multiple source IP addresses and/or 386 destination IP addresses. All packets in a flow must enter on 387 the same ingress interface and exit on the same egress 388 interface, and have some common network layer content. 390 Microflows [3] are a subset of flows. As defined in [3], 391 microflows require application-to-application measurement. In 392 contrast, flows use lower-layer classification criteria. Since 393 this document focuses on network-layer classification criteria, 394 we concentrate here on the use of network-layer identifiers in 395 describing a flow. Flow identifiers also may reside at the 396 data-link, transport, or application layers of the ISO model. 397 However, identifiers other than those at the network layer are 398 out of scope for this document. 400 A flow may contain a single code point/IP precedence value or 401 may contain multiple values destined for a single egress 402 interface. This is determined by the test methodology. 404 Measurement units: 406 n/a 408 Issues: 410 See Also: 411 Microflow [3] 412 Network-layer Traffic Control Mechanisms 414 Streams 416 3.10 Forwarding Vector 418 Definition: 419 The number of packets per second for all packets containing a 420 single DSCP (or IP precedence) that a device can be observed to 421 successfully transmit to the correct destination interface in 422 response to an offered vector. 424 Discussion: 425 Forwarding Vector is expressed as pair of numbers. Both the 426 codepoint (or IP precedence) value AND the packets per second 427 value combine to make a vector. 429 The forwarding vector represents packet rate based on their 430 codepoint or IP precedence value. It is not necessary based on 431 stream or flow. The forwarding vector may be expresses as �per 432 port� or �of the DUT/SUT�. 434 Forwarding Vector is a per-hop measurement. The DUT/SUT may 435 change the codepoint or IP precedence value for a multiple-hop 436 measurement. 438 Measurement units: 440 N-octet packets per second 442 Issues: 444 See Also: 445 Codepoint Set 446 Expected Vector 447 Offered Vector. 449 3.11 Jitter 451 Definition: 452 Variation in a stream's delay. 454 Discussion: 455 Jitter is the absolute value of the difference between the 456 delay measurement of two packets belonging to the same stream. 458 The jitter between two consecutive packets in a stream is 459 reported as the "instantaneous jitter". Instantaneous jitter 460 can be expressed as |D(i) � D(i+1)| where D equals the delay 461 and i is the test sequence number. Packets lost are not 462 counted in the jitter measurement. 464 Network-layer Traffic Control Mechanisms 466 Average Jitter is the average of the instantaneous jitter 467 measured during the test duration. 469 Peak-to-peak jitter is the maximum delay minus the minimum 470 delay of the packets forwarded by the DUT/SUT. 472 Measurement units: 474 Seconds (instantaneous) 475 Seconds P-P (peak to peak) 476 Seconds avg (average) 478 Issues: 479 Mean 480 Standard Deviation 481 Median 482 90th percentile 483 Inter Quartile Range 485 See Also: 486 Stream 488 3.12 Nonconforming 490 Definition: 491 Packets that lie outside the parameter bounds of a given 492 traffic profile. 494 Discussion: 495 Rules may be configured for a given traffic class based on 496 parameters, such as an upper bound on the rate of packet 497 arrivals. All packets that lie outside the bounds specified by 498 the traffic profile, measured over a period of time specified 499 in the traffic profile, are said to be nonconforming. 501 Measurement units: 503 n/a 505 Issues: 507 See Also: 508 Conforming 510 3.13 Offered Vector 512 Definition: 514 Network-layer Traffic Control Mechanisms 516 A vector describing the rate at which packets having a specific 517 code-point are offered to the DUT/SUT. 519 Discussion: 520 Offered loads across the different code-point classes, 521 constituting a code-point set, determine the metrics associated 522 with a specific code-point traffic class. 524 Measurement Units: 525 N-octets packets per second 527 Issues: 528 Packet size. 530 See Also: 531 Expected Vector 532 Forwarding Vector 533 Codepoint Set 535 3.14 Stream 537 Definition: 538 A group of packets tracked as a single entity by the traffic 539 receiver. A stream shares a common content such as type (IP, 540 UDP), frame size, or payload. 542 Discussion: 543 Streams are tracked by "sequence number" or "unique signature 544 field" (RFC 2889). Streams define how individual packet's 545 statistics are grouped together to form an intelligible 546 summary. 548 Common stream groupings would be by egress interface, 549 destination address, source address, DSCP, or IP precedence. A 550 stream using sequence numbers can track the ordering of packets 551 as they transverse the DUT/SUT. 553 Streams are not restricted to a pair of source and destination 554 interfaces as long as all packets are tracked as a single 555 entity. A mulitcast stream can be forward to multiple 556 destination interfaces. 558 Measurement units: 560 n/a 562 Issues: 564 See Also: 565 Flow 566 MicroFlow [3] 567 Network-layer Traffic Control Mechanisms 569 Test sequence number 571 3.15 Tail dropping 573 Definition: 574 The condition in which a congested DUT/SUT discards newly 575 arriving packets. 577 Discussion: 578 Every DUT/SUT has a finite amount of traffic it can forward, 579 beyond which congestion occurs. Once the offered load crosses 580 the congestion threshold, the device may discard any additional 581 traffic that arrives until congestion clears. 583 Tail dropping is typically a function of offered load exceeding 584 a DUT/SUT�s buffer capacity, but other factors internal to the 585 DUT/SUT may also come into play. In terms of what is externally 586 observable, tail dropping can be said to occur only when 587 offered load exceeds channel capacity. Since a DUT/SUT may 588 buffer traffic on ingress, the actual threshold for tail 589 dropping may be higher than channel capacity. 591 Measurement units: 593 n/a 595 Issues: 596 Some congestion management mechanisms seek to avoid tail 597 dropping by discarding packets before offered load exceeds 598 channel capacity. In the presence of such mechanisms, neither 599 congestion nor tail dropping should occur. 601 See Also: 602 Channel capacity 603 Congestion 605 3.16 Test Sequence number 607 Definition: 608 A field in the IP payload portion of the packet that is used to 609 verify the order of the packets on the egress of the DUT/SUT. 611 Discussion: 612 The traffic generator sets the sequence number value and the 613 traffic receiver checks the value upon receipt of the packet. 614 The traffic generator changes the value on each packet 615 transmitted based on an algorithm agreed to by the traffic 616 receiver. 618 Network-layer Traffic Control Mechanisms 620 The traffic receiver keeps track of the sequence numbers on a 621 per stream basis. In addition to number of received packets, 622 the traffic receiver may also report number of in-sequence 623 packets, number of out-sequence packets and number of duplicate 624 packets. 626 The recommended algorithm to use to change the sequence number 627 on sequential packets is an incrementing value. 629 Measurement units: 631 n/a 633 Issues: 635 See Also: 636 Stream 638 3.17 Unburdened Response 640 Definition: 641 A performance measure obtained when mechanisms used to support 642 IP precedence and DiffServ are disabled. 644 Discussion: 645 Enabling Diffserv mechanisms such as scheduling algorithms may 646 impose an additional processing overhead for packets, which may 647 cause the aggregate response to suffer even when traffic 648 belonging to only one class, the best effort class, is offered 649 to the device. Comparisons with "unburdened performance" may 650 thus be in order when obtaining metrics to ensure that enabling 651 Diffserv mechanisms doesn't impose an excessive performance 652 penalty. 654 Measurement units: 656 n/a 658 4. Security Considerations 660 Documents of this type do not directly effect the security of 661 the Internet or of corporate networks as long as benchmarking 662 is not performed on devices or systems connected to operating 663 networks. 665 5. References 667 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 668 Network-layer Traffic Control Mechanisms 670 Interconnection Devices", RFC 1242, July 1991. 672 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 673 Devices", RFC 2285, February 1998. 675 [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of the 676 Differentiated Services Field (DS Field) in the IPv4 and 677 IPv6 Headers", RFC 2474, December 1998. 679 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 680 Weiss, "An Architecture for Differentiated Services", RFC 681 2475, December 1998. 683 6. Author's Address 685 Jerry Perser 686 Spirent Communications 687 26750 Agoura Road 688 Calabasas, CA 91302 689 USA 691 Phone: + 1 818 676 2300 692 EMail: jerry.perser@spirentcom.com 694 David Newman 695 Network Test 696 31324 Via Colinas, Suite 113 697 Westlake Village, CA 91362 698 USA 700 Phone: + 1 818 889 0011, x10 701 EMail: dnewman@networktest.com 703 Sumit Khurana 704 Telcordia Technologies 705 445 South Street 706 Morristown, NJ 07960 707 USA 709 Phone: + 1 973 829 3170 710 EMail: sumit@research.telcordia.com 712 Shobha Erramilli 713 Telcordia Technologies 714 331 Newman Springs Road, 715 Navesink, NJ 07701 716 USA 717 Network-layer Traffic Control Mechanisms 719 Phone: + 1 732 758 5508 720 EMail: shobha@research.telcordia.com 722 Scott Poretsky 723 Avici Systems 724 101 Billerica Ave�Building #6 725 N. Billerica, MA 01862 726 USA 728 Phone: + 1 978 964 2287 729 EMail: sporetsky@avici.com 731 7. Full Copyright Statement 733 Copyright (C) The Internet Society (1998). All Rights 734 Reserved. 736 This document and translations of it may be copied and 737 furnished to others, and derivative works that comment on or 738 otherwise explain it or assist in its implementation may be 739 prepared, copied, published and distributed, in whole or in 740 part, without restriction of any kind, provided that the above 741 copyright notice and this paragraph are included on all such 742 copies and derivative works. However, this document itself may 743 not be modified in any way, such as by removing the copyright 744 notice or references to the Internet Society or other Internet 745 organizations, except as needed for the purpose of developing 746 Internet standards in which case the procedures for copyrights 747 defined in the Internet Standards process must be followed, or 748 as required to translate it into languages other than English. 750 The limited permissions granted above are perpetual and will 751 not be revoked by the Internet Society or its successors or 752 assigns. This document and the information contained herein is 753 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 754 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 755 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 756 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 757 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 758 FOR A PARTICULAR PURPOSE.