draft-ietf-v6ops-nat64-experience-06.txt   draft-ietf-v6ops-nat64-experience-07.txt 
Internet Engineering Task Force G. Chen Internet Engineering Task Force G. Chen
Internet-Draft Z. Cao Internet-Draft Z. Cao
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: June 21, 2014 C. Xie Expires: June 26, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
December 18, 2013 December 23, 2013
NAT64 Operational Experience NAT64 Operational Experience
draft-ietf-v6ops-nat64-experience-06 draft-ietf-v6ops-nat64-experience-07
Abstract Abstract
This document summarizes NAT64 function deployment scenarios and This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document. NAT64 server Front End (NAT64-FE) are considered in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2014. This Internet-Draft will expire on June 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 12. Additional Author List . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Testing Results of Application Behavior . . . . . . 20 Appendix A. Testing Results of Application Behavior . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet IPv6 is the only sustainable solution for numbering nodes on Internet
due to the IPv4 depletion. Network operators have to deploy due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding IPv6-only networks in order to meet the needs of the expanding
internet without available IPv4 addresses. internet without available IPv4 addresses.
Single stack IPv6 network deployment can simplify network's Single stack IPv6 network deployment can simplify networks
provisioning. Some justifications have been described in 464xlat provisioning. Some justifications have been described in 464xlat
[RFC6877]. As an example, IPv6-only connectivity confers some [RFC6877]. As an example, IPv6-only connectivity confers some
benefits to mobile operators. In such mobile context, it enables the benefits to mobile operators. In such mobile context, it enables the
use of a single IPv6 Packet Data Protocol(PDP) context or Evolved use of a single IPv6 Packet Data Protocol(PDP) context or Evolved
Packet System (EPS) bearer if Long Term Evolution (LTE) network is Packet System (EPS) bearer if Long Term Evolution (LTE) network is
considered, which eliminates significant network costs caused by considered, which eliminates significant network costs caused by
doubling the number of PDP contexts in some cases and the need of doubling the number of PDP contexts in some cases and the need of
IPv4 addresses to be assigned to customers. In broadband networks IPv4 addresses to be assigned to customers. In broadband networks
overall, it can allow for the scaling of edge-network growth overall, it can allow for the scaling of edge-network growth
decoupled from IPv4 numbering limitations. decoupled from IPv4 numbering limitations.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Fixed network operators and mobile operators may locate NAT64 in Fixed network operators and mobile operators may locate NAT64 in
access networks or in mobile core networks. It can be built into access networks or in mobile core networks. It can be built into
various devices, including routers, gateways or firewalls in order to various devices, including routers, gateways or firewalls in order to
connect IPv6 users to the IPv4 Internet. With regard to the numbers connect IPv6 users to the IPv4 Internet. With regard to the numbers
of users and the shortage of public IPv4 addresses, stateful of users and the shortage of public IPv4 addresses, stateful
NAT64[RFC6146] is more adapted to perform some maximal sharing of NAT64[RFC6146] is more adapted to perform some maximal sharing of
public IPv4 addresses. The usage of stateless NAT64 can be seen with public IPv4 addresses. The usage of stateless NAT64 can be seen with
better transparency features better transparency features
[I-D.ietf-softwire-stateless-4v6-motivation], while it has to be [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be
coordinated with A+P[RFC6346] processes as specified in coordinated with A+P[RFC6346] processes as specified in
[I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope [I-D.ietf-softwire-map-t] in order to cope with IPv4 shortage.
with IPv4 shortage.
3.1.2. DNS64 Deployment 3.1.2. DNS64 Deployment
DNS64[RFC6147] is recommended for use in combination with stateful DNS64[RFC6147] is recommended for use in combination with stateful
NAT64, and will likely be an essential part of an IPv6 single-stack NAT64, and will likely be an essential part of an IPv6 single-stack
network that couples to the IPv4 Internet. 464xlat[RFC6877] is network that couples to the IPv4 Internet. 464xlat[RFC6877] is
proposed to enable access of IPv4 only applications or applications proposed to enable access of IPv4 only applications or applications
that call IPv4 literal addresses. Using DNS64 will help 464xlat to that call IPv4 literal addresses. Using DNS64 will help 464xlat to
automatically discover NAT64 prefix through [RFC7050]. Berkeley automatically discover NAT64 prefix through [RFC7050]. Berkeley
Internet Name Daemon (BIND) software supports the function. It's Internet Name Daemon (BIND) software supports the function. It's
skipping to change at page 8, line 21 skipping to change at page 8, line 21
handover time has been extremely reduced. Thanks to Bidirectional handover time has been extremely reduced. Thanks to Bidirectional
Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
of only 35ms for 30 million sessions handover was observed during of only 35ms for 30 million sessions handover was observed during
testing. In some sense, it could guarantee the session continuity testing. In some sense, it could guarantee the session continuity
for every service. In order to timely transmit session states, for every service. In order to timely transmit session states,
operators may have to deploy extra transport links between primary operators may have to deploy extra transport links between primary
NAT64 and distant backup. The scale of synchronization data NAT64 and distant backup. The scale of synchronization data
instance is depending on the particular deployment. For example, instance is depending on the particular deployment. For example,
If a NAT64-CGN is served for 200,000 users, the average amount of If a NAT64-CGN is served for 200,000 users, the average amount of
800, 000 sessions per second is roughly estimated for new created 800, 000 sessions per second is roughly estimated for new created
and expired sessions. A 10Gbps transport link should be used for and expired sessions. A physical 10Gbps transport link may have
the sync data transmission. to be deployed for the sync data transmission considering the
amount of sync sessions at the peak and capacity redundancy
In general, cold-standby and warm-standby is simpler and less In general, cold-standby and warm-standby is simpler and less
resource intensive, but it requires clients to re-establish sessions resource intensive, but it requires clients to re-establish sessions
when a fail-over occurs. Hot standby doubles resource's consumption when a fail-over occurs. Hot standby increases resource's
to synchronize the states, but it achieve seamless handover. The consumption to synchronize the states, but it achieve seamless
consideration of redundancy mode for stateless NAT64 is simple, handover. The consideration of redundancy mode for stateless NAT64
because it doesn't have to consider time consuming for states is simple, because state synchronization is unnecessary. In regards
maintenance. The warm standby is sufficient for stateless NAT64. In to stateful NAT64, it may be useful to investigate performance
regards to stateful NAT64, it may be useful to investigate tolerance of applications and the traffic characteristics in a
performance tolerance of applications and the traffic characteristics particular network. Some testing results are shown in the
in a particular network. Some testing results are shown in the
Appendix A. Appendix A.
Our statistics in a mobile network shown that almost 91.21% of amount Our statistics in a mobile network shown that almost 91.21% of amount
of traffic is accounted by browsing services. Those services don't of traffic is accounted by browsing services. Those services don't
require session continuity. The handover time of warm standby is require session continuity. The handover time of warm standby is
qualified to the delay tolerance. Hot-standby does not offer much qualified to the delay tolerance. Hot-standby does not offer much
benefit for those sessions on this point. In a fixed network, HTTP benefit for those sessions on this point. In a fixed network, HTTP
streaming, p2p and online games would be the major streaming, p2p and online games would be the major
traffic[Cisco-VNI]. Consideration should be given to the importance traffic[Cisco-VNI]. Consideration should be given to the importance
of maintaining bindings for those sessions across failover. of maintaining bindings for those sessions across failover.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
where the imposition of an ALG might be required. At the same time, where the imposition of an ALG might be required. At the same time,
it is also important to remind customers and application developers it is also important to remind customers and application developers
that IPv6 end-to-end usage does not require ALG imposition and that IPv6 end-to-end usage does not require ALG imposition and
therefore results in a better overall user experience. therefore results in a better overall user experience.
The service reachability is also subject to the IPv6 support in the The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports. The experiences of some below table to verify the IPv6 supports. The experiences of some
applications are still align with [RFC6586]. It has been found there applications are still align with [RFC6586]. It has been found there
are some software issues to support IPv6 at this time. The software are some software issues to support IPv6 at this time. The software
could benefit from 464xlat[RFC6877] to be able to access IPv6 could benefit from 464xlat[RFC6877] to be able to get IPv4
networks without requiring software upgrades. A SIP based voice call connectivity across an IPv6-only network without requiring software
has been tested in LTE mobile environment as specified in [IR.92]. upgrades. A SIP based voice call has been tested in LTE mobile
The voice call is failed due to the lack of NAT64 traversal when an environment as specified in [IR.92]. The voice call is failed due to
IPv6 SIP user agent communicates with an IPv4 SIP user agent. In the lack of NAT64 traversal when an IPv6 SIP user agent communicates
order to address the failure, Interactive Connectivity Establishment with an IPv4 SIP user agent. In order to address the failure,
(ICE) described in [RFC5245]is recommended to be supported for the Interactive Connectivity Establishment (ICE) described in [RFC5245]is
SIP IPv6 transition. [RFC6157] describes both signaling and media recommended to be supported for the SIP IPv6 transition. [RFC6157]
layer process, which should be followed. In addition, it may be describes both signaling and media layer process, which should be
worth to notice that ICE is not only useful for NAT traversal, but followed. In addition, it may be worth to notice that ICE is not
also firewall[RFC6092] traversal in native IPv6 deployment. only useful for NAT traversal, but also firewall[RFC6092] traversal
in native IPv6 deployment.
Different IPsec modes for VPN services have been tested, including Different IPsec modes for VPN services have been tested, including
IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive
since the destination host detects the IP header changes and since the destination host detects the IP header changes and
invalidate the packets. For the IPsec-ESP mode, the failure happens invalidate the packets. IPsec-ESP failed in our testing because the
because the function of NAT-Traversal in the IKE[RFC3947] is missed NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It
on the NAT64 gateway. NAT64 can't update the TCP/UDP checksum, which has been suggested that IPsec ESP should succeed if the IPSec client
is encrypted. The destination host is failed to validate the supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over
received packets. UDP[RFC3948].
Table 1: The tested applications Table 1: The tested applications
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| APPs | Results and Found Issues |. | APPs | Results and Found Issues |.
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| Webservice |Mostly pass, some failure cases due to IPv4 Literals| | Webservice |Mostly pass, some failure cases due to IPv4 Literals|
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
|Instant Message |Mostly fail, software can't support IPv6 | |Instant Message |Mostly fail, software can't support IPv6 |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| Games |Mostly pass for web-based games; mostly fail for | | Games |Mostly pass for web-based games; mostly fail for |
| |standalone games due to the lack of IPv6 support in | | |standalone games due to the lack of IPv6 support in |
| |software | | |software |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| SIP-VoIP |Fail, due to the lack of NAT64 traversal | | SIP-VoIP |Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| IPsec-VPN |Fail, the translated IPsec packets are invalidated | | IPsec-VPN |Fail, the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| P2P |Mostly fail, software can't support IPv6 | |P2P streaming, |Mostly fail, software can't support IPv6, e.g. eMule|
|file sharing |Thunder and PPS TV |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| FTP |Pass | | FTP |Pass |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| Email |Pass | | Email |Pass |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
6.2. Resource Reservation 6.2. Resource Reservation
Session status normally is managed by a static timer. For example, Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP the value of the "established connection idle-timeout" for TCP
skipping to change at page 15, line 32 skipping to change at page 15, line 37
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy
Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley,
Tim Chown and Gert Doering for their helpful comments. Tim Chown, Gert Doering and Simon Perreault for their helpful
comments.
Many thanks to Wesley George, Lee Howard and Satoru Matsushima for Many thanks to Wesley George, Lee Howard and Satoru Matsushima for
their detailed reviews. their detailed reviews.
The authors especially thank Joel Jaeggli and Ray Hunter for his The authors especially thank Joel Jaeggli and Ray Hunter for his
efforts and contributions on editing which substantially improves the efforts and contributions on editing which substantially improves the
legibility of the document. legibility of the document.
Thanks to Cameron Byrne who was an active co-author of some earlier Thanks to Cameron Byrne who was an active co-author of some earlier
versions of this draft. versions of this draft.
skipping to change at page 16, line 40 skipping to change at page 16, line 44
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
skipping to change at page 18, line 46 skipping to change at page 19, line 11
Chen, G., "Analysis of NAT64 Port Allocation Method", Chen, G., "Analysis of NAT64 Port Allocation Method",
draft-chen-sunset4-cgn-port-allocation-02 (work in draft-chen-sunset4-cgn-port-allocation-02 (work in
progress), July 2013. progress), July 2013.
[I-D.donley-behave-deterministic-cgn] [I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", draft-donley- Logging in Carrier Grade NAT Deployments", draft-donley-
behave-deterministic-cgn-06 (work in progress), July 2013. behave-deterministic-cgn-06 (work in progress), July 2013.
[I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
progress), October 2013.
[I-D.ietf-softwire-map-deployment] [I-D.ietf-softwire-map-deployment]
Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Mapping of Address and Port (MAP) - Deployment "Mapping of Address and Port (MAP) - Deployment
Considerations", draft-ietf-softwire-map-deployment-03 Considerations", draft-ietf-softwire-map-deployment-03
(work in progress), October 2013. (work in progress), October 2013.
[I-D.ietf-softwire-map-t] [I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
skipping to change at page 21, line 16 skipping to change at page 21, line 20
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| APPs | Acceptable Interrupt | Session Continuity | | APPs | Acceptable Interrupt | Session Continuity |
| | Recovery | | | | Recovery | |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s | No | | Web Browse |As maximum as 6s | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Http streaming |As maximum as 10s(cache)| Yes | |Http streaming |As maximum as 10s(cache)| Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Gaming | 200ms~400ms | Yes | | Gaming | 200ms~400ms | Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| P2P | 10~16s | Yes | |P2P streaming, | 10~16s | Yes |
|file sharing | | |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Instant Message |1 minute | Yes | |Instant Message |1 minute | Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Mail |30 seconds | No | |Mail |30 seconds | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Downloading |1 minutes | No | |Downloading |1 minutes | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
Authors' Addresses Authors' Addresses
 End of changes. 17 change blocks. 
44 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/