[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

TSVWG                                                         B. Briscoe
Internet Draft                                               G. Corliano
draft-briscoe-tsvwg-cl-phb-00.txt                             P. Eardley
Expires: January 2006                                          P. Hovell
                                                              A. Jacquet
                                                            D. Songhurst
                                                                      BT
                                                           July 11, 2005


                   The Controlled Load per hop behaviour
                     draft-briscoe-tsvwg-cl-phb-00.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 January 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This document defines two per-hop behaviours (PHBs) called Controlled
   Load step and Controlled Load ramp (CL-step-PHB and CL-ramp-PHB). CL



Briscoe                Expires January 11 2006                [Page 1]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   service is a quality of service (QoS) closely approximating the QoS
   that same flow would receive from a lightly loaded network element
   [RFC2211]. CL service is useful for inelastic flows such as those for
   streaming real-time media.

   Explicit Congestion Notification (ECN) marking semantics are defined
   as part of the PHBs, to provide an "early warning" of potential
   congestion. The PHBs can be used as a basic building block within an
   edge-to-edge (CL-ramp-PHB) or end-to-end (CL-step-PHB) QoS
   architecture, using distributed measurement-based admission control.

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 [RFC2119].

Table of Contents


   1. Overview and motivation......................................3
   2. Detail......................................................5
      2.1. Queuing................................................5
      2.2. Setting the Congestion Experienced (CE) codepoint........5
         2.2.1. Possible algorithms for setting the CE codepoint....6
      2.3. Scheduling.............................................8
      2.4. Damage limitation.......................................8
      2.5. Applicability of CL PHBs................................9
      2.6. Interaction with other PHBs.............................9
      2.7. Interaction with default ECN behaviour..................9
      2.8. Mutability............................................10
      2.9. Microflow misordering..................................10
      2.10. Recommended codepoint for this PHB....................10
      2.11. Tunnelling...........................................10
      2.12. Security Considerations...............................10
      2.13. IANA considerations...................................10
   3. Use cases..................................................11
      3.1. Host-to-host service...................................11
      3.2. Edge-to-edge service...................................11
   4. Acknowledgements...........................................12
   5. Comments solicited.........................................12
   6. References.................................................13
   Authors' Addresses............................................15
   Intellectual Property Statement................................16
   Disclaimer of Validity........................................17
   Copyright Statement...........................................17



Briscoe                Expires January 11 2006                [Page 2]


Internet-Draft    Controlled Load per hop behaviour          July 2005


1. Overview and motivation

   Network nodes that implement the differentiated services (DS)
   enhancements to IP use a codepoint in the IP header to select a per-
   hop behaviour (PHB) as the specific forwarding treatment for that
   packet [RFC2474, RFC2475]. This document describes two new PHBs
   called Controlled Load (CL) ramp and step (CL-ramp-PHB and CL-step-
   PHB).

   The Quality of Service (QoS) that can be achieved with the PHBs
   corresponds to the Integrated services Controlled Load (CL) class,
   that is [RFC2211]: "a quality of service closely approximating the
   QoS that same flow would receive from [a network element that is]
   lightly loaded".

   The CL PHBs are different from PHBs defined so far, in that they
   define Explicit Congestion Notification (ECN) marking semantics as
   part of the PHB. [RFC3168] specifies the default ECN marking
   behaviour of an ECN-capable router for currently standardised PHBs,
   but allows new PHBs to define different ECN marking behaviour. The
   default behaviour is to indicate incipient congestion by setting the
   Congestion Experienced (CE) codepoint in the IP header of packets,
   with a probability determined by the RED algorithm [RFC2309] based on
   the moving average queue length - so packets have their CE codepoint
   set at the same point that a non-ECN-capable router would drop them.

   This document specifies a different behaviour: a node sets the CE
   codepoint in the IP header as an "early warning" of potential
   congestion, and aims to do so before there is any significant build-
   up of CL packets in the queue. This information enables appropriate
   action to be taken to heed the "early warning" so that the router
   should never become overloaded and forced to queue packets, and hence
   the service achieves a higher performance. One example of an
   'appropriate action' is that an ingress gateway blocks new microflows
   (Section 3.2 and [CL-arch]). Hence it is possible for the CL packets
   to suffer minimal queuing delay, jitter and loss - exactly the
   requirements of real time traffic.
   So a node using a CL PHB generates ECN signalling and is also part of
   a system of other nodes in a closed feedback loop, which allows
   control of the offered load on the local queue. To summarise: the CL
   PHBs provide QoS by virtue of their local scheduling behaviour, in
   combination with admission control.


   The basic concepts are:



Briscoe                Expires January 11 2006                [Page 3]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   o Setting the CE codepoint: the router sets the CE codepoint of CL
      packets before it is actually congested (but when congestion is
      fairly imminent). Reason: it enables appropriate action to be
      taken so that actual congestion is not experienced, and hence a
      very low loss, delay and jitter service is possible.

   o Discarding: CL packets should not need to be discarded, but if
      necessary packets would be discarded on a drop tail basis.

   o Priority queuing: at a minimum for the CL-ramp-PHB with adaptive
      bandwidth (see below), CL packets are prioritised before non-CL
      packets, ie they are always de-queued first. Reason: This
      minimises CL packets' delay and jitter.

   o Reordering: CL packets within a flow must not be reordered, for
      example this can be achieved with a first-in-first-out (FIFO)
      queue. Reason: packet reordering significantly degrades the
      performance of real time applications.

   o Selecting the output link: the router selects the link on which to
      forward the packet based on normal IP routing.

   To indicate that this new behaviour is required, packets are marked
   with one of two new Differentiated Services Codepoints (DSCPs). It is
   hoped that (an evolution of) the CL PHBs is standardised, which
   requires each PHB to have an associated RECOMMENDED DSCP. RECOMMENDED
   DSCPs, rather than EXP/LU (experimental / local use) ones, enable
   multi-domain operation and vendor interoperability.



   Two usage scenarios are suggested in Section 3 (others are possible):

   o A host-to-host service, potentially through several domains, using
      the CL-step-PHB

   o An edge-to-edge service across a single domain or across
      cooperating domains, using the CL-ramp-PHB.

   How the CL PHBs can co-exist with existing DiffServ (DS) PHBs and
   with the default [RFC3168] ECN behaviour is discussed in Sections 2.6
   and 2.7.

   The CL PHBs - unlike the PHBs for Expedited Forwarding [RFC3246] and
   Assured Forwarding [RFC2597] - do not require routers to be
   configured with a minimum departure rate, although it is not
   precluded.


Briscoe                Expires January 11 2006                [Page 4]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   There are two CL PHB groups each of which consists of a single
   individual PHB. They are intended for general or local use.

   One motivation for this specification is that some network operators
   are planning to carry all their traffic on a single unified network,
   because this is expected to reduce operating costs dramatically.
   Therefore such a network must carry real time inelastic flows like
   voice and video calls, which are very delay sensitive. Per microflow
   reservations are too unwieldy in the core and backbone of the
   network. It is possible to achieve low delays in the core and
   backbone with DS today, by triggering flow admission control when
   traffic entering a DS domain exceeds its contracted rate. But for
   longer topologies, the chances increase that traffic will focus on a
   resource near the egress, even though it is within contract at the
   ingress [Reid]. This is because the ingress contract must allow any
   destination address, if it is to remain scalable. Even though
   networks can be engineered to make such failures rare, when they
   occur all inelastic flows through the congested resource fail
   catastrophically.



2. Detail

   The CL PHBs define forwarding behaviour for packets in the CL
   behaviour aggregate.

2.1. Queuing

   CL and non-CL packets are put into logically separate queues; if
   required, a CL packet can pre-empt non-CL packet(s) in the total
   buffer (see below).

2.2. Setting the Congestion Experienced (CE) codepoint

   A CL implementation in a DS node MUST detect and respond to potential
   congestion within the CL traffic aggregate by setting the CE
   codepoint of CL packets, with a probability determined by the
   algorithms described below, when it forwards them. 'Potential
   congestion' means a little before the CL packets start suffering a
   significant delay due to queuing in the node.
   There are two PHBs with slightly different behaviour:
   1. CL-step-PHB: The probability that a node sets the CE codepoint of
      a packet is either 0 or 1 (ie 'on' or 'off').




Briscoe                Expires January 11 2006                [Page 5]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   2. CL-ramp-PHB: The probability that a node sets the CE codepoint of
      a packet can be any value.

   Implementation details include the precise algorithm and the value of
   its parameters.
2.2.1. Possible algorithms for setting the CE codepoint

   Each node in the CL-region runs an algorithm to determine whether to
   set the CE codepoint of a particular CL packet. In our description we
   assume that a bulk token bucket is used (note that there is not a
   token bucket per microflow). Tokens are added when packets are queued
   and are consumed at a fixed rate. The idea is that an excess of
   tokens is seen before the queue of CL packets has got long enough to
   cause the CL packets to suffer a significant delay - the algorithms
   are explained more fully below and are slightly different for the CL-
   step-PHB and CL-ramp-PHB. Other implementations are possible.

   The two CL PHBs use different algorithms for determining how the
   amount of tokens whether a packet has its CE codepoint set:
   1. CL-step: The CE codepoint setting is either 'on' or 'off'. As soon
      as the amount of tokens is greater than a threshold value, then
      all CL-step packets have their CE codepoint set. To prevent
      instability, the metering function has built-in hysterisis, ie
      this continues until the amount of tokens has decreased below a
      second threshold value.

   2. CL-ramp: There are two alternatives described in detail in [CL-
      arch]:

   o Configured bandwidth: the node has a fixed maximum bandwidth
      allocated to CL-ramp traffic, under the control of management
      configuration. Tokens are consumed slightly slower than this rate.
      The probability that a node sets the CE codepoint of a CL-ramp
      packet depends on the number of tokens in the bucket. Below one
      threshold value of the number of tokens no packets have their CE
      codepoint set and above the second they all do; in between, the
      probability increases linearly.









Briscoe                Expires January 11 2006                [Page 6]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   o Flexible bandwidth: the node allows an adaptive trade-off between
      CL-ramp and non-CL-ramp traffic. Tokens are consumed at slightly
      less than the (total) outgoing service rate. The probability that
      a node sets the CE codepoint of a CL packet depends on the number
      of tokens in the bucket *plus* the number of queued non-CL
      packets. Below one threshold value of this sum no packets have
      their CE codepoint set and above the second they all do; in
      between, the probability increases linearly.

   In the flexible bandwidth case, the probability reflects the load of
   both CL and non-CL traffic. The reason is to ensure a 'fair balance'
   between the two classes, by rejecting CL session requests if non-CL
   demand is very high. Alternatively, if the number of queued non-CL
   packets is not included, then the admission of a CL microflow is
   independent of the amount of non-CL traffic.


Probability
of setting    ^
CE codepoint  |
              |
            1_|            ____<____
              |           |         |
              |           |         |
              |           |         |
              |           |         |
              |           |         ^
              |           |         |
              |           |         |
              |           |         |
              |           |         |
            0_|___________|____>____|
              |
               -----------|---------|-------------->
                        min-       max-         Amount of tokens
                     threshold    threshold

   Figure 1: Setting Congestion Experienced Codepoint for CL-step-PHB








Briscoe                Expires January 11 2006                [Page 7]


Internet-Draft    Controlled Load per hop behaviour          July 2005


Probability
of setting    ^
CE codepoint  |
              |
            1_|                     _______________
              |                    /
              |                   /
              |                  /
              |                 /
              |                /
              |               /
              |              /
              |             /
              |            /
            0_|___________/
              |
               -----------|---------|-------------->
                        min-       max-         Amount of tokens
                     threshold    threshold      + number of queued
                                                  non-CL packets

Figure 2: Setting Congestion Experienced Codepoint for CL-ramp-PHB



2.3. Scheduling

   In the CL-ramp case with flexible bandwidth, CL packets are always
   scheduled ahead of non-CL ones, in order to minimise their delay and
   jitter, and FIFO (First In First Out) scheduling is used to prevent
   reordering within a CL microflow. This is needed because the arrival
   rate of CL packets is unknown. The fixed bandwidth case has more
   options, for example the CL-ramp and non-CL traffic could be serviced
   by a Weighted Round Robin scheduler.

2.4. Damage limitation

   It is expected that setting the CE codepoint will enable appropriate
   action to be taken early enough to prevent significant congestion.
   However, in some circumstances (for instance if a node fails) it will
   not be sufficient. Therefore, if a CL PHB is implemented by a
   mechanism that allows unlimited pre-emption of other traffic (eg a




Briscoe                Expires January 11 2006                [Page 8]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   priority queue), the implementation SHOULD include some means to
   limit the damage CL traffic could inflict on other traffic.

2.5. Applicability of CL PHBs

   It is suggested that the CL-step-PHB is defined for probing. One
   advantage of the CL-step-PHB is that it sets the CE codepoint
   immediately it notices there is potential congestion, so the
   admission control can react to a single CE packet.

   It is suggested that the CL-ramp-PHB is defined for either data or
   probing. Advantages of the CL-ramp-PHB are that it can discriminate
   between different levels of congestion and accumulate the congestion
   signal across the network (so it can detect when several nodes are
   experiencing a low level of congestion such that a step algorithm
   would be 'off' in all nodes).

   Use cases for the CL PHBs are briefly described in Section 3.

2.6. Interaction with other PHBs

   Other PHBs and PHB groups may be deployed in the same DS node or
   domain with a CL PHB. CL traffic is prioritised over all other PHBs,
   but the admission control procedure prevents the CL traffic affecting
   their service.

   It is believed that the CL-ramp-PHB configured and flexible bandwidth
   cases belong to the same PHB because they can both be used in the
   same domain, since the difference between them doesn't affect the way
   the ingress and egress nodes do admission control and metering.

   It is believed that the CL-step-PHB and CL-ramp-PHB are different
   PHBs, because they cannot be used within the same domain, since the
   CE codepoint is interpreted differently. With the CL-step-PHB a
   single CE packet can cause the admission controller to block a new
   microflow, whereas with the CL-ramp-PHB sufficient packets are needed
   to estimate the congestion level. However, it would be possible to
   use CL-step-PHB for probe traffic and CL-ramp-PHB for data traffic
   within the same domain.

2.7. Interaction with default ECN behaviour

   The CL PHBs define behaviour for setting the CE codepoint that is
   different from the default ECN marking behaviour [RFC3168]. To
   address the concerns of [Floyd] it therefore must be ensured that the
   packets only travel through nodes with a CL PHB. This could be done
   by signalling (to verify that the nodes on the path all understand


Briscoe                Expires January 11 2006                [Page 9]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   the CL PHB) or by configuration (eg in usage scenario 2 the whole
   domain runs the CL-ramp-PHB).

2.8. Mutability

   CL packets with the ECN field cleared (`Not ECT') should be re-marked
   to Best Effort. In most scenarios, all CL packets should be ECN-
   capable, so it MAY be appropriate to raise a suitable management
   alarm the first time this is not the case.

   In the edge-to-edge usage scenario, which is described below in
   Section 3.2, if some packets of a CL microflow are over the
   reservation at the ingress edge, then they SHOULD be marked to Best
   Effort.

2.9. Microflow misordering

   Packets that belong to a single microflow within the CL behaviour
   aggregate passing through a device SHOULD NOT be re-ordered in normal
   operation of the device. In a microflow where packets are marked to
   Best Effort by the ingress node (see Mutability sub-section) they may
   become misordered, but note that these packets are never part of the
   CL behaviour aggregate.

2.10. Recommended codepoint for this PHB

   Codepoint xxxxxx is RECOMMENDED for the CL-ramp-PHB and codepoint
   xxxxxx is RECOMMENDED for the CL-step-PHB. RECOMMENDED codepoints are
   needed, rather than EXP/LU ones, to enable host-to-host and inter-
   operator usage.

2.11. Tunnelling

   When CL packets are tunnelled, the tunnelling packets SHOULD be
   marked as CL and the ECN field copied between headers as in RFC3168.

2.12. Security Considerations

   TBD

2.13. IANA considerations

   TBD.






Briscoe                Expires January 11 2006               [Page 10]


Internet-Draft    Controlled Load per hop behaviour          July 2005




3. Use cases

   Two possible usage scenarios for the CL PHBs are discussed in this
   section:

   o A host-to-host service, potentially through several domains

   o An edge-to-edge service across a single domain or across
      cooperating domains.



3.1. Host-to-host service

   This usage scenario is based on [RTECN-usage]. A source wanting to
   establish a real time inelastic microflow sends probe packets, which
   have their DSCP set to the value for the CL-step-PHB and the ECN
   field set to the ECT codepoint. Nodes en route set the CE codepoint
   if necessary as an "early warning" of potential congestion. The
   receiver informs the source about the value(s) of the ECN field of
   the probe packets, enabling the source to decide whether or not the
   new microflow is acceptable. To ease migration, [RTECN] suggests that
   to start with the mechanism is deployed in a limited number of nodes
   - those known to be points where the bandwidth is constrained.



3.2. Edge-to-edge service

   This usage scenario is described more fully in [CL-arch]. The CL-
   ramp-PHB is used within a single domain. The ingress node to the
   domain sets the DSCP to the value for the CL-ramp-PHB and the ECN
   field set to the ECT codepoint. Nodes en route set the CE codepoint
   if necessary as an "early warning" of potential congestion. The
   egress node of the domain meters CL-ramp packets that have their CE
   codepoint set. It calculates the fraction of the total (CL-ramp) bits
   that are in CE packets. The calculation is done as an exponentially
   weighted moving average ('Congestion-Level-Estimate'). Congestion-
   Level-Estimate provides an estimate of how near the domain is getting
   to a load where the CL-ramp traffic will start suffering significant
   delays. Note that the metering and calculation are done separately
   for CL-ramp packets from each ingress router, because (as discussed
   in Section 1) there may be sufficient capacity on all the nodes on
   the path between one ingress node and a particular egress, but not
   from a second ingress.


Briscoe                Expires January 11 2006               [Page 11]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   In order to decide whether to admit a new real time inelastic
   microflow, the current value for Congestion-Level-Estimate is
   compared with a threshold value; if it is greater then the request is
   refused, otherwise it is accepted. It would be possible to have
   different service priorities (eg for emergency calls or important
   users) by the ingress having different thresholds for Congestion-
   Level-Estimate.

   The details depend on the end-to-end signalling protocol, but for
   example with RSVP, Congestion-Level-Estimate is included as an opaque
   object within the RESV message. If the current value for Congestion-
   Level-Estimate is unknown (eg if there are no microflows at present
   between the relevant ingress and egress nodes), then probe packets
   are sent, from which the egress node can initialise its meter. These
   probe packets could use either the CL-ramp-PHB or the CL-step-PHB.
   It is also possible for several adjacent domains to cooperate. Then
   only the ingress and egress nodes of the combined region take part in
   the admission control procedure; border nodes within the combined
   region do not take part in signal processing or hold path state. The
   domains can even be run by different operators; in this case the
   border routers between operators only have to do bulk accounting -
   per microflow metering and policing is not needed [Briscoe].



4. Acknowledgements

   We thank Joe Babiarz for very helpful discussion about this document
   and [RTECN].

   This work evolved from the Guaranteed Stream Provider developed in
   the M3I project [GSPa, GSP-TR], which in turn was based on the
   theoretical work of Gibbens and Kelly [DCAC].

5. Comments solicited

   Comments and questions are encouraged and very welcome. They can be
   sent to the Transport Area Working Group's mailing list,
   tsvwg@ietf.org, and/or to the authors (either individually or
   collectively at gqs@jungle.bt.co.uk).








Briscoe                Expires January 11 2006               [Page 12]


Internet-Draft    Controlled Load per hop behaviour          July 2005


6. References

   A later version will distinguish normative and informative
   references.

   [Briscoe]     Bob Briscoe and Steve Rudkin, "Commercial Models for
                 IP Quality of Service Interconnect", BT Technology
                 Journal, Vol 23 No 2, April 2005.

   [CL-arch]     B. Briscoe, G. Corliano, P. Eardley, P. Hovell, A.
                 Jacquet, D. Songhurst, 'An architecture for edge-to-
                 edge controlled load service using distributed
                 measurement-based admission control', draft-briscoe-
                 tsvwg-cl-architecture-00.txt", (work in progress),
                 July 2005

   [DCAC]        Richard J. Gibbens and Frank P. Kelly "Distributed
                 connection acceptance control for a connectionless
                 network", In: Proc. International Teletraffic Congress
                 (ITC16), Edinburgh, pp. 941ù952 (1999).

   [Floyd]       S. Floyd, 'Specifying Alternate Semantics for the
                 Explicit Congestion Notification (ECN) Field', draft-
                 floyd-ecn-alternates-00.txt (work in progress), April
                 2005

   [GSPa]        Karsten (Ed.), Martin "GSP/ECN Technology \&
                 Experiments", Deliverable: 15.3 PtIII, M3I Eu Vth
                 Framework Project IST-1999-11429, URL:
                 http://www.m3i.org/ (February, 2002) (superseded by
                 [GSP- TR])

   [GSP-TR]      Martin Karsten and Jens Schmitt, "Admission Control
                 Based on Packet Marking and Feedback Signalling ¡--
                 Mechanisms, Implementation and Experiments", TU-
                 Darmstadt Technical Report TR-KOM-2002-03, URL:
                 http://www.kom.e-technik.tu-
                 darmstadt.de/publications/abstracts/KS02-5.html (May,
                 2002)

   [Reid]        ABD Reid, 'Economics and scalability of QoS
                 solutions', BT Technology Journal, Vol 23 No 2, April
                 2005

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.



Briscoe                Expires January 11 2006               [Page 13]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   [RFC2211]     J. Wroclawski, Specification of the Controlled-Load
                 Network Element Service, September 1997

   [RFC2309]     Braden, B., et al., "Recommendations on Queue
                 Management and Congestion Avoidance in the Internet",
                 RFC 2309, April 1998.

   [RFC2474]     Nichols, K., Blake, S., Baker, F. and D. Black,
                 "Definition of the Differentiated Services Field (DS
                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
                 December 1998

   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                 Z. and W. Weiss, "An Architecture for Differentiated
                 Services", RFC 2475, December 1998.

   [RFC2597]     Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski,
                 "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC3168]     Ramakrishnan, K., Floyd, S. and D. Black "The Addition
                 of Explicit Congestion Notification (ECN) to IP", RFC
                 3168, September 2001.

   [RFC3246]     B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le
                 Boudec, W. Courtney, S. Davari, V. Firoiu, D.
                 Stiliadis, 'An Expedited Forwarding PHB (Per-Hop
                 Behavior)', RFC 3246, March 2002.

   [RTECN]       Babiarz, J., Chan, K. and V. Firoiu, 'Congestion
                 Notification Process for Real-Time Traffic', draft-
                 babiarz-tsvwg-rtecn-03" Work in Progress, February
                 2005.

   [RTECN-usage] Alexander, C., Ed., Babiarz, J. and J. Matthews,
                 'Admission Control Use Case for Real-time ECN, draft-
                 alexander-rtecn-admission-control-use-case-00', Work
                 in Progress, February 2005.

   [vq]          Costas Courcoubetis and Richard Weber "Buffer Overflow
                 Asymptotics for a Switch Handling Many Traffic
                 Sources" In: Journal Applied Probability 33 pp. 886--
                 903 (1996).







Briscoe                Expires January 11 2006               [Page 14]


Internet-Draft    Controlled Load per hop behaviour          July 2005


Authors' Addresses

   Bob Briscoe
   BT Research
   B54/77, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: bob.briscoe@bt.com


   Dave Songhurst
   BT Research
   B54/69, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: dsonghurst@jungle.bt.co.uk


   Philip Eardley
   BT Research
   B54/77, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: philip.eardley@bt.com


   Peter Hovell
   BT Research
   B54/69, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: peter.hovell@bt.com





Briscoe                Expires January 11 2006               [Page 15]


Internet-Draft    Controlled Load per hop behaviour          July 2005


   Gabriele Corliano
   BT Research
   B54/70, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: gabriele.2.corliano@bt.com


   Arnaud Jacquet
   BT Research
   B54/70, Sirius House
   Adastral Park
   Martlesham Heath
   Ipswich, Suffolk
   IP5 3RE
   United Kingdom
   Email: arnaud.jacquet@bt.com


Intellectual Property Statement

   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




Briscoe                Expires January 11 2006               [Page 16]


Internet-Draft    Controlled Load per hop behaviour          July 2005


Disclaimer of Validity

   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 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.

Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.































Briscoe                Expires January 11 2006               [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/