rfc2682.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


   The distribution appears bi-modal with two big masses at 40 bytes
   (about a third) due to TCP acknowledgment packets, and 552 bytes
   (about 22 percent) due to Maximum Transmission Unit (MTU) limitations
   in many routers. Other prominent packet sizes include 72 bytes (about
   4.1 percent), 576 bytes (about 3.6 percent), 44 bytes (about 3
   percent), 185 bytes (about 2.7 percent), and 1500 bytes (about 1.5
   percent) due to Ethernet MTU. The mean packet size is  257 bytes, and
   the variance is 84,287 bytes^2. Thus, the SCV for the Internet packet
   size is about 1.1.

   To convert the IP packet size in bytes to ATM cells, we assume AAL 5
   using null encapsulation where the additional overhead in AAL 5 is 8
   bytes long [7].  Using the null encapsulation technique, the average
   packet size is about 6.2 ATM cells.

   We examine the buffer overflow probability against the buffer size
   using the Internet packet size distribution. The OFF period is
   assumed to have a geometric distribution.  Again, we find that the
   same behavior as before, except that the buffer requirement drops
   with Internet packets due to smaller average packet size.

3.6 Effect of Correlated Interarrival Times on Additional Buffer
    Requirement

   To model correlated interarrival times, we use the DAR(p) process
   (discrete autoregressive process of order p) [8], which has been used
   to accurately model video traffic (Star Wars movie) in [9].  The
   DAR(p) process is a p-th order (lag-p) discrete-time Markov chain.
   The state of the process at time n depends explicitly on the states
   at times (n-1), ...,  (n-p).

   We examine the overflow probability for the case where the
   interarrival time between packets is geometric and independent, and
   the case where the interarrival time is geometric and correlated to
   the previous one with coefficient of correlation equal to 0.9. The
   empirical distribution of the Internet packet size from the last
   section is used. The utilization is fixed to 0.5 in each case.
   Although, the overflow probability increases as p increases, the
   additional amount of buffering actually decreases for VC merging as
   p, or equivalently the correlation, increases.  One can easily
   conclude that higher-order correlation or long-range dependence,
   which occurs in self-similar traffic, will result in similar
   qualitative performance.








Widjaja & Elwalid            Informational                      [Page 7]

RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


3.7 Slow Sources

   The discussions up to now have assumed that cells within a packet
   arrive back-to-back. When traffic shaping is implemented, adjacent
   cells within the same packet would typically be spaced by idle slots.
   We call such sources as "slow sources".  Adjacent cells within the
   same packet may also be perturbed and spaced as these cells travel
   downstream due to the merging and splitting of cells at preceding
   nodes.

   Here, we assume that each source transmits at the rate of r_s (0 <
   r_s < 1), in units of link speed, to the ATM switch.  To capture the
   merging and splitting of cells as they travel in the network, we will
   also assume that the cell interarrival time within a packet is ran-
   domly perturbed.  To model this perturbation, we stretch the original
   ON period by 1/r_s, and  flip a Bernoulli coin with parameter r_s
   during the stretched ON period. In other words, a slot would contain
   a cell with probability r_s, and would be idle with probability 1-r_s
   during the ON period. By doing so, the average packet size remains
   the same as r_s is varied.  We simulated slow sources on the VC-merge
   ATM switch using the Internet packet size distribution with r_s=1 and
   r_s=0.2.  The packet interarrival time is assumed to be geometrically
   distributed.  Reducing the source rate in general reduces the
   stresses on the ATM switches since the traffic becomes smoother.
   With VC merging, slow sources also have the effect of increasing the
   reassembly time. At utilization of 0.5, the reassembly time is more
   dominant and causes the slow source (with r_s=0.2) to require more
   buffering than the fast source (with r_s=1).  At utilization of 0.8,
   the smoother traffic is more dominant and causes the slow source
   (with r_s=0.2) to require less buffering than the fast source (with
   r_s=1).  This result again has practical consequences in ATM switch
   design where buffer dimensioning is performed at reasonably high
   utilization. In this situation, slow sources only help.

3.8 Packet Delay

   It is of interest to see the impact of cell reassembly on packet
   delay. Here we consider the delay at one node only; end-to-end delays
   are subject of ongoing work.  We define the delay of a packet as the
   time between the arrival of the first cell of a packet at the switch
   and the departure of the last cell of the same packet.  We study the
   average packet delay as a function of utilization for both VC-merging
   and non-VC merging switches for the case r_s=1 (back-to-back cells in
   a packet).  Again, the Internet packet size distribution is used to
   adopt the more realistic scenario. The interarrival time of packets
   is geometrically distributed.  Although the difference in the worst-
   case delay between VC-merging and non-VC merging can be theoretically
   very large, we consistently observe that the difference in average



Widjaja & Elwalid            Informational                      [Page 8]

RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


   delays of the two systems to be consistently about one average packet
   time for a wide range of utilization. The difference is due to the
   average time needed to reassemble a packet.

   To see the effect of cell spacing in a packet, we again simulate the
   average packet delay for r_s=0.2. We observe that the difference in
   average delays of VC merging and non-VC merging increases to a few
   packet times (approximately 20 cells at high utilization).  It should
   be noted that when a VC-merge capable ATM switch reassembles packets,
   in effect it performs the task that the receiver has to do otherwise.
   From practical point-of-view, an increase in 20 cells translates to
   about 60 micro seconds at OC-3 link speed.  This additional delay
   should be insignificant for most applications.

4.0 Security Considerations

   There are no security considerations directly related to this
   document since the document is concerned with the performance
   implications of VC merging. There are also no known security
   considerations as a result of the proposed modification of a legacy
   ATM LSR to incorporate VC merging.

5.0 Discussion

   This document has investigated the impacts of VC merging on the
   performance of an ATM LSR.  We experimented with various traffic
   processes to understand the detailed behavior of VC-merge capable ATM
   LSRs.  Our main finding indicates that VC merging incurs a minimal
   overhead compared to non-VC merging in terms of additional buffering.
   Moreover, the overhead decreases as utilization increases, or as the
   traffic becomes more bursty.  This fact has important practical
   consequences since switches are dimensioned for high utilization and
   stressful traffic conditions.  We have considered the case where the
   output buffer uses a FIFO scheduling. However, based on our
   investigation on slow sources, we believe that fair queueing will not
   introduce a significant impact on the additional amount of buffering.
   Others may wish to investigate this further.

6.0 Acknowledgement

   The authors thank Debasis Mitra for his penetrating questions during
   the internal talks and discussions.









Widjaja & Elwalid            Informational                      [Page 9]

RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


7.0 References

   [1] P. Newman, Tom Lyon and G. Minshall, "Flow Labelled IP:
       Connectionless ATM Under IP", in Proceedings of INFOCOM'96, San-
       Francisco, April 1996.

   [2] Rekhter,Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, "Cisco
       Systems' Tag Switching Architecture Overview", RFC 2105, February
       1997.

   [3] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router
       Architecture Extensions for ATM: Overview", RFC 2098, February
       1997.

   [4] A. Viswanathan, N. Feldman, R. Boivie and R. Woundy, "ARIS:
       Aggregate Route-Based IP Switching", Work in Progress.

   [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow and A.
       Viswanathan, "A Framework for Multiprotocol Label Switching",
       Work in Progress.

   [6] WAN Packet Size Distribution,
       http://www.nlanr.net/NA/Learn/packetsizes.html.

   [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5", RFC 1483, July 1993.

   [8] P. Jacobs and P. Lewis, "Discrete Time Series Generated by
       Mixtures III:  Autoregressive Processes (DAR(p))", Technical
       Report NPS55-78-022, Naval Postgraduate School, 1978.

   [9] B.K. Ryu and A. Elwalid, "The Importance of Long-Range Dependence
       of VBR Video Traffic in ATM Traffic Engineering", ACM SigComm'96,
       Stanford, CA, pp. 3-14, August 1996.

















Widjaja & Elwalid            Informational                     [Page 10]

RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


Authors' Addresses

   Indra Widjaja
   Fujitsu Network Communications
   Two Blue Hill Plaza
   Pearl River, NY 10965, USA

   Phone: [phone]
   EMail: [e-mail]

   Anwar Elwalid
   Bell Labs, Lucent Technologies
   600 Mountain Ave, Rm 2C-324
   Murray Hill, NJ 07974, USA

   Phone: [phone]
   EMail: [e-mail]


































Widjaja & Elwalid            Informational                     [Page 11]

RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999


9.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Widjaja & Elwalid            Informational                     [Page 12]