home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-intserv-control-flow-01.txt < prev    next >
Text File  |  1997-10-09  |  26KB  |  731 lines
  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                   Integrated Services WG
  5. INTERNET-DRAFT                                S. Jamin/C. Jin/L. Breslau
  6. draft-ietf-intserv-control-flow-01.txt                 UMich/UMich/Xerox
  7.                                                                Oct, 1997
  8.                                                         Expires: 4/15/98
  9.  
  10.  
  11.  
  12.  
  13.           A Measurement Based Admission Control Algorithm for
  14.    Controlled-Load Service with a Reference Implementation Framework
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as "work in progress."
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  32.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36.    This document is a product of the Integrated Services working group
  37.    of the Internet Engineering Task Force.  Comments are solicited and
  38.    should be addressed to the working group's mailing list at int-
  39.    serv@isi.edu and/or the author(s).
  40.  
  41.  
  42. Abstract
  43.  
  44.  
  45.    Controlled-Load Service provides data flows with an enhanced quality
  46.    of service, in the form of low packet delay and a low probability of
  47.    packet loss even under congestion.  A network element providing
  48.    Controlled-Load Service can use an admission control algorithm to
  49.    limit the number of data flows receiving the service.  In this
  50.    document we describe an admission control algorithm for Controlled-
  51.    Load Service.  This algorithm is not intended for IETF
  52.  
  53.  
  54.  
  55. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 1]
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  63.  
  64.  
  65.    standardization.  Rather, it is presented for informational purposes
  66.    only.
  67.  
  68.    We also present a reference implementation framework for the
  69.    measurement-based admission control algorithm.  Our implementation
  70.    separates the measurement from the actual admission control decision
  71.    to provide the flexibility of using different algorithms in bandwidth
  72.    estimation and admission control.
  73.  
  74.  
  75. Introduction
  76.  
  77.  
  78.    Controlled-Load Service (CL), as defined in [Wro95], is an enhanced
  79.    quality of service intended to support applications requiring
  80.    performance better than that provided by traditional best-effort
  81.    service. Even under congestion, network elements offering CL are
  82.    expected to provide flows with low delay and low packet loss.
  83.  
  84.    In order to provide this enhanced level of service, network elements
  85.    must limit the number of flows receiving the service.  This can be
  86.    accomplished by requiring applications to make explicit requests for
  87.    service.  Explicit requests for service can be made using a
  88.    reservation setup protocol, such as RSVP [B+96], or some other means.
  89.    Each network element that receives a request for service can either
  90.    accept or reject the request.  We refer to this decision as
  91.    "admission control."
  92.  
  93.    An application requesting CL presents the network element with a
  94.    traffic descriptor to describe its data flow.  This descriptor
  95.    includes a token bucket filter and a peak rate.  The token bucket
  96.    parameters, a rate and bucket depth, represent a loose upper bound on
  97.    the new data flow.  A measurement based admission control algorithm
  98.    (MBAC) admits or rejects a new flow based on measurements of existing
  99.    traffic and the parameterized description of the new flow.  The
  100.    dependence of MBACs on traffic measurements makes the quality of the
  101.    service they provide subject to statistical fluctuation of traffic.
  102.    We expect MBACs to work well only when there is a high degree of
  103.    statistical multiplexing of uncorrelated flows and traffic
  104.    fluctuation is not dominated by a small number of flows.  In this
  105.    document, we describe one such MBAC designed for CL.
  106.  
  107.    Admission control is not an area appropriate for IETF
  108.    standardization.  Rather, vendors and service providers are free to
  109.    implement and deploy any admission control algorithm that enables a
  110.    network element to meet the service requirements of the Controlled-
  111.    Load specification.  Indeed, admission control can be seen as an area
  112.    for product differentiation.  Hence, the algorithm described here is
  113.  
  114.  
  115.  
  116. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 2]
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  124.  
  125.  
  126.    presented for informational purposes only, providing a single example
  127.    of an MBAC that may be used as a reference algorithm.
  128.  
  129.    Various MBACs suitable for use with CL have been proposed in the
  130.    academic literature.  See, for example, algorithms described in
  131.    [Flo96, JSD97, GK97].  The algorithm described here was first
  132.    proposed in [JS97] and was shown to perform as well as several other
  133.    MBACs.  This algorithm is designed to be very simple to implement.
  134.    We believe that it meets the requirements given in the CL
  135.    specification, performs as well as other known algorithms, and
  136.    provides sufficient configuration parameters to allow it to be
  137.    deployed in a variety of settings.  We refer the interested readers
  138.    to the above references both for further details on the other MBACs
  139.    and for more background on the MBAC described here.
  140.  
  141.    The remainder of this document is organized as follows.  In the next
  142.    section we describe the admission control algorithm.  Next, we
  143.    describe one measurement process that may be used to provide load
  144.    estimates that are used as inputs to the admission control algorithm.
  145.    After discussing the different tuning parameters that allow the
  146.    algorithm to be used in various settings, we present a reference
  147.    implementation framework of the algorithm.
  148.  
  149.  
  150. The Admission Control Algorithm
  151.  
  152.  
  153.    Our admission control algorithm takes as input L, a load estimate
  154.    produced by the measurement process (described in the next section),
  155.    C, the link bandwidth, upsilon, a user defined aggregate loading
  156.    factor, kappa, a user defined new flow effect factor, and r, the
  157.    token bucket rate of the new flow requesting admission.  Whenever a
  158.    new flow requests admittance under CL, the flow is admitted if the
  159.    following inequality is satisfied:
  160.  
  161.                         L < upsilon * C - kappa * r
  162.  
  163.    Otherwise the flow is rejected.
  164.  
  165.  
  166. The Measurement Process
  167.  
  168.  
  169.    The purpose of the measurement process is to compute an estimate of
  170.    the network load attributed to data packets receiving Controlled-Load
  171.    Service.  This estimate, which we refer to as L, is used as input to
  172.    the admission control algorithm.  We describe a time window
  173.    measurement process here.  An alternative measurement process using
  174.  
  175.  
  176.  
  177. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 3]
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  185.  
  186.  
  187.    exponential averaging may be used instead [Flo96].
  188.  
  189.    The time window measurement process uses 2 parameters, T and S.  T is
  190.    the measurement window and S is the sampling period, with S <= T.
  191.  
  192.    During every sampling period, S, an average load is computed.  This
  193.    average load is simply the sum of bits in packets receiving CL
  194.    divided by the length of the sampling period.  We note that computing
  195.    average load for a given sampling period is basic to most measurement
  196.    processes advocated for use with MBAC.
  197.  
  198.    The only per-packet action required by the measurement process is to
  199.    accumulate the bit-count of packets receiving CL service.  All other
  200.    processing occurs with low frequency.  For performance enhancement, a
  201.    router vendor may wish to implement the per-packet bit counting in
  202.    hardware.  At each operator-defined sampling period S, a software
  203.    process reads and clears the hardware accumulator.  The software
  204.    process also performs the other low frequency processing to compute
  205.    the load estimate.
  206.  
  207.    The load estimate, L, is updated as follows:
  208.  
  209.    1.  At the end of every measurement window, T, L is set to the
  210.    highest average load computed for any S during the previous window.
  211.  
  212.    2.  If a newly computed average load for a given sampling period S is
  213.    larger than the current value of L, L is set to the newly computed
  214.    average.
  215.  
  216.    3.  Whenever a new flow is admitted, the measurement estimate is
  217.    immediately increased by r, the token bucket rate of the newly
  218.    admitted flow.
  219.  
  220.  
  221. The Parameters
  222.  
  223.    In this section we discuss how each of the parameters can be adjusted
  224.    to control the behavior of the algorithm.  The specific settings that
  225.    are appropriate in any deployment environment depend on the
  226.    characteristics of that environment (i.e., the traffic
  227.    characteristics and link bandwidth), on how much Controlled-Load
  228.    traffic a network operator wants to admit on a link, and on the level
  229.    of risk the network operator is willing to take that the service
  230.    requirements are occasionally violated.
  231.  
  232.    T -- Measurement Window
  233.  
  234.    Increasing T increases the amount of history remembered by the
  235.  
  236.  
  237.  
  238. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  246.  
  247.  
  248.    measurement process.  The values of T will be some integral multiple
  249.    of the value of S.
  250.  
  251.    S -- Sampling Period
  252.  
  253.    For a fixed T, decreasing S makes this measurement process more
  254.    sensitive to bursts of data.  Appropriate values of S are likely to
  255.    be on the order of thousands of packet transmission times.
  256.  
  257.    upsilon -- Aggregate Loading Factor
  258.  
  259.    Upsilon controls the amount of the link resources that can be used by
  260.    CL traffic.  Decreasing upsilon makes the admission control algorithm
  261.    more conservative and reduces the number of CL flows admitted on a
  262.    link.  Network operator willing to commit all their link capacity to
  263.    CL traffic might want to start off setting upsilon to 0.7.  Depending
  264.    on the burstiness of extant traffic, upsilon may be tuned to values
  265.    higher than 1.  Larger values of upsilon decreases the "safety
  266.    margin" of slack bandwidth that may be used to accommodate sudden
  267.    bursts in traffic.  Hence network operators that operate their
  268.    network with high upsilon run a higher risk of violating CL service
  269.    description.
  270.  
  271.    kappa -- New Flow Effect Factor
  272.  
  273.    Kappa reflects the network operator's assessment of the effect new
  274.    flows may have on traffic load.  Kappa of 1 provides for the worst
  275.    case where a new flow may send data at a constant bit rate consummate
  276.    with its token rate.
  277.  
  278.    Network service providers should have the ability to control the
  279.    settings of each of these parameters, conditioned upon the network
  280.    link speed, extant traffic characteristics, and the providers' goals
  281.    (i.e., the percentage of bandwidth set aside for other services such
  282.    as best-effort, the degree of risk aversion, etc.).  Network
  283.    operators will need to monitor the performance of the algorithm over
  284.    time and adjust these parameters to meet changing traffic
  285.    characteristics and service requirements.  Automatic tuning of these
  286.    parameters is also possible [CKT96].
  287.  
  288.    We mentioned in the Introduction that MBAC works well only on links
  289.    with high degree of statistical multiplexing where current traffic
  290.    measurements are reasonable predictors of future load.  For links
  291.    with low degree of statistical multiplexing, the algorithm presented
  292.    here may be used without the measurement part, for example by
  293.    maintaining L as the sum of the token rates of all admitted flows,
  294.    with the parameters upsilon and kappa both set to 1.
  295.  
  296.  
  297.  
  298.  
  299. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 5]
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  307.  
  308.  
  309. Reference Implementation Framework
  310.  
  311.                            +-----------+
  312.                            |           |    +-------------+
  313.                            | Admission |<---| ADC Control |
  314.        +=============+     |  Control  |    +-------------+
  315.        | Reservation |<--->|           | +-------------------+
  316.        +=============+     +-----------+ | Estimator Control |
  317.               ^                          +-------------------+
  318.               |               USER                   ^
  319.    ***********V**************************************V********
  320.               ^               KERNEL                 ^
  321.     flow and  |                                +-----V-----+
  322.     class     |            +===========+       | Estimator |
  323.     management|            |           |       +-----------+
  324.         +=====V======+     | Scheduler |             ^
  325.         | Classifier |---->|           |---+         |
  326.         +============+     +===========+   |   +-----V-------+
  327.               ^                  |         +-->| Measurement |
  328.               |                  |             +-------------+
  329.               |                  V
  330.       incoming packets     outgoing packets
  331.  
  332.                     Figure 1: Overview of the MBAC
  333.  
  334.  
  335.    We present in this section a description of an implementation of
  336.    MBAC.  This description represents our on-going efforts to implement
  337.    MBAC on several BSD-derived UNIX platforms.  A guiding principle of
  338.    our implementation is to put components of the architecture that
  339.    require high-frequency updates in the UNIX kernel, leaving the rest
  340.    in user space.
  341.  
  342.    Figure 1.0 is an abstraction of the implementation shown with the
  343.    other integrated services modules, i.e. packet classifier, scheduler,
  344.    and a reservation daemon, which we expect to be present on the
  345.    system. Inside the kernel, the classifier intercepts each output
  346.    packet and determines the output queue to which the packet belongs.
  347.    The scheduler selects the next packet and dispatch it to the output
  348.    interface whenever the interface is ready to transmit a new packet.
  349.    The user level reservation daemon makes new bandwidth reservations or
  350.    deletes existing ones.  The remaining five functional units are part
  351.    of the MBAC, consisting of a measurement unit and an estimator unit
  352.    in the kernel, and the ADC (ADmission Control) unit on the user
  353.    level. The measurement unit counts the total number of bits sent
  354.    through each interface; the estimator unit computes bandwidth usage
  355.    estimates for use in admission control equations.  These two
  356.    functions require access to low level network data structures and
  357.  
  358.  
  359.  
  360. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 6]
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  368.  
  369.  
  370.    need to make frequent computations, which introduces tremendous
  371.    overhead if implemented on the user level.  The user level module
  372.    includes ADC, ADC Control, and Estimator Control. The ADC unit
  373.    implements the actual admission control algorithm.  The other two
  374.    units, ADC Control and Estimator Control, allow users to tune the
  375.    parameters of the admission control algorithm and bandwidth averaging
  376.    techniques used in the kernel.
  377.  
  378.    The Measurement unit inside the kernel maintains an accounting of the
  379.    number of bits sent through each interface.  It adds to the count of
  380.    bits sent whenever a packet is dispatched by the scheduler.
  381.  
  382.            +---------------------+           +-------------+
  383.            | meas_readresetCLM() |<----?---->|             |
  384.            +---------------------+           |             |
  385.            +---------------------+           +-------------+
  386.            | meas_updateCLMq()   |---------->|  CLM_entry  |
  387.            +---------------------+           +-------------+
  388.            +---------------------+           |             |
  389.            | meas_newCLM()       |---------->|             |
  390.            +---------------------+           +.............+
  391.  
  392.                    Figure 2: the Measurement Unit
  393.  
  394.    The measurement unit consists of three interface functions and a data
  395.    structure, CLMq (Controlled Load Measurement queue.)  The details of
  396.    this unit are shown in Figure 2.  The CLMq maintains an entry for
  397.    each Controlled Load class.  In the simplest case there will be one
  398.    CL class per interface.  In the presence of link-sharing, each share
  399.    can have its own CL class.  The structure of each entry is shown as a
  400.    CLM_entry type in C language:
  401.  
  402.            typedef struct  _CLM{
  403.                    ClassID         *cid;
  404.                    unsigned long   bits_sent;
  405.                    unsigned int    multiplier;
  406.            } CLM_entry;
  407.  
  408.    The first member is a pointer to a ClassID by which the entries in
  409.    the CLMq is addressed.  The ClassID of a CLMq entry associates the
  410.    entry with its respective CL queue the Scheduler maintains.  Since
  411.    the Scheduler is not part of our architecture, we assume no prior
  412.    knowledge of the data structures it uses and hence keep only a
  413.    pointer for a class ID.  The member bits_sent is incremented by the
  414.    packet size in bits whenever a packet belonging to the current class
  415.    is dispatched by the scheduler; the member multiplier is provided as
  416.    a safety factor in case the number of bits sent exceeds a 32 bit long
  417.    integer.  There is currently no support for queueing delay
  418.  
  419.  
  420.  
  421. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 7]
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  429.  
  430.  
  431.    measurement.
  432.  
  433.    The first interface function meas_updateCLMq is invoked by the
  434.    scheduler after it sends a packet out to a network interface.
  435.    meas_updateCLMq updates the CLMq entry according to the class of the
  436.    packet. Function meas_readresetCLMq is provided to the rest of the
  437.    system as an interface to access the CLMq; it reads, or reads and
  438.    resets, members of a CLMq entry.  The last of the three, meas_newCLM
  439.    adds an entry for a new class to the end of the CLMq.
  440.  
  441.         +-----------------+ \    +-----------+
  442.     +-->| est_estimator() |  \   |           |
  443.     |   +-----------------+   \  +-----------+
  444.     |   | est_readmeas()  |    > | est_entry |
  445.     |   +-----------------+   /  +-----------+
  446.     |   | est_readest()   |  /   |           |
  447.     |   +-----------------+ /    +-----------+
  448.     |
  449.     |               +-----------------+     Estimator Queue
  450.     +---------------| est_change_fp() |
  451.                     +-----------------+
  452.  
  453.                    Figure 3: Estimator Unit inside the Kernel
  454.  
  455.    The Estimator inside the kernel is illustrated in Figure 3.  It is
  456.    invoked periodically to compute the sample and average bandwidth
  457.    usage estimate. A function est_change_fp and an estimation queue
  458.    constitute the estimator unit.  The function est_changefp can change
  459.    the estimation algorithm for any class; this is necessary since
  460.    different classes may have different flow characteristics. The
  461.    estimation queue is organized simply as an array.  The structure of
  462.    an entry in an estimation queue is shown as a structure in C
  463.    language:
  464.  
  465.            typedef struct _est{
  466.                    ClassID *       cid;
  467.                    unsigned long   bandwidth_avg;
  468.                    unsigned long   bandwidth_var;
  469.                    unsigned int *est_estimator(ClassID *, void *);
  470.                    unsigned int *est_readmeas(ClassID *, void *);
  471.                    unsigned int *est_readest(ClassID *, void *);
  472.            } est_entry;
  473.  
  474.    Each entry in the queue stores the average and the variance of the
  475.    bandwidth usage.  The function pointer est_estimator points to the
  476.    actual estimation routine that calculates quantities such as
  477.    bandwidth usages or queueing delays. Currently only bandwidth usage
  478.    estimation is supported, but we allow for extension to estimate other
  479.  
  480.  
  481.  
  482. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 8]
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  490.  
  491.  
  492.    flow characteristics in the implementation framework.  The function
  493.    est_readmeas allows access to the raw measurement samples and the
  494.    function est_readest allows access to the estimate.  The user level
  495.    processes can thus access both results of estimation calculation and
  496.    the raw data in the CLMq through a system call.
  497.  
  498.                         +-----------------+
  499.                         | adc_changealgor |
  500.                         +--------^--------+
  501.                                  |
  502.       +-------------+   +--------V--------+   +-----------------+
  503.       | Reservation |<->| adc_algorithm[] |<->| est_changeparam |
  504.       +------^------+   +-----------------+   +------^----------+
  505.              |                                       |
  506.          +---V---------------------------------------V-----+
  507.          |                     KERNEL                      |
  508.          +-------------------------------------------------+
  509.  
  510.                   Figure 4: MBAC on the User Level
  511.  
  512.    The user level MBAC is shown in Figure 4. The ADC unit consists of an
  513.    array of function pointers, adc_algorithm[], with one entry for each
  514.    CL class.  This design, again, allows for the flexibility of using a
  515.    different admission control algorithms for each CL classes.  The ADC
  516.    Control unit is the function adc_changealgor, through which network
  517.    administrators can select the admission control routine to use.  The
  518.    third unit, est_changeparam, is the Estimator Control unit for
  519.    changing the estimation mechanism inside the kernel; this enables
  520.    network administrators to tailor the averaging algorithm according to
  521.    their specific needs.
  522.  
  523.  
  524. Function Prototypes
  525.  
  526.  
  527.    We provide a list of prototypes of the major proposed functions and a
  528.    brief description of each function.  Note that the ClassID argument
  529.    tells each of these functions which CL class to operate on.
  530.  
  531.    Measurement unit:
  532.  
  533.    unsigned int meas_updateCLMq(ClassID *cid, unsigned long packet_size,
  534.    unsigned int options); meas_updateCLMq updates the bits_sent member
  535.    of a CLMq entry indexed by *cid.
  536.  
  537.    unsigned int meas_newCLM(ClassID *cid, char *options); meas_newCLM
  538.    creates a new entry in the CLMq and initialize the storage for *cid.
  539.  
  540.  
  541.  
  542.  
  543. Jamin/Jin/Breslau           Expires 4/15/98                     [Page 9]
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  551.  
  552.  
  553.    CLM_entry *meas_readresetCLM(ClassID *cid, CLM_entry *resetvalue,
  554.    unsigned int options); meas_readresetCLM reads or resets an entry in
  555.    the CLMq indexed by cid. If the resetvalue is a null pointer, the
  556.    function will read the entry indexed by *class and return it;
  557.    otherwise the entry is set to *resetvalue, and the final entry is
  558.    returned to the caller.
  559.  
  560.    Estimator unit:
  561.  
  562.    unsigned int est_changefp(ClassID *cid,  unsigned int EstID, unsigned
  563.    int options); est_changefp changes the estimation functions according
  564.    to EstID for class *cid.
  565.  
  566.    ADC unit:
  567.  
  568.    unsigned int *adc_algorithm[](ClassID *cid, unsigned long flowBW,
  569.    unsigned int options); adc_algorithm takes the class of the new flow
  570.    *cid in this case) and the flow's bandwidth requirement.  It returns
  571.    a nonzero value if the flow can be admitted and 0 otherwise.
  572.  
  573.    ADC Control unit:
  574.  
  575.    unsigned int adc_changealgor(ClassID *cid, unsigned int AlgorID,
  576.    unsigned int options); adc_changealgor changes the admission control
  577.    algorithm of a particular class to the algorithm designated by
  578.    AlgorID.
  579.  
  580.    Estimator Control unit:
  581.  
  582.    unsigned int est_changeparam(ClassID *cid, unsigned int EstID,
  583.    unsigned int options); est_changeparam is the user level equivalent
  584.    of est_changefp in the kernel.
  585.  
  586.  
  587. Security Considerations
  588.  
  589.  
  590.    Security considerations are not discussed in this memo.
  591.  
  592.  
  593. References
  594.  
  595.  
  596.    [B+96] R. Braden (ed.) et al. "Resource ReSerVation Protocol",
  597.    Internet Draft, June 1996.
  598.  
  599.    [CKT96] C. Casetti, J. Kurose, and D. Towsley. "An Adaptive Algorithm
  600.    for Measurement-based Admission Control in Integrated Services Packet
  601.  
  602.  
  603.  
  604. Jamin/Jin/Breslau           Expires 4/15/98                    [Page 10]
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  612.  
  613.  
  614.    Networks", Proc. of the Protocols for High Speed Networks Workshop,
  615.    Oct. 1996.
  616.  
  617.    [Flo96] S. Floyd. "Comments on Measurement-based Admissions Control
  618.    for Controlled-Load Service", submitted for publication, 1996.  Also
  619.    available as ftp://ftp.ee.lbl.gov/papers/admit.ps.Z.
  620.  
  621.    [GK97] R.J. Gibbens and F.P. Kelly, "Measurement-Based Connection
  622.    Admission Control", Proc. of the International Teletraffic Congress
  623.    15, Jun. 1997.
  624.  
  625.    [JSD97] S. Jamin, S.J. Shenker, and P.B. Danzig, "Comparison of
  626.    Measurement-based Admission Control Algorithms for Controlled-Load
  627.    Service", Proc. of IEEE Infocom 97, Apr. 1997.  Also available as
  628.    http://netweb.usc.edu/jamin/admctl/info97.ps.gz.
  629.  
  630.    [JS97] S. Jamin, S.J. Shenker, "Measurement-based Admission Control
  631.    Algorithms for Controlled-Load Service: A Structural Examination",
  632.    Univ. of Michigan, CSE-TR-333-97, Apr. 1997.  Available as
  633.    http://irl.eecs.umich.edu/jamin/papers/mbac/clmbac.ps.gz
  634.  
  635.    [Wro95] J. Wroclawski.  "Specification of Controlled-Load Network
  636.    Element Service", Internet Draft, November 1995, <draft-ietf-
  637.    intserv-ctrl-load-svc-01.txt>.
  638.  
  639.  
  640. Author's Address:
  641.  
  642.  
  643.    Sugih Jamin
  644.    University of Michigan
  645.    CSE/EECS
  646.    1301 Beal Ave.
  647.    Ann Arbor, MI 48109-2122
  648.    jamin@eecs.umich.edu
  649.    +1 313 763 1583
  650.    +1 313 763 1503 (FAX)
  651.  
  652.    Cheng Jin
  653.    University of Michigan
  654.    CSE/EECS
  655.    1301 Beal Ave.
  656.    Ann Arbor, MI 48109-2122
  657.    chengjin@eecs.umich.edu
  658.    +1 313 763 6131
  659.  
  660.    Lee Breslau
  661.    Xerox PARC
  662.  
  663.  
  664.  
  665. Jamin/Jin/Breslau           Expires 4/15/98                    [Page 11]
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672. INTERNET-DRAFT    draft-ietf-intserv-control-flow.txt      October, 1997
  673.  
  674.  
  675.    3333 Coyote Hill Road
  676.    Palo Alto, CA  94304-1314
  677.    breslau@parc.xerox.com
  678.    +1 415 812 4402
  679.    +1 415 812 4471 (FAX)
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726. Jamin/Jin/Breslau           Expires 4/15/98                    [Page 12]
  727.  
  728.  
  729.  
  730.  
  731.