rfc2884.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   observe that the number of transactions per second increases from 0.8
   to 2.2 which corresponds to an increase in relative gain for ECN of
   20% to 140%.

   3) As the transactional data size increases, ECN's advantage
   diminishes because the probability of recovering from a Fast
   Retransmit increases for NON ECN. ECN, therefore, has a huge
   advantage as the transactional data size gets smaller as is observed
   in the results.  This can be explained by looking at TCP recovery
   mechanisms.  NON ECN in the short flows depends, for recovery, on
   congestion signaling via receiving 3 duplicate ACKs, or worse by a
   retransmit timer expiration, whereas ECN depends mostly on the TCP-
   ECE flag. This is by design in our experimental setup.  [3] shows
   that most of the TCP loss recovery in fact happens in timeouts for
   short flows. The effectiveness of the Fast Retransmit/Recovery
   algorithm is limited by the fact that there might not be enough data
   in the pipe to elicit 3 duplicate ACKs.  TCP RENO needs at least 4
   outstanding packets to recover from losses without going into a
   timeout. For 5KB (4 packets for MTU of 1500Bytes) a NON ECN flow will
   always have to wait for a retransmit timeout if any of its packets
   are lost. ( This timeout could only have been avoided if the flow had
   used an initial window of four packets, and the first of the four
   packets was the packet dropped).  We repeated these experiments with
   the kernels implementing SACK/FACK and New Reno algorithms. Our
   observation was that there was hardly any difference with what we saw
   with Reno. For example in the case of SACK-ECN enabling: maintaining
   the maximum drop probability to 0.1 and increasing the congestion
   level for the 5KB transaction we noticed that the relative gain for
   the ECN enabled flows increases from 47-80%.  If we maintain the
   congestion level for the 5KB transactions and increase the maximum
   drop probabilities instead, we notice that SACKs performance
   increases from 15%-120%.  It is fair to comment that the difference
   in the testbeds (different machines, same topology) might have
   contributed to the results; however, it is worth noting that the
   relative advantage of the SACK-ECN is obvious.

6. Conclusion

   ECN enhancements improve on both bulk and transactional TCP traffic.
   The improvement is more obvious in short transactional type of flows
   (popularly referred to as mice).

   * Because less retransmits happen with ECN, it means less traffic on
   the network. Although the relative amount of data retransmitted in
   our case is small, the effect could be higher when there are more
   contributing end systems. The absence of retransmits also implies an
   improvement in the goodput. This becomes very important for scenarios




Salim & Ahmed                Informational                     [Page 13]

RFC 2884                   ECN in IP Networks                  July 2000


   where bandwidth is expensive such as in low bandwidth links.  This
   implies also that ECN lends itself well to applications that require
   reliability but would prefer to avoid unnecessary retransmissions.

   * The fact that ECN avoids timeouts by getting faster notification
   (as opposed to traditional packet dropping inference from 3 duplicate
   ACKs or, even worse, timeouts) implies less time is spent during
   error recovery - this also improves goodput.

   * ECN could be used to help in service differentiation where the end
   user is able to "probe" for their target rate faster. Assured
   forwarding [1] in the diffserv working group at the IETF proposes
   using RED with varying drop probabilities as a service
   differentiation mechanism.  It is possible that multiple packets
   within a single window in TCP RENO could be dropped even in the
   presence of RED, likely leading into timeouts [23]. ECN end systems
   ignore multiple notifications, which help in countering this scenario
   resulting in improved goodput. The ECN end system also ends up
   probing the network faster (to reach an optimal bandwidth). [23] also
   notes that RENO is the most widely deployed TCP implementation today.

   It is clear that the advent of policy management schemes introduces
   new requirements for transactional type of applications, which
   constitute a very short query and a response in the order of a few
   packets. ECN provides advantages to transactional traffic as we have
   shown in the experiments.

7. Acknowledgements

   We would like to thank Alan Chapman, Ioannis Lambadaris, Thomas Kunz,
   Biswajit Nandy, Nabil Seddigh, Sally Floyd, and Rupinder Makkar for
   their helpful feedback and valuable suggestions.

8. Security Considerations

   Security considerations are as discussed in section 9 of RFC 2481.

9. References

   [1]  Heinanen, J., Finland, T., Baker, F., Weiss, W. and J.
        Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [2]  B.A. Mat. "An empirical model of HTTP network traffic."  In
        proceedings INFOCOMM'97.







Salim & Ahmed                Informational                     [Page 14]

RFC 2884                   ECN in IP Networks                  July 2000


   [3]  Balakrishnan H., Padmanabhan V., Seshan S., Stemn M. and Randy
        H. Katz, "TCP Behavior of a busy Internet Server: Analysis and
        Improvements", Proceedings of IEEE Infocom, San Francisco, CA,
        USA, March '98
        http://nms.lcs.mit.edu/~hari/papers/infocom98.ps.gz

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

   [5]  W. Feng, D. Kandlur, D. Saha, K. Shin, "Techniques for
        Eliminating Packet Loss in Congested TCP/IP Networks", U.
        Michigan CSE-TR-349-97, November 1997.

   [6]  S. Floyd. "TCP and Explicit Congestion Notification." ACM
        Computer Communications Review, 24, October 1994.

   [7]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
        Congestion Notification (ECN) to IP", RFC 2481, January 1999.

   [8]  Kevin Fall, Sally Floyd, "Comparisons of Tahoe, RENO and Sack
        TCP", Computer  Communications Review, V. 26 N. 3, July 1996,
        pp. 5-21

   [9]  S. Floyd and V. Jacobson. "Random Early Detection Gateways for
        Congestion Avoidance". IEEE/ACM Transactions on Networking,
        3(1), August 1993.

   [10] E. Hashem. "Analysis of random drop for gateway congestion
        control." Rep. Lcs tr-465, Lav. Fot Comput. Sci., M.I.T., 1989.

   [11] V. Jacobson. "Congestion Avoidance and Control." In Proceedings
        of SIGCOMM '88, Stanford, CA, August 1988.

   [12] Raj Jain, "The art of computer systems performance analysis",
        John Wiley and sons QA76.9.E94J32, 1991.

   [13] T. V. Lakshman, Arnie Neidhardt, Teunis Ott, "The Drop From
        Front Strategy in TCP Over ATM and Its Interworking with Other
        Control Features", Infocom 96, MA28.1.

   [14] P. Mishra and H. Kanakia. "A hop by hop rate based congestion
        control scheme." Proc. SIGCOMM '92, pp. 112-123, August 1992.

   [15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
        Fast Recovery Algorithm", RFC 2582, April 1999.





Salim & Ahmed                Informational                     [Page 15]

RFC 2884                   ECN in IP Networks                  July 2000


   [16] The NIST Network Emulation Tool
        http://www.antd.nist.gov/itg/nistnet/

   [17] The network performance tool
        http://www.netperf.org/netperf/NetperfPage.html

   [18] ftp://ftp.ee.lbl.gov/ECN/ECN-package.tgz

   [19] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
        Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
        C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
        and L. Zhang, "Recommendations on Queue Management and
        Congestion Avoidance in the Internet", RFC 2309, April 1998.

   [20] K. K. Ramakrishnan and R. Jain. "A Binary feedback scheme for
        congestion avoidance in computer networks." ACM Trans. Comput.
        Syst.,8(2):158-181, 1990.

   [21] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
        Selective Acknowledgement Options", RFC 2018, October 1996.

   [22] S. Floyd and V. Jacobson, "Link sharing and Resource Management
        Models for packet  Networks", IEEE/ACM Transactions on
        Networking, Vol. 3 No.4, August 1995.

   [23] Prasad Bagal, Shivkumar Kalyanaraman, Bob Packer, "Comparative
        study of RED, ECN and TCP Rate Control".
        http://www.packeteer.com/technology/Pdf/packeteer-final.pdf

   [24] tcpdump, the protocol packet capture & dumper program.
        ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

   [25] TCP dump file analysis tool:
        http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html

   [26] Thompson K., Miller, G.J., Wilder R., "Wide-Area Internet
        Traffic Patterns and Characteristics". IEEE Networks Magazine,
        November/December 1997.

   [27] http://www7.nortel.com:8080/CTL/ecnperf.pdf











Salim & Ahmed                Informational                     [Page 16]

RFC 2884                   ECN in IP Networks                  July 2000


10. Authors' Addresses

   Jamal Hadi Salim
   Nortel Networks
   3500 Carling Ave
   Ottawa, ON, K2H 8E9
   Canada

   EMail: [e-mail]


   Uvaiz Ahmed
   Dept. of Systems and Computer Engineering
   Carleton University
   Ottawa
   Canada

   EMail: [e-mail]

































Salim & Ahmed                Informational                     [Page 17]

RFC 2884                   ECN in IP Networks                  July 2000


11. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Salim & Ahmed                Informational                     [Page 18]