home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-bmwg-call-00.txt < prev    next >
Text File  |  1996-11-16  |  20KB  |  778 lines
  1.  
  2.  
  3. Network Working Group                                       R. Craig
  4. INTERNET-DRAFT                                         Cisco Systems
  5. Expiration Date:  May 1997                                  Nov 1996
  6.  
  7.                  Terminology for Cell/Call Benchmarking
  8.                      <draft-ietf-bmwg-call-00.txt>
  9.  
  10. Status of this Memo
  11.  
  12.    This document is an Internet-Draft.  Internet-Drafts are working
  13.    documents of the Internet Engineering Task Force (IETF), its areas,
  14.    and its working groups.  Note that other groups may also distribute
  15.    working documents as Internet-Drafts.
  16.  
  17.    Internet-Drafts are draft documents valid for a maximum of six months
  18.    and may be updated, replaced, or obsoleted by other documents at any
  19.    time.  It is inappropriate to use Internet- Drafts as reference
  20.    material or to cite them other than as ``work in progress.''
  21.  
  22.    To learn the current status of any Internet-Draft, please check the
  23.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  24.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  25.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  26.    ftp.isi.edu (US West Coast).
  27.  
  28. Abstract
  29.  
  30.    The purpose of this draft is to add terminology specific to the cell
  31.    and call-based switch environment to that defined by the Benchmarking
  32.    Methodology Working Group (BMWG) of the Internet Engineering Task
  33.    Force (IETF) in RFC1242.
  34.  
  35.    While primarily directed towards wide area switches, portions of the
  36.    document may be useful for benchmarking other devices such as ADSU's.
  37.  
  38. 1.  Introduction
  39.  
  40.    In light of the increasing use of cell-based and/or circuit-switched
  41.    transport layers in building networks, it would be useful to develop
  42.    a set of benchmarks with which to compare technologies,
  43.    implementation strategies, and products.
  44.  
  45.    1.1  Terminology Brought Forward
  46.  
  47.       The terminology defined in RFC 1242 applies equally well to this
  48.       memo.  There is also a certain amount of overlap with terms
  49.       defined in draft-ietf-bmwg-lanswitch-00.txt.
  50.  
  51.  
  52.  
  53.  
  54. Benchmarking Methodology Working Group                          [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  61.  
  62.  
  63. 2.  Definition Format (from RFC1242)
  64.  
  65.    Term to be defined.
  66.  
  67.    Definition:
  68.       The specific definition for the term.
  69.  
  70.    Discussion:
  71.       A brief discussion of the term, its application and any
  72.       restrictions on measurement procedures.
  73.  
  74.    Measurement units:
  75.       Units used to record measurements of this term, if applicable.
  76.  
  77. 3.  Term Definitions
  78.  
  79. 3.1  Virtual Circuit
  80.  
  81.    This group applies to those switches that are connection-oriented.
  82.  
  83.    3.1.1  Call setup time
  84.  
  85.       Definition:  the length of time for the virtual circuit to be
  86.       established.
  87.  
  88.       Discussion:  as measured from the initiation of the signalling to
  89.       circuit establishment.
  90.  
  91.       Measurement units:  fractional seconds
  92.  
  93.       Issues:
  94.  
  95.       See also:
  96.  
  97.    3.1.2  Call setup rate (sustained)
  98.  
  99.       Definition:  the maximum sustained rate of successful connection
  100.       establishment.
  101.  
  102.       Discussion:  without loss of existing calls.
  103.  
  104.       Measurement units:  calls per second
  105.  
  106.       Issues:
  107.  
  108.       See also:
  109.  
  110.    3.1.3  Call maintenance overhead
  111.  
  112.  
  113.  
  114. Benchmarking Methodology Working Group                          [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  121.  
  122.  
  123.       Definition:  the amount of work required to maintain the calls
  124.       that have been established.
  125.  
  126.       Discussion:  a method to obtain the desired result would be to
  127.       benchmark with PVC's in place, then with SVC's.  The difference in
  128.       results would be the overhead.
  129.  
  130.       Measurement units:
  131.  
  132.       Issues:
  133.  
  134.       See also:
  135.  
  136.    3.1.4  Call teardown time
  137.  
  138.       Definition:  the length of time for the virtual circuit to be torn
  139.       down.
  140.  
  141.       Discussion:  measured from the start of the signalling to the
  142.       freeing of the resources associated with that call (end to end, if
  143.       applicable).
  144.  
  145.       Measurement units:  fractional seconds
  146.  
  147.       Issues:
  148.  
  149.       See also:
  150.  
  151.    3.1.5  Call teardown rate (sustained)
  152.  
  153.       Definition:  the maximum rate at which calls can be successfully
  154.       torn down.
  155.  
  156.       Discussion:  without loss of existing calls, and without failure
  157.       to tear down any calls that have been signalled to be destroyed.
  158.  
  159.       Measurement units:  teardowns per second
  160.  
  161.       Issues:
  162.  
  163.       See also:
  164.  
  165.    3.1.6  Impact of Signalling on Forwarding
  166.  
  167.       Definition:  cells per second versus calls per second
  168.  
  169.       Discussion:  some devices use the same engine for cell forwarding
  170.       and call maintenance.  In this case, interaction between the two
  171.  
  172.  
  173.  
  174. Benchmarking Methodology Working Group                          [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  181.  
  182.  
  183.       will be inevitable.  More interesting, however, would be the case
  184.       where the two processing functions are clearly separate, yet still
  185.       interact.
  186.  
  187.       Measurement units:  cells per second versus calls per second
  188.  
  189.       Issues:
  190.  
  191.       See also:
  192.  
  193. 3.2  Cell/Packet Interaction
  194.  
  195.    This group applies to cell-based switches, connection-oriented or
  196.    not.
  197.  
  198.    3.2.1  Packet disassembly/reassembly time (peak)
  199.  
  200.       Definition:  the length of time to disassemble a layer 3 packet
  201.       into layer 2 cells, or reassemble cells into a packet.
  202.  
  203.       Discussion:  with no packet or cell loss or corruption.
  204.  
  205.       Measurement units:  the appropriate fraction of a second
  206.  
  207.       Issues:
  208.  
  209.       See also:
  210.  
  211.    3.2.2  Packet disassembly/reassembly rate (sustained)
  212.  
  213.       Definition:  the maximum sustained rate at which packets can be
  214.       disassembled/reassembled into/from cells.
  215.  
  216.       Discussion:  without loss or corruption.
  217.  
  218.       Measurement units:  packets per second
  219.  
  220.       Issues:
  221.  
  222.       See also:
  223.  
  224.    3.2.3  Full packet drop rate (on cell loss)
  225.  
  226.       Definition:  the rate at which cell loss triggering full packet
  227.       drop can be detected/sustained.
  228.  
  229.       Discussion:  When a packet is disassembled into cells, typically
  230.       many cells result.  When these cells are transmitted, they are
  231.  
  232.  
  233.  
  234. Benchmarking Methodology Working Group                          [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  241.  
  242.  
  243.       subject to loss or corruption. The device should recognize at the
  244.       cell/packet boundary that a cell or cells belonging to a given
  245.       packet has been lost and should drop that packet, immediately
  246.       freeing those resources.  A couple of things are of interest here:
  247.       whether the switch is able to detect very small amounts of cell
  248.       loss and correctly drop the associated packets and whether large
  249.       amounts of cell loss perturb this ability in any way.
  250.  
  251.       Measurement units:  (dropped) packets per second
  252.  
  253.       Issues:
  254.  
  255.       See also:
  256.  
  257.    3.2.4  End to end data integrity
  258.  
  259.       Definition:  the percentage of packets (post-reassembly) that
  260.       actually contain undetected data link layer corruption.
  261.  
  262.       Discussion:  some network devices have been known to regenerate
  263.       CRC's over the re-assembled packet (i.e., the CRC is not carried
  264.       end to end), resulting in undetected data link layer corruption or
  265.       re-ordering of cells in a packet.
  266.  
  267.       Measurement units:  percentage
  268.  
  269.       Issues:  production of a stream of traffic containing internal
  270.       checksums sufficiently strong to detect cell re-ordering (the IP
  271.       checksum is not).  The ISIS LSP checksum is.
  272.  
  273.       See also:
  274.  
  275. 3.3  Switch Fabric
  276.  
  277.    This group applies to all switches.
  278.  
  279.    3.3.1  Switch type
  280.  
  281.       Definition:  the type of switch architecture.
  282.  
  283.       Discussion:  Is this of any importance?  We are concerned with
  284.       interesting "metrics" and how they affect the performance of a
  285.       device.  I'm not sure switch architecture falls into this category
  286.       except as an perhaps interesting bit of trivia.
  287.  
  288.       Measurement units:  n/a
  289.  
  290.       Issues:
  291.  
  292.  
  293.  
  294. Benchmarking Methodology Working Group                          [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  301.  
  302.  
  303.       See also:
  304.  
  305.    3.3.2  Topology Table Size
  306.  
  307.       Definition:  number of network elements supported.
  308.  
  309.       Discussion:  switches may support a limited topology due to static
  310.       table sizes or processing limitations.  This is true whether it's
  311.       a "LAN" switch running spanning tree or a "WAN" switch running
  312.       OSPF.  The effect of a limited topology table on a switch in a
  313.       real-world environment can be disastrous.
  314.  
  315.       A similar metric (2.14 Address handling) is mentioned in "draft-
  316.       ietf-bmwg-lanswitch-00.txt".  Here, a more general metric is
  317.       intended.
  318.  
  319.       Measurement units:  number
  320.  
  321.       Issues:  Measuring the effects of an overflow is probably
  322.       meaningless, since in the multi-switch case, there is no longer
  323.       any network to speak of, hence, nothing to measure.
  324.  
  325.       If a device handles table overflow gracefully, this should be
  326.       noted.  Similarly, if a device crashes and burns on table
  327.       overflow, this should be noted.
  328.  
  329.       See also:
  330.  
  331.    3.3.3  Topology Table Learning Rate
  332.  
  333.       Definition:  the rate at which the topology table can be filled or
  334.       updated.
  335.  
  336.       Discussion:  a single switch in isolation learning MAC addresses
  337.       will flood frames when the rate exceeds its learning capability.
  338.       This metric is covered in "2.15 Address learning speed" of
  339.       "draft-ietf-bmwg-lanswitch-00.txt".  We generalize the metric here
  340.       to include the topological databases of routing protocols used in
  341.       switched networks (among the switches themselves) as well as the
  342.       spanning tree recalculation among multiple LAN switches.
  343.  
  344.       Measurement units:  frames per second 1) with maximum diversity of
  345.       addresses, 2) with routing instability introduced.
  346.  
  347.       Issues:
  348.  
  349.       See also:
  350.  
  351.  
  352.  
  353.  
  354. Benchmarking Methodology Working Group                          [Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  361.  
  362.  
  363.    3.3.4  "Bandwidth"
  364.  
  365.       Definition:  internal bandwidth of the switch fabric.
  366.  
  367.       Discussion:  open to some interpretation ;-).  Should probably be
  368.       stated as some combination of the slowest and fastest elements in
  369.       the switching path.
  370.  
  371.       Measurement units:  bits per second
  372.  
  373.       Issues:
  374.  
  375.       See also:
  376.  
  377.    3.3.5  Throughput (from RFC1242) (Cell forwarding rate)
  378.  
  379.       Definition:  The maximum rate at which none of the offered frames
  380.       are dropped by the device.
  381.  
  382.       Discussion:  This metric probably overlaps work being done in the
  383.       ATM Forum.
  384.  
  385.       Measurement units:  cells per second
  386.  
  387.       Issues:
  388.  
  389.       See also:
  390.  
  391.    3.3.6  Non-Blocking factor
  392.  
  393.       Definition:  simultaneous communication amongst multiple ports.
  394.  
  395.       Discussion:  a switch is termed "non-blocking" if multiple ports
  396.       are able to communicate across the switch fabric at the same time.
  397.       If a popular destination port can accept connections from more
  398.       than one source port, the number of those connections is the non-
  399.       blocking factor.  We are interested in the number of ports which
  400.       can simultaneously transmit to a single port (N), the number of
  401.       ports which can simultaneously receive from N other ports (M), and
  402.       the total number of ports on the switch (P).
  403.  
  404.       Measurement units:  N:1, N:M:P (switch-wide measurement)
  405.  
  406.       Issues:
  407.  
  408.       See also:
  409.  
  410. 3.4  Buffering
  411.  
  412.  
  413.  
  414. Benchmarking Methodology Working Group                          [Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  421.  
  422.  
  423.    This group applies to all switches.
  424.  
  425.    3.4.1  Buffering strategy
  426.  
  427.       Definition:  central pool of buffers versus distributed pools.
  428.       Pools of one size versus multiple MTU sizes.
  429.  
  430.       Discussion:  There are tradeoffs in each approach:  bus bandwidth
  431.       and arbitration cycles for centrality, over-configuration of
  432.       memory for distributed pools and one-size-fits-all, greater number
  433.       of drops due to buffer exhaustion with MTU-tailored buffers.
  434.  
  435.       The effectiveness of the given strategy is revealed by the
  436.       performance of the device in overload conditions.  For example,
  437.       one might cause the majority of input buffers to migrate to one
  438.       port which is experiencing a sustained burst of traffic, and then
  439.       cause another port to burst, creating input drops due to lack of
  440.       buffers while the device re-allocates its buffer pool.
  441.  
  442.       Measurement units:  underruns (can't feed transmitting interface
  443.       quickly enough, indicative of bus bw or access problem),
  444.       input/output drops (buffer exhaustion), overruns (another
  445.       indicator of either buffer or CPU exhaustion)
  446.  
  447.       Issues:
  448.  
  449.       See also:
  450.  
  451.    3.4.2  Buffering per output
  452.  
  453.       Definition:  the number of buffers per output port and their size.
  454.  
  455.       Discussion:  It must also be noted whether the buffers are local
  456.       to the line card, whether they are dynamically allocated from a
  457.       central pool, whether they are MTU-tailored, and so on.
  458.  
  459.       Measurement units:  octets
  460.  
  461.       Issues:
  462.  
  463.       See also:  3.4.1
  464.  
  465.    3.4.3  Buffering per input
  466.  
  467.       Definition:  the number of buffers per input port and their size.
  468.  
  469.       Discussion:  see 3.4.2
  470.  
  471.  
  472.  
  473.  
  474. Benchmarking Methodology Working Group                          [Page 8]
  475.  
  476.  
  477.  
  478.  
  479.  
  480. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  481.  
  482.  
  483.       Measurement units:  octets
  484.  
  485.       Issues:
  486.  
  487.       See also:  3.4.1
  488.  
  489. 3.5  Congestion Control
  490.  
  491.    This group applies to all switches.
  492.  
  493.    3.5.1  Congestion avoidance
  494.  
  495.       Definition:  effectiveness of measures taken by the switch to
  496.       avoid congestion.
  497.  
  498.       Discussion:  connections that are bursting above their committed
  499.       rate may have cells buffered at the ingress, in order to avoid
  500.       congestion in the trunks and impact on other connections, or they
  501.       may simply be marked "discard-eligible" and forwarded into the
  502.       network, hoping for the best.
  503.  
  504.       Distinguishing between these two approaches should be relatively
  505.       simple.  In the first case, latency for the bursting session
  506.       increases, but there is no cell loss.  Other sessions are
  507.       unaffected.  In the second case, there may be cell loss across any
  508.       of the sessions, and latency may increase across all.
  509.  
  510.       Measurement units:  dropped cells, latency
  511.  
  512.       Issues:
  513.  
  514.       See also:
  515.  
  516.    3.5.2  Congestion management
  517.  
  518.       Definition:  effectiveness of measures taken by the switch to deal
  519.       with congestion.
  520.  
  521.       Discussion:  in the face of sustained traffic above committed rate
  522.       on multiple sessions, a switch has little choice but to begin
  523.       discarding cells, since buffering cannot be infinite.  This case
  524.       might arise if one were wildly profligate in over-subscribing
  525.       trunk bandwidth, or if one had neglected to analyze the network
  526.       applications to be run over the network and they were found to be
  527.       network-hostile (UDP, IPX, AT, NetBIOS, for example).
  528.  
  529.       The switch has some discretion in deciding which cells to drop.
  530.       Presumably, the strategy should involve something resembling
  531.  
  532.  
  533.  
  534. Benchmarking Methodology Working Group                          [Page 9]
  535.  
  536.  
  537.  
  538.  
  539.  
  540. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  541.  
  542.  
  543.       "fairness".
  544.  
  545.       The basic idea is that ill-behaved connections should not starve
  546.       others for resources.
  547.  
  548.       Measurement units:  latency, cell drops
  549.  
  550.       Issues:
  551.  
  552.       See also:
  553.  
  554.    3.5.3  Queueing strategies
  555.  
  556.       Definition:  the method used for queueing frames.
  557.  
  558.       Discussion:  FIFO, WFQ, SFQ, tail drop, RED.  Queue per interface,
  559.       per rate or per connection?
  560.  
  561.       Measurement units:
  562.  
  563.       Issues:
  564.  
  565.       See also:
  566.  
  567. 3.6  Inter-switch protocols
  568.  
  569.    This group applies to all switches.
  570.  
  571.    3.6.1  Impact of Routing on Forwarding
  572.  
  573.       Definition:  interaction between routing protocol and data
  574.       forwarding operations.
  575.  
  576.       Discussion:  No amount of routing fluctuation should have an
  577.       impact on data forwarding for unaffected destinations.  Similarly,
  578.       no amount of data forwarding should cause the routing to become
  579.       unstable.
  580.  
  581.       Measurement units:  route flaps per second versus cells per
  582.       second, cells per second versus route stability (table fluctuation
  583.       or peer loss).
  584.  
  585.       Issues:
  586.  
  587.       See also:
  588.  
  589.    3.6.2  Impact of Congestion Control
  590.  
  591.  
  592.  
  593.  
  594. Benchmarking Methodology Working Group                         [Page 10]
  595.  
  596.  
  597.  
  598.  
  599.  
  600. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  601.  
  602.  
  603.       Definition:  interaction between congestion control and data
  604.       forwarding operations.
  605.  
  606.       Discussion:  switches may share views of congestion in-band
  607.       through the network.  Should these feedback messages be delayed or
  608.       lost, the potential exists for an incorrect picture of current
  609.       network conditions, which may exacerbate congestion and lead to
  610.       cell loss.  Worse, it is possible to enter a stable oscillation
  611.       state, where ever-increasing waves of congestion overwhelm the
  612.       switches.
  613.  
  614.       Measurement units:
  615.  
  616.       Issues:
  617.  
  618.       See also:
  619.  
  620. 3.7  Quality of Service
  621.  
  622.    This group applies to all switches.
  623.  
  624.    3.7.1  Traffic Management
  625.  
  626.       Definition:  impact of misbehaving class on others, for example
  627.       data forwarding on voice or video frames and vice versa.
  628.  
  629.       Discussion:  we wish to quantify the potential interaction amongst
  630.       the various classes of service.  Constant bit rate (CBR), variable
  631.       bit rate (VBR) (real and non-real time?), and available bit rate
  632.       (ABR) streams are established, within their respective service
  633.       levels, but sufficient to subscribe the trunk to 90%.  The bit
  634.       rate of each is increased until it has exceeded its allocation by
  635.       a degree which should cause loss or delay in the other streams.
  636.  
  637.       Measurement units:  cells (lost) per second, latency
  638.  
  639.       Issues:  some switches perform compression and silence
  640.       suppression.  Should these features be disabled?
  641.  
  642.       See also:
  643.  
  644.    3.7.2  Mapping of IP ToS/Precedence onto QoS
  645.  
  646.       Definition:  some method is required to map IP type of service
  647.       and/or precedence values onto the switch's notion of quality of
  648.       service.
  649.  
  650.       Discussion:
  651.  
  652.  
  653.  
  654. Benchmarking Methodology Working Group                         [Page 11]
  655.  
  656.  
  657.  
  658.  
  659.  
  660. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  661.  
  662.  
  663.       Measurement units:
  664.  
  665.       Issues:
  666.  
  667.       See also:
  668.  
  669. 3.8  Multicast
  670.  
  671.    3.8.1  Cell replication
  672.  
  673.       Definition:  the device's ability to forward a cell to multiple
  674.       ports simultaneously (multicast).
  675.  
  676.       Discussion:
  677.  
  678.       Measurement units:  replication factor 1:N and cells per second
  679.       measured at ingress versus cells per second measured at the
  680.       egresses
  681.  
  682.       Issues:
  683.  
  684.       See also:
  685.  
  686.    3.8.2  Impact of multicast on unicast
  687.  
  688.       Definition:  switch's ability to insulate unicast traffic from the
  689.       effects of multicast.
  690.  
  691.       Discussion:  a poorly-designed replication scheme could easily
  692.       swamp unicast traffic.  Yet, multicast traffic often has QoS
  693.       needs.  How does one reconcile the competing requirements?
  694.  
  695.       Measurement units:  cell loss, delay
  696.  
  697.       Issues:
  698.  
  699.       See also:
  700.  
  701.  
  702. Security Considerations
  703.  
  704.    Security issues are not addressed in this memo.
  705.  
  706. Editor's Address
  707.  
  708.    Robert Craig
  709.    Cisco Systems
  710.    7025 Kit Creek Road
  711.  
  712.  
  713.  
  714. Benchmarking Methodology Working Group                         [Page 12]
  715.  
  716.  
  717.  
  718.  
  719.  
  720. INTERNET-DRAFT     Cell/Call Benchmarking Terminology           Nov 1996
  721.  
  722.  
  723.    PO Box 14987
  724.    Research Triangle Park, NC 27709
  725.    (919) 472-2886
  726.    rcraig@cisco.com
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774. Benchmarking Methodology Working Group                         [Page 13]
  775.  
  776.  
  777.  
  778.