home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2415.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  24.2 KB  |  620 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            K. Poduri
  8. Request for Comments: 2415                                      K. Nichols
  9. Category: Informational                                       Bay Networks
  10.                                                             September 1998
  11.  
  12.  
  13.         Simulation Studies of Increased Initial TCP Window Size
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  24.  
  25. Abstract
  26.  
  27.    An increase in the permissible initial window size of a TCP
  28.    connection, from one segment to three or four segments, has been
  29.    under discussion in the tcp-impl working group. This document covers
  30.    some simulation studies of the effects of increasing the initial
  31.    window size of TCP. Both long-lived TCP connections (file transfers)
  32.    and short-lived web-browsing style connections were modeled. The
  33.    simulations were performed using the publicly available ns-2
  34.    simulator and our custom models and files are also available.
  35.  
  36. 1. Introduction
  37.  
  38.    We present results from a set of simulations with increased TCP
  39.    initial window (IW). The main objectives were to explore the
  40.    conditions under which the larger IW was a "win" and to determine the
  41.    effects, if any, the larger IW might have on other traffic flows
  42.    using an IW of one segment.
  43.  
  44.    This study was inspired by discussions at the Munich IETF tcp-impl
  45.    and tcp-sat meetings. A proposal to increase the IW size to about 4K
  46.    bytes (4380 bytes in the case of 1460 byte segments) was discussed.
  47.    Concerns about both the utility of the increase and its effect on
  48.    other traffic were raised. Some studies were presented showing the
  49.    positive effects of increased IW on individual connections, but no
  50.    studies were shown with a wide variety of simultaneous traffic flows.
  51.    It appeared that some of the questions being raised could be
  52.    addressed in an ns-2 simulation. Early results from our simulations
  53.    were previously posted to the tcp-impl mailing list and presented at
  54.    the tcp-impl WG meeting at the December 1997 IETF.
  55.  
  56.  
  57.  
  58. Poduri & Nichols             Informational                      [Page 1]
  59.  
  60. RFC 2415                    TCP Window Size               September 1998
  61.  
  62.  
  63. 2. Model and Assumptions
  64.  
  65.    We simulated a network topology with a bottleneck link as shown:
  66.  
  67.            10Mb,                                    10Mb,
  68.            (all 4 links)                          (all 4 links)
  69.  
  70.       C   n2_________                               ______ n6     S
  71.       l   n3_________\                             /______ n7     e
  72.       i              \\              1.5Mb, 50ms   //             r
  73.       e               n0 ------------------------ n1              v
  74.       n   n4__________//                          \ \_____ n8     e
  75.       t   n5__________/                            \______ n9     r
  76.       s                                                           s
  77.  
  78.                     URLs -->          <--- FTP & Web data
  79.  
  80.    File downloading and web-browsing clients are attached to the nodes
  81.    (n2-n5) on the left-hand side. These clients are served by the FTP
  82.    and Web servers attached to the nodes (n6-n9) on the right-hand side.
  83.    The links to and from those nodes are at 10 Mbps. The bottleneck link
  84.    is between n1 and n0. All links are bi-directional, but only ACKs,
  85.    SYNs, FINs, and URLs are flowing from left to right. Some simulations
  86.    were also performed with data traffic flowing from right to left
  87.    simultaneously, but it had no effect on the results.
  88.  
  89.    In the simulations we assumed that all ftps transferred 1-MB files
  90.    and that all web pages had exactly three embedded URLs. The web
  91.    clients are browsing quite aggressively, requesting a new page after
  92.    a random delay uniformly distributed between 1 and 5 seconds. This is
  93.    not meant to realistically model a single user's web-browsing
  94.    pattern, but to create a reasonably heavy traffic load whose
  95.    individual tcp connections accurately reflect real web traffic. Some
  96.    discussion of these models as used in earlier studies is available in
  97.    references [3] and [4].
  98.  
  99.    The maximum tcp window was set to 11 packets, maximum packet (or
  100.    segment) size to 1460 bytes, and buffer sizes were set at 25 packets.
  101.    (The ns-2 TCPs require setting window sizes and buffer sizes in
  102.    number of packets. In our tcp-full code some of the internal
  103.    parameters have been set to be byte-oriented, but external values
  104.    must still be set in number of packets.)  In our simulations, we
  105.    varied the number of data segments sent into a new TCP connection (or
  106.    initial window) from one to four, keeping all segments at 1460 bytes.
  107.    A dropped packet causes a restart window of one segment to be used,
  108.    just as in current practice.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Poduri & Nichols             Informational                      [Page 2]
  115.  
  116. RFC 2415                    TCP Window Size               September 1998
  117.  
  118.  
  119.    For ns-2 users: The tcp-full code was modified to use an
  120.    "application" class and three application client-server pairs were
  121.    written: a simple file transfer (ftp), a model of http1.0 style web
  122.    connection and a very rough model of http1.1 style web connection.
  123.    The required files and scripts for these simulations are available
  124.    under the contributed code section on the ns-simulator web page at
  125.    the sites ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} or http://www-
  126.    nrg.ee.lbl.gov/floyd/tcp_init_win.html.
  127.  
  128.    Simulations were run with 8, 16, 32 web clients and a number of ftp
  129.    clients ranging from 0 to 3. The IW was varied from 1 to 4, though
  130.    the 4-packet case lies beyond what is currently recommended. The
  131.    figures of merit used were goodput, the median page delay seen by the
  132.    web clients and the median file transfer delay seen by the ftp
  133.    clients. The simulated run time was rather large, 360 seconds, to
  134.    ensure an adequate sample. (Median values remained the same for
  135.    simulations with larger run times and can be considered stable)
  136.  
  137. 3. Results
  138.  
  139.    In our simulations, we varied the number of file transfer clients in
  140.    order to change the congestion of the link. Recall that our ftp
  141.    clients continuously request 1 Mbyte transfers, so the link
  142.    utilization is over 90% when even a single ftp client is present.
  143.    When three file transfer clients are running simultaneously, the
  144.    resultant congestion is somewhat pathological, making the values
  145.    recorded stable. Though all connections use the same initial window,
  146.    the effect of increasing the IW on a 1 Mbyte file transfer is not
  147.    detectable, thus we focus on the web browsing connections.  (In the
  148.    tables, we use "webs" to indicate number of web clients and "ftps" to
  149.    indicate the number of file transfer clients attached.) Table 1 shows
  150.    the median delays experienced by the web transfers with an increase
  151.    in the TCP IW.  There is clearly an improvement in transfer delays
  152.    for the web connections with increase in the IW, in many cases on the
  153.    order of 30%.  The steepness of the performance improvement going
  154.    from an IW of 1 to an IW of 2 is mainly due to the distribution of
  155.    files fetched by each URL (see references [1] and [2]); the median
  156.    size of both primary and in-line URLs fits completely into two
  157.    packets. If file distributions change, the shape of this curve may
  158.    also change.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Poduri & Nichols             Informational                      [Page 3]
  171.  
  172. RFC 2415                    TCP Window Size               September 1998
  173.  
  174.  
  175.    Table 1. Median web page delay
  176.  
  177.    #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
  178.                    (s)        (% decrease)
  179.    ----------------------------------------------
  180.      8      0      0.56    14.3  17.9   16.1
  181.      8      1      1.06    18.9  25.5   32.1
  182.      8      2      1.18    16.1  17.1   28.9
  183.      8      3      1.26    11.9  19.0   27.0
  184.     16      0      0.64    11.0  15.6   18.8
  185.     16      1      1.04    17.3  24.0   35.6
  186.     16      2      1.22    17.2  20.5   25.4
  187.     16      3      1.31    10.7  21.4   22.1
  188.     32      0      0.92    17.6  28.6   21.0
  189.     32      1      1.19    19.6  25.0   26.1
  190.     32      2      1.43    23.8  35.0   33.6
  191.     32      3      1.56    19.2  29.5   33.3
  192.  
  193.    Table 2 shows the bottleneck link utilization and packet drop
  194.    percentage of the same experiment. Packet drop rates did increase
  195.    with IW, but in all cases except that of the single most pathological
  196.    overload, the increase in drop percentage was less than 1%. A
  197.    decrease in packet drop percentage is observed in some overloaded
  198.    situations, specifically when ftp transfers consumed most of the link
  199.    bandwidth and a large number of web transfers shared the remaining
  200.    bandwidth of the link. In this case, the web transfers experience
  201.    severe packet loss and some of the IW=4 web clients suffer multiple
  202.    packet losses from the same window, resulting in longer recovery
  203.    times than when there is a single packet loss in a window. During the
  204.    recovery time, the connections are inactive which alleviates
  205.    congestion and thus results in a decrease in the packet drop
  206.    percentage. It should be noted that such observations were made only
  207.    in extremely overloaded scenarios.
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Poduri & Nichols             Informational                      [Page 4]
  227.  
  228. RFC 2415                    TCP Window Size               September 1998
  229.  
  230.  
  231. Table 2. Link utilization and packet drop rates
  232.  
  233.          Percentage Link Utilization            |      Packet drop rate
  234. #Webs   #FTPs   IW=1    IW=2    IW=3  IW=4      |IW=1  IW=2  IW=3  IW=4
  235. -----------------------------------------------------------------------
  236.   8     0        34     37      38      39      | 0.0   0.0  0.0   0.0
  237.   8     1        95     92      93      92      | 0.6   1.2  1.4   1.3
  238.   8     2        98     97      97      96      | 1.8   2.3  2.3   2.7
  239.   8     3        98     98      98      98      | 2.6   3.0  3.5   3.5
  240. -----------------------------------------------------------------------
  241.  16     0        67     69      69      67      | 0.1   0.5  0.8   1.0
  242.  16     1        96     95      93      92      | 2.1   2.6  2.9   2.9
  243.  16     2        98     98      97      96      | 3.5   3.6  4.2   4.5
  244.  16     3        99     99      98      98      | 4.5   4.7  5.2   4.9
  245. -----------------------------------------------------------------------
  246.  32     0        92     87      85      84      | 0.1   0.5  0.8   1.0
  247.  32     1        98     97      96      96      | 2.1   2.6  2.9   2.9
  248.  32     2        99     99      98      98      | 3.5   3.6  4.2   4.5
  249.  32     3       100     99      99      98      | 9.3   8.4  7.7   7.6
  250.  
  251.    To get a more complete picture of performance, we computed the
  252.    network power, goodput divided by median delay (in Mbytes/ms), and
  253.    plotted it against IW for all scenarios. (Each scenario is uniquely
  254.    identified by its number of webs and number of file transfers.) We
  255.    plot these values in Figure 1 (in the pdf version), illustrating a
  256.    general advantage to increasing IW. When a large number of web
  257.    clients is combined with ftps, particularly multiple ftps,
  258.    pathological cases result from the extreme congestion. In these
  259.    cases, there appears to be no particular trend to the results of
  260.    increasing the IW, in fact simulation results are not particularly
  261.    stable.
  262.  
  263.    To get a clearer picture of what is happening across all the tested
  264.    scenarios, we normalized the network power values for the non-
  265.    pathological scenario by the network power for that scenario at IW of
  266.    one. These results are plotted in Figure 2. As IW is increased from
  267.    one to four, network power increased by at least 15%, even in a
  268.    congested scenario dominated by bulk transfer traffic. In simulations
  269.    where web traffic has a dominant share of the available bandwidth,
  270.    the increase in network power was up to 60%.
  271.  
  272.    The increase in network power at higher initial window sizes is due
  273.    to an increase in throughput and a decrease in the delay. Since the
  274.    (slightly) increased drop rates were accompanied by better
  275.    performance, drop rate is clearly not an indicator of user level
  276.    performance.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Poduri & Nichols             Informational                      [Page 5]
  283.  
  284. RFC 2415                    TCP Window Size               September 1998
  285.  
  286.  
  287.    The gains in performance seen by the web clients need to be balanced
  288.    against the performance the file transfers are seeing. We computed
  289.    ftp network power and show this in Table 3.  It appears that the
  290.    improvement in network power seen by the web connections has
  291.    negligible effect on the concurrent file transfers. It can be
  292.    observed from the table that there is a small variation in the
  293.    network power of file transfers with an increase in the size of IW
  294.    but no particular trend can be seen. It can be concluded that the
  295.    network power of file transfers essentially remained the same.
  296.    However, it should be noted that a larger IW does allow web transfers
  297.    to gain slightly more bandwidth than with a smaller IW. This could
  298.    mean fewer bytes transferred for FTP applications or a slight
  299.    decrease in network power as computed by us.
  300.  
  301.    Table 3. Network power of file transfers with an increase in the TCP
  302.             IW size
  303.  
  304.    #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
  305.    --------------------------------------------
  306.      8      1      4.7     4.2     4.2     4.2
  307.      8      2      3.0     2.8     3.0     2.8
  308.      8      3      2.2     2.2     2.2     2.2
  309.     16      1      2.3     2.4     2.4     2.5
  310.     16      2      1.8     2.0     1.8     1.9
  311.     16      3      1.4     1.6     1.5     1.7
  312.     32      1      0.7     0.9     1.3     0.9
  313.     32      2      0.8     1.0     1.3     1.1
  314.     32      3      0.7     1.0     1.2     1.0
  315.  
  316.    The above simulations all used http1.0 style web connections, thus, a
  317.    natural question is to ask how results are affected by migration to
  318.    http1.1. A rough model of this behavior was simulated by using one
  319.    connection to send all of the information from both the primary URL
  320.    and the three embedded, or in-line, URLs. Since the transfer size is
  321.    now made up of four web files, the steep improvement in performance
  322.    between an IW of 1 and an IW of two, noted in the previous results,
  323.    has been smoothed. Results are shown in Tables 4 & 5 and Figs. 3 & 4.
  324.    Occasionally an increase in IW from 3 to 4 decreases the network
  325.    power owing to a non-increase or a slight decrease in the throughput.
  326.    TCP connections opening up with a higher window size into a very
  327.    congested network might experience some packet drops and consequently
  328.    a slight decrease in the throughput. This indicates that increase of
  329.    the initial window sizes to further higher values (>4) may not always
  330.    result in a favorable network performance. This can be seen clearly
  331.    in Figure 4 where the network power shows a decrease for the two
  332.    highly congested cases.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Poduri & Nichols             Informational                      [Page 6]
  339.  
  340. RFC 2415                    TCP Window Size               September 1998
  341.  
  342.  
  343.    Table 4. Median web page delay for http1.1
  344.  
  345.    #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
  346.                    (s)       (% decrease)
  347.    ----------------------------------------------
  348.      8      0      0.47   14.9   19.1   21.3
  349.      8      1      0.84   17.9   19.0   25.0
  350.      8      2      0.99   11.5   17.3   23.0
  351.      8      3      1.04   12.1   20.2   28.3
  352.     16      0      0.54   07.4   14.8   20.4
  353.     16      1      0.89   14.6   21.3   27.0
  354.     16      2      1.02   14.7   19.6   25.5
  355.     16      3      1.11   09.0   17.0   18.9
  356.     32      0      0.94   16.0   29.8   36.2
  357.     32      1      1.23   12.2   28.5   21.1
  358.     32      2      1.39   06.5   13.7   12.2
  359.     32      3      1.46   04.0   11.0   15.0
  360.  
  361.  
  362.    Table 5. Network power of file transfers with an increase in the
  363.             TCP IW size
  364.  
  365.    #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
  366.    --------------------------------------------
  367.      8      1      4.2     4.2     4.2     3.7
  368.      8      2      2.7     2.5     2.6     2.3
  369.      8      3      2.1     1.9     2.0     2.0
  370.     16      1      1.8     1.8     1.5     1.4
  371.     16      2      1.5     1.2     1.1     1.5
  372.     16      3      1.0     1.0     1.0     1.0
  373.     32      1      0.3     0.3     0.5     0.3
  374.     32      2      0.4     0.3     0.4     0.4
  375.     32      3      0.4     0.3     0.4     0.5
  376.  
  377.    For further insight, we returned to the http1.0 model and mixed some
  378.    web-browsing connections with IWs of one with those using IWs of
  379.    three. In this experiment, we first simulated a total of 16 web-
  380.    browsing connections, all using IW of one. Then the clients were
  381.    split into two groups of 8 each, one of which uses IW=1 and the other
  382.    used IW=3.
  383.  
  384.    We repeated the simulations for a total of 32 and 64 web-browsing
  385.    clients, splitting those into groups of 16 and 32 respectively. Table
  386.    6 shows these results.  We report the goodput (in Mbytes), the web
  387.    page delays (in milli seconds), the percent utilization of the link
  388.    and the percent of packets dropped.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Poduri & Nichols             Informational                      [Page 7]
  395.  
  396. RFC 2415                    TCP Window Size               September 1998
  397.  
  398.  
  399. Table 6. Results for half-and-half scenario
  400.  
  401. Median Page Delays and Goodput (MB)   | Link Utilization (%) & Drops (%)
  402. #Webs     IW=1    |     IW=3          |       IW=1    |    IW=3
  403.       G.put   dly |  G.put   dly      |  L.util  Drops| L.util   Drops
  404. ------------------|-------------------|---------------|---------------
  405. 16      35.5  0.64|  36.4   0.54      |   67      0.1 |   69       0.7
  406. 8/8     16.9  0.67|  18.9   0.52      |   68      0.5 |
  407. ------------------|-------------------|---------------|---------------
  408. 32      48.9  0.91|  44.7   0.68      |   92      3.5 |   85       4.3
  409. 16/16   22.8  0.94|  22.9   0.71      |   89      4.6 |
  410. ------------------|-------------------|---------------|----------------
  411. 64      51.9  1.50|  47.6   0.86      |   98     13.0 |   91       8.6
  412. 32/32   29.0  1.40|  22.0   1.20      |   98     12.0 |
  413.  
  414.    Unsurprisingly, the non-split experiments are consistent with our
  415.    earlier results, clients with IW=3 outperform clients with IW=1. The
  416.    results of running the 8/8 and 16/16 splits show that running a
  417.    mixture of IW=3 and IW=1 has no negative effect on the IW=1
  418.    conversations, while IW=3 conversations maintain their performance.
  419.    However, the 32/32 split shows that web-browsing connections with
  420.    IW=3 are adversely affected. We believe this is due to the
  421.    pathological dynamics of this extremely congested scenario. Since
  422.    embedded URLs open their connections simultaneously, very large
  423.    number of TCP connections are arriving at the bottleneck link
  424.    resulting in multiple packet losses for the IW=3 conversations. The
  425.    myriad problems of this simultaneous opening strategy is, of course,
  426.    part of the motivation for the development of http1.1.
  427.  
  428. 4. Discussion
  429.  
  430.    The indications from these results are that increasing the initial
  431.    window size to 3 packets (or 4380 bytes) helps to improve perceived
  432.    performance. Many further variations on these simulation scenarios
  433.    are possible and we've made our simulation models and scripts
  434.    available in order to facilitate others' experiments.
  435.  
  436.    We also used the RED queue management included with ns-2 to perform
  437.    some other simulation studies. We have not reported on those results
  438.    here since we don't consider the studies complete. We found that by
  439.    adding RED to the bottleneck link, we achieved similar performance
  440.    gains (with an IW of 1) to those we found with increased IWs without
  441.    RED. Others may wish to investigate this further.
  442.  
  443.    Although the simulation sets were run for a T1 link, several
  444.    scenarios with varying levels of congestion and varying number of web
  445.    and ftp clients were analyzed. It is reasonable to expect that the
  446.    results would scale for links with higher bandwidth. However,
  447.  
  448.  
  449.  
  450. Poduri & Nichols             Informational                      [Page 8]
  451.  
  452. RFC 2415                    TCP Window Size               September 1998
  453.  
  454.  
  455.    interested readers could investigate this aspect further.
  456.  
  457.    We also used the RED queue management included with ns-2 to perform
  458.    some other simulation studies. We have not reported on those results
  459.    here since we don't consider the studies complete. We found that by
  460.    adding RED to the bottleneck link, we achieved similar performance
  461.    gains (with an IW of 1) to those we found with increased IWs without
  462.    RED. Others may wish to investigate this further.
  463.  
  464. 5. References
  465.  
  466.    [1] B. Mah, "An Empirical Model of HTTP Network Traffic", Proceedings
  467.        of INFOCOM '97, Kobe, Japan, April 7-11, 1997.
  468.  
  469.    [2] C.R. Cunha, A. Bestavros, M.E. Crovella, "Characteristics of WWW
  470.        Client-based Traces", Boston University Computer Science
  471.        Technical Report BU-CS-95-010, July 18, 1995.
  472.  
  473.    [3] K.M. Nichols and M. Laubach, "Tiers of Service for Data Access in
  474.        a HFC Architecture", Proceedings of SCTE Convergence Conference,
  475.        January, 1997.
  476.  
  477.    [4] K.M. Nichols, "Improving Network Simulation with Feedback",
  478.        available from knichols@baynetworks.com
  479.  
  480. 6. Acknowledgements
  481.  
  482.    This work benefited from discussions with and comments from Van
  483.    Jacobson.
  484.  
  485. 7. Security Considerations
  486.  
  487.    This document discusses a simulation study of the effects of a
  488.    proposed change to TCP. Consequently, there are no security
  489.    considerations directly related to the document. There are also no
  490.    known security considerations associated with the proposed change.
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Poduri & Nichols             Informational                      [Page 9]
  507.  
  508. RFC 2415                    TCP Window Size               September 1998
  509.  
  510.  
  511. 8. Authors' Addresses
  512.  
  513.    Kedarnath Poduri
  514.    Bay Networks
  515.    4401 Great America Parkway
  516.    SC01-04
  517.    Santa Clara, CA 95052-8185
  518.  
  519.    Phone: +1-408-495-2463
  520.    Fax:   +1-408-495-1299
  521.    EMail: kpoduri@Baynetworks.com
  522.  
  523.  
  524.    Kathleen Nichols
  525.    Bay Networks
  526.    4401 Great America Parkway
  527.    SC01-04
  528.    Santa Clara, CA 95052-8185
  529.  
  530.    EMail: knichols@baynetworks.com
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Poduri & Nichols             Informational                     [Page 10]
  563.  
  564. RFC 2415                    TCP Window Size               September 1998
  565.  
  566.  
  567. Full Copyright Statement
  568.  
  569.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  570.  
  571.    This document and translations of it may be copied and furnished to
  572.    others, and derivative works that comment on or otherwise explain it
  573.    or assist in its implementation may be prepared, copied, published
  574.    and distributed, in whole or in part, without restriction of any
  575.    kind, provided that the above copyright notice and this paragraph are
  576.    included on all such copies and derivative works.  However, this
  577.    document itself may not be modified in any way, such as by removing
  578.    the copyright notice or references to the Internet Society or other
  579.    Internet organizations, except as needed for the purpose of
  580.    developing Internet standards in which case the procedures for
  581.    copyrights defined in the Internet Standards process must be
  582.    followed, or as required to translate it into languages other than
  583.    English.
  584.  
  585.    The limited permissions granted above are perpetual and will not be
  586.    revoked by the Internet Society or its successors or assigns.
  587.  
  588.    This document and the information contained herein is provided on an
  589.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  590.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  591.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  592.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  593.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Poduri & Nichols             Informational                     [Page 11]
  619.  
  620.