One document matched: draft-donley-nat444-impacts-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.shirasaki-nat444 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-02.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nishitani-cgn-05.xml">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-intarea-shared-addressing-issues-02.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-donley-nat444-impacts-03"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="NAT444 impacts">Assessing the Impact of Carrier-Grade NAT
on Network Applications</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Chris Donley" initials="C.D." surname="Donley">
<organization>CableLabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>c.donley@cablelabs.com</email>
</address>
</author>
<author fullname="Lee Howard" initials="L.H." surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13241 Woodland Park Rd</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>USA</country>
</postal>
<email>william.howard@twcable.com</email>
</address>
</author>
<author fullname="Victor Kuarsingh" initials="V.K." surname="Kuarsingh">
<organization>Rogers Communications</organization>
<address>
<postal>
<street>8200 Dixie Road</street>
<city>Brampton</city>
<region>ON</region>
<code>L6T 0C1</code>
<country>Canada</country>
</postal>
<email>victor.kuarsingh@rci.rogers.com</email>
</address>
</author>
<author fullname="John Berg" initials="J.B." surname="Berg">
<organization>CableLabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>j.berg@cablelabs.com</email>
</address>
</author>
<author fullname="Jinesh Doshi" initials="J.D." surname="Doshi">
<organization>University of Colorado</organization>
<address>
<email>jinesh.doshi@colorado.edu</email>
</address>
</author>
<date day="15" month="November" year="2011" />
<abstract>
<t>NAT444 is an IPv4 extension technology being considered by Service
Providers to continue offering IPv4 service to customers while
transitioning to IPv6. This technology adds an extra Carrier-Grade NAT
("CGN") in the Service Provider network, often resulting in two NATs.
CableLabs, Time Warner Cable, and Rogers Communications independently
tested the impacts of NAT444 on many popular Internet services using a
variety of test scenarios, network topologies, and vendor equipment.
This document identifies areas where adding a second layer of NAT
disrupts the communication channel for common Internet applications.
This document was updated to also include Dual-Stack Lite impacts.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IANA and APNIC exhausted their IPv4 address space in 2011. Current
projections suggest that RIPE and ARIN may exhaust their free pools of
IPv4 addresses in 2012. IPv6 is the solution to the IPv4 depletion
problem; however, the transition to IPv6 will not be completed prior to
IPv4 exhaustion. NAT444 <xref target="I-D.shirasaki-nat444"></xref> and
Dual-Stack Lite (<xref target="RFC6333"></xref>) are transition
mechanisms that will allow Service Providers to multiplex customers
behind a single IPv4 address, which will allow many legacy devices and
applications some IPv4 connectivity. While both NAT444 and Dual-Stack
Lite do provide basic IPv4 connectivity, they impact a number of
advanced applications. This document describes suboptimal behaviors of
NAT444 and DS-Lite in our test environments.</t>
<t>In July-August 2010, CableLabs, Time Warner Cable, and Rogers
Communications tested the impact of NAT444 on common applications using
Carrier Grade NAT (CGN) devices. This testing was focused on a wide
array of real time usage scenarios designed to evaluate the user
experience over the public Internet using NAT444, in both single ISP and
dual ISP environments. The purpose of this testing was to identify
applications where the technology either breaks or significantly impacts
the user experience. The outcome of the testing revealed that
applications such as video streaming, video gaming and peer-to-peer file
sharing are impacted by NAT444.</t>
<t>From June – October 2011, CableLabs conducted additional
testing of CGN technologies, including both NAT444 and Dual-Stack Lite.
The testing focused on working with several vendors including A10,
Alcatel-Lucent, and Juniper to optimize the performance of those
applications that experienced negative impacts during earlier CGN
testing and to expand the testing to DS-Lite.</t>
<t>Applications that were tested included but were not necessarily
limited to the following:</t>
<t><list style="numbers">
<t>Video/Audio streaming, e.g. Silverlight-based applications,
Netflix, YouTube, Pandora 2.</t>
<t>Peer-to-peer applications, e.g. video gaming, uTorrent</t>
<t>On line gaming, e.g. Xbox</t>
<t>Large file transfers using File Transfer Protocol (FTP)</t>
<t>Session Initiation Protocol (SIP) calls via X-Lite, Skype</t>
<t>Social Networking, e.g. Facebook, Webkinz</t>
<t>Video chat, e.g. Skype</t>
<t>Web conferencing</t>
</list></t>
</section>
<section title="Testing Scope">
<t></t>
<section anchor="TestCases" title="Test Cases">
<t>The diagrams below depict the general network architecture used for
testing NAT444 and Dual Stack-Lite co-existence technologies at
CableLabs.</t>
<section title="Case1: Single Client, Single Home Network, Single Service Provider">
<figure>
<artwork><![CDATA[
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| CGN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
+---------------+
| CM |
+---------------+
|
+-------------------------+
| Home Router |
+-------------------------+
|
+---------------+
| Client |
+---------------+
]]></artwork>
</figure>
<t>This is a typical case for a client accessing content on the
Internet. For this case, we focused on basic web browsing, voice and
video chat, instant messaging, video streaming (using YouTube,
Google Videos , etc.), Torrent leeching and seeding, FTP, and
gaming.</t>
</section>
<section title="Case2: Two Clients, Single Home Network, Single Service Provider">
<figure>
<artwork><![CDATA[
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| CGN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
+---------------+
| CM |
+---------------+
|
+-------------------------+
| Home Router |
+-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
]]></artwork>
</figure>
<t>This is similar to Case 1, except that two clients are behind the
same LSN and in the same home network. This test case was conducted
to observe any change in speed in basic web browsing and video
streaming.</t>
</section>
<section title="Case3: Two Clients, Two Home Networks, Single Service Provider">
<figure>
<artwork><![CDATA[
^^^^^^^^
(Internet)
vvvvvvvv
|
|
+---------------+
| CGN |
+---------------+
|
+---------------+
| CMTS |
+---------------+
|
----------------------------------------
| |
+---------------+ +---------------+
| CM | | CM |
+---------------+ +---------------+
| |
+-------------------------+ +-------------------------+
| Home Router | | Home Router |
+-------------------------+ +-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
]]></artwork>
</figure>
<t>In this scenario, the two clients are under the same LSN but
behind two different gateways. This simulates connectivity between
two residential subscribers on the same ISP. We tested peer-to-peer
applications.</t>
</section>
<section title="Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP">
<figure>
<artwork><![CDATA[
^^^^^^^^ ^^^^^^^^
( ISP A ) ( ISP B )
Vvvvvvvv vvvvvvvv
| |
+---------------+ +---------------+
| LSN | | LSN |
+---------------+ +---------------+
| |
+---------------+ +---------------+
| CMTS | | CMTS |
+---------------+ +---------------+
| |
+---------------+ +---------------+
| CM | | CM |
+---------------+ +---------------+
| |
+-------------------------+ +-------------------------+
| Home Router | | Home Router |
+-------------------------+ +-------------------------+
| |
+---------------+ +---------------+
| Client | | Client |
+---------------+ +---------------+
]]></artwork>
</figure>
<t>This test case is similar to Case 1 but with the addition of
another identical ISP. This topology allows us to test traffic
between two residential customers connected across the Internet. We
focused on client-to-client applications such as IM and
peer-to-peer.</t>
</section>
</section>
<section title="General Test Environment">
<t>The lab environment was intended to emulate multiple service
provider networks with a CGN deployed, and with connectivity to the
public IPv4 or IPv6 internet (as dictated by the co-existence
technology under test). This was accomplished by configuring a CGN
behind multiple CMTSes and setting up multiple home networks for each
ISP. Testing involved sending traffic to and from the public internet
in both single and dual ISP environments, using both single and
multiple home networks. The following equipment was used for
testing:</t>
<t><list style="symbols">
<t>CGN</t>
<t>CMTS</t>
<t>IP sniffer</t>
<t>RF sniffer</t>
<t>Metrics tools (for network performance)</t>
<t>CPE gateway devices</t>
<t>Laptop or desktop computers (multiple OS used)</t>
<t>Gaming consoles</t>
<t>iPad or tablet devices</t>
<t>other CE equipment, e.g. BluRay players supporting
miscellaneous applications</t>
</list></t>
<t>One or more CPE gateway devices were configured in the home
network. One or more host devices behind the gateways were also
configured in order to test conditions such as multiple users on
multiple home networks in the CGN architecture, both in single and
dual ISP environments.</t>
<t>The scope of testing was honed down to the specific types of
applications and network conditions that demonstrated a high
probability of diminishing user experience based on prior testing. The
following use cases were tested:</t>
<t><list style="numbers">
<t>Video streaming over Netflix</t>
<t>Video streaming over YouTube</t>
<t>Video streaming over Joost</t>
<t>On line gaming with Xbox (one user)</t>
<t>Peer to Peer gaming with Xbox (two users)</t>
<t>Bit Torrent/uTorrent file seeding/leeching</t>
<t>Pandora internet radio</t>
<t>FTP server</t>
<t>Web conferencing (GTM, WebEx)</t>
<t>Social Networking – Facebook, Webkinz (chat, YouTube,
file transfer)</t>
<t>Internet Archive – Video and Audio streaming; large file
downloads</t>
<t>Video streaming using iClips</t>
<t>SIP Calls – X-Lite, Skype, PJSIP</t>
<t>MS Smooth Streaming (Silverlight)</t>
<t>Video chat – Skype, OoVoo</t>
</list></t>
<t>The following CPE devices were used for testing these applications
on one or more home networks:</t>
<t><list style="numbers">
<t>Windows 7, XP and Vista based laptops</t>
<t>MAC OS X laptop</t>
<t>iPad</t>
<t>Xbox gaming consoles</t>
<t>iPhone and Android smartphones</t>
<t>LG Blu-Ray player (test applications such as Netflix, Vudu,
etc.)</t>
<t>Home routers – Netgear, Linksys, D-Link, Cisco, Apple</t>
</list></t>
</section>
<section title="Test Metrics">
<t>Metrics data that were collected during the course of testing were
related to throughput, latency, and jitter. These metrics were
evaluated under three conditions:</t>
<t><list style="numbers">
<t>Initial finding on the CGN configuration used for testing</t>
<t>Retest of the same test scenario with the CGN removed from the
network</t>
<t>Retest with a new configuration (optimized) on the CGN (when
possible)</t>
</list></t>
<t>In our testing, we found no significant differences with respect to
latency or jitter when the CGN was in the network versus when it was
not present in the network. It should be noted that we did not conduct
any performance testing and metrics gathered were limited to single
session scenarios. Also, bandwidth was not restricted on the DOCSIS
network. Simulated homes shared a single DOCSIS upstream and
downstream channel.</t>
<t>Note: Performance testing as defined by CableLabs includes load
testing, induction of impairments on the network, etc. This type of
testing was out of scope for CGN testing.</t>
</section>
<section title="Test Scenarios Executed">
<t>The following test scenarios were executed using the aforementioned
applications and test equipment:</t>
<t><list style="numbers">
<t>Single ISP, Single Home Network with Single User</t>
<t>Single ISP, Two Home Networks With One User on Each Network</t>
<t>Dual ISPs, Single Home Network with Single User on each ISP</t>
<t>Dual ISPs, One Home Network With One User ISP-A; Two Home
Networks with one user on each for ISP-B</t>
</list></t>
<t>These test scenarios were executed for both NAT444 and DS-Lite
technologies.</t>
</section>
<section title="General Test Methodologies">
<t>The CGN was configured for optimal setting for the specific test
being executed for NAT444 or DS-Lite. Individual vendors provided
validation of the configuration used for the co-existence technology
under test prior to the start of testing. Some NAT444 testing used
private <xref target="RFC1918"></xref> IPv4 space between the CGN and
CPE router; other tests used public (non-<xref
target="RFC1918"></xref>) IPv4 space between the CGN and CPE router.
With the exception of 6to4 (<xref target="RFC3056"></xref>) traffic,
we observed no difference in test results whether private or public
address space was used. 6to4 failed when public space was used between
the CGN and CPE router was public, but CPE routers did not initiate
6to4 when private space was used.</t>
<t>CPE gateways and client devices were configured with IPv4 or IPv6
addresses using DHCP or manual configuration as required by each of
the devices used in the test.</t>
<t>All devices were brought to operational state. Connectivity of CPE
devices to provider network and public Internet were verified prior to
start of each test.</t>
<t>IP sniffers and metrics tools were configured as required before
starting tests. IP capture and metrics data was collected for all
failed test scenarios. Sniffing was configured behind the home
routers, north and south of the CMTS, and north and south of the
CGN.</t>
<t>The test technician executed test scenarios listed above, for
single and dual ISP environments, testing multiple users on multiple
home networks, using the applications described above, where
applicable to the each specific test scenario. Results checklists were
compiled for all tests executed and for each combination of devices
tested.</t>
</section>
</section>
<section title="Observed CGN Impacts">
<t>CGN testing revealed that basic services such as e-mail and web
browsing worked normally and as expected. However, there were some
service affecting issues noted for applications that fall into two
categories; dropped service and degraded service. In addition, for some
specific applications in which the performance was degraded, throughput,
latency and jitter measurements were taken. We observed that performance
often differs from vendor to vendor and from test environment to test
environment, and the results are somewhat difficult to predict. So as to
not become a comparison between different vendor implementations, these
results are presented in summary form. When issues were identified, we
worked with the vendors involved to confirm the specific issues and
explore workarounds. Except where noted, impacts to NAT444 and DS-Lite
were similar.</t>
<t>In 2010 testing, we identified that IPv6 transition technologies such
as 6to4 <xref target="RFC3056"></xref> and Teredo <xref
target="RFC4380"></xref>) fail outright or are subject to severe service
degradation. We did not repeat transition technology testing in
2011.</t>
<section title="Dropped Services">
<t>Several peer-to-peer applications failed in both the NAT444 and
Dual-Stack Lite environments. Specifically, peer-to-peer gaming using
Xbox, and peer-to-peer SIP calls using the PJSIP client did not
succeed. Many CGN devices use "full cone" NAT so that once the CGN
maps a port for outbound services, it will accept incoming connections
to that port. However, some applications did not first send outgoing
traffic and hence did not open an incoming port through the CGN. Other
applications try to open a particular fixed port through the CGN;
while service will work for a single subscriber behind the CGN, it
fails when multiple subscribers try to use that port.</t>
<t>PJSIP and other SIP software worked when clients used a
registration server to initiate calls, provided that the client inside
the CGN initiated the traffic first and that only one SIP user was
active behind a single IPv4 address at any given time. However, in our
testing, we observed that when making a direct client-to-client SIP
call across two home networks on a single ISP, or when calling from a
single home network across dual ISPs, calls could neither be initiated
nor received.</t>
<t>In the case of peer-to-peer gaming between two Xbox 360 users in
different home networks on the same ISP, the game could not be
connected between the two users. Both users shared an outside IP
address, and tried to connect to the same port, causing a connection
failure. There are some interesting nuances to this problem. In the
case where two users are in the same home network and the scenario is
through a single ISP, when the Xbox tries to register with the Xbox
server, the server sees that both Xboxes are coming through the same
public IP address and directs the devices to connect using their
internal IP addresses. So, the connection ultimately gets established
directly between both Xboxes via the home gateway, rather than the
Xbox server. In the case where there are two Xbox users on two
different home networks using a single ISP, and the CGN is configured
with only one public IPv4 address, this scenario will not work because
the route between the two users cannot be determined. However, if the
CGN is configured with two public NAT IP addresses this scenario will
work because now there is a unique IP address to communicate with.
This is not an ideal solution, however, because it means that there is
a one-to-one relationship between IP addresses in the public NAT and
the number of Xbox users on each network.</t>
<t>Other peer-to-peer applications that were noted to fail were
seeding sessions initiated on Bittorent and uTorrent. In our test,
torrent seeding was initiated on a client inside the CGN. Leeching was
initiated using a client on the public Internet. It was observed that
direct peer-to-peer seeding did not work. However, the torrent session
typically redirected the leeching client to a proxy server, in which
case the torrent session was set up successfully. Additionally, with
the proxy in the network, re-seeding via additional leech clients
worked as would be expected for a typical torrent session. Finally,
uTorrent tries to use STUN to identify its outside address. In working
with vendors, we learned that increasing the STUN timeout to 4 minutes
improved uTorrent seeding performance behind a CGN, resulting in the
ability for the uTorrent client to open a port and successfully seed
content.</t>
</section>
<section title="Degraded Services">
<t>There were several applications that diminished the user experience
in our environment. We measured these variations in user experience
against a baseline IPv4 environment where NAT is not deployed.
Specifically, large size file transfers and multiple video streaming
sessions initiated on a single client on the same home network proved
to be problematic with some home routers behind the CGN.</t>
<t>In our testing, we tried large file transfers from several FTP
sites, as well as downloading sizable audio and video files (750MB
– 1.4 GB) from the Internet Archive. We observed that when
Dual-Stack Lite was implemented for some specific home router and
client combinations, the transfer rate was markedly slower. For
example, PC1 using one operating system behind the same home router as
PC2 using a different operating system yielded a transfer rate of
120Kbps for PC1, versus 250Kbps for PC2. Our conclusion is that
varying combinations of home routers and CE client devices may result
in a user experience that is less than what the user would expect for
typical applications. It is also difficult to predict which
combinations of CPE routers and CE devices will produce a reduced
experience for the user. We did not analyze the root cause of the
divergence in performance across CE devices, as this was beyond the
scope of our testing. However, as this issue was specific to
Dual-Stack Lite, we suspect that it is related to the MTU.</t>
<t>While video streaming sessions for a single user generally
performed well, testing revealed that video streaming sessions such as
Microsoft Smooth Streaming technology (i.e. Silverlight) or Netflix
might also exhibit some service impacting behavior. In particular,
this was observed on one older, yet popular and well-known CPE router
where the first session was severely degraded when a second session
was initiated in the same home network. Traffic from the first session
ceased for 8 s once the second session was initiated. While we are
tempted to write this off as a problematic home router, its popularity
suggests that home router interactions may cause issues in NAT444
deployments (newer routers that support DS-Lite were not observed to
experience this condition). Overall, longer buffering times for video
sessions were noted for most client devices behind all types of home
routers. However, once the initial buffering was complete, the video
streams were consistently smooth. In addition, there were varying
degrees as to how well multiple video sessions were displayed on
various client devices across the CPE routers tested. Some video
playback devices performed better than others.</t>
</section>
<section title="Improvements since 2010">
<t>Since CableLabs completed initial CGN testing in 2010, there have
been quantifiable improvements in performance over CGN since that
time. These improvements may be categorized as follows:</t>
<t><list style="symbols">
<t>Content provider updates</t>
<t>Application updates</t>
<t>Improvements on the CGNs themselves</t>
</list>In terms of content provider updates, we have noted
improvements in the overall performance of streaming applications in
the CGN environment. Whereas applications such as streaming video were
very problematic a year ago with regard to jitter and latency, our
most recent testing revealed that there is less of an issue with these
conditions, except in some cases when multiple video streaming
sessions were initiated on the same client using specific types of
home routers. Applications such as MS Smooth Streaming appear to have
addressed these issues to some degree.</t>
<t>As far as application updates, use of STUN and/or proxy servers to
offset some of the limitations of NAT and tunneling in the network are
more evident as workarounds to the peer-to-peer issues. Applications
appear to have incorporated other mechanisms for delivering content
faster, even if buffering times are somewhat slower and the content is
not rendered as quickly.</t>
<t>CGN vendors have also upgraded their devices to mitigate several
known issues with specific applications. With regard to addressing
peer-to-peer SIP call applications, port reservations appear to be a
workaround to the problem. However, this approach has limitations
because of there are limited numbers of users that can have port
reservations at any given time. For example, one CGN implementation
allowed a port reservation to be made on port 5060 (default SIP port)
but this was the only port that could be configured for the SIP
client. This means that only one user can be granted the port
reservation.</t>
</section>
<section title="Additional CGN Challenges">
<t>There are other challenges that arise when using shared IPv4
address space, as with NAT444. Some of these challenges include: <list
style="symbols">
<t>Loss of geolocation information - Often, translation zones will
cross traditional geographic boundaries. Since the source
addresses of packets traversing an LSN are set to the external
address of the LSN, it is difficult for external entities to
associate IP/Port information to specific locations/areas.</t>
<t>Lawful Intercept/Abuse Response - Due to the nature of NAT444
address sharing, it will be hard to determine the
customer/endpoint responsible for initiating a specific IPv4 flow
based on source IP address alone. Content providers, service
providers, and law enforcement agencies will need to use new
mechanisms (e.g., logging source port and timestamp in addition to
source IP address) to potentially mitigate this new problem. This
may impact the timely response to various identification requests.
See <xref target="RFC6269"></xref></t>
<t>Antispoofing - Multiplexing users behind a single IP address
can lead to situations where traffic from that address triggers
antispoofing/DDoS protection mechanisms, resulting in
unintentional loss of connectivity for some users.</t>
</list></t>
</section>
</section>
<section title="2011 Summary of Results">
<section title="NAT444">
<texttable style="all" title="NAT-444">
<ttcol>Test Scenario (per Test Plan)</ttcol>
<ttcol>Single ISP, Single HN, Single User</ttcol>
<ttcol>Single ISP, Two HN, Single User on Each</ttcol>
<ttcol>Dual ISP, One HN with One User on Each ISP</ttcol>
<ttcol>Dual ISP, One HN+One User on ISP-A, Two HN with One User on
Each on ISP-B</ttcol>
<ttcol>Notes</ttcol>
<c>Video streaming over Netflix</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>fails behind one router</c>
<c>Video streaming over YouTube</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Video streaming over Joost</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Online gaming with one user</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>NT</c>
<c></c>
<c>Peer to Peer gaming with two users</c>
<c>Pass</c>
<c>Fail</c>
<c>Pass</c>
<c>NT</c>
<c>fails when both users NAT to same address</c>
<c>Bit Torrent uTorrent file seeding</c>
<c>Fail</c>
<c>Fail</c>
<c>Fail</c>
<c>Fail</c>
<c></c>
<c>Bit Torrent uTorrent file leeching</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Pandora internet radio</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>FTP server</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Web conferencing GTM</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Social Networking Facebook</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Social Networking Webkinz</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>X-Lite for SIP calls with proxy</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>X-Lite for SIP calls no proxy</c>
<c>Fail</c>
<c>Fail</c>
<c>Fail</c>
<c>Fail</c>
<c></c>
<c>Skype text chat</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Skype video chat</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Oovoo</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>MS Smooth streaming</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Internet Archive video streaming</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Internet Archive audio streaming</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Internet Archive file download</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
<c>Iclips</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c>Pass</c>
<c></c>
</texttable>
</section>
<section title="DS-Lite">
<texttable style="all" title="DSLite">
<ttcol>Test Scenario (per Test Plan)</ttcol>
<ttcol>DS-Lite Test Results</ttcol>
<ttcol>Duration of Test Performed</ttcol>
<ttcol>Description of Test Execution</ttcol>
<ttcol>General Observations/Notes</ttcol>
<c>Video streaming over Netflix</c>
<c>Pass</c>
<c>15</c>
<c></c>
<c></c>
<c>Video streaming over YouTube</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>Video streaming over Joost</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>On line gaming (one user)</c>
<c>Pass</c>
<c>15</c>
<c></c>
<c></c>
<c>Peer to Peer gaming (two users)</c>
<c>Fail</c>
<c>NA</c>
<c>user inside HN1 playing game against user inside HN2</c>
<c>Users inside both HN are not able to connect. The error shown on
console- "The game session is no longer available"</c>
<c>Bit Torrent/uTorrent file seeding</c>
<c>Fail</c>
<c>12</c>
<c>user on the internet is able to download file using proxy server
and not peer-to-peer</c>
<c></c>
<c>Bit Torrent/uTorrent file leeching</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>Pandora internet radio</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>FTP server</c>
<c>Pass</c>
<c>700 Mb</c>
<c></c>
<c></c>
<c>Web conferencing (GTM)</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>Social Networking - Facebook</c>
<c>Pass</c>
<c>NA</c>
<c></c>
<c></c>
<c>Social Networking - Webkinz</c>
<c>Pass</c>
<c>NA</c>
<c></c>
<c></c>
<c>X-Lite (for SIP calls) (proxy given)</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>X-Lite (for SIP calls) (proxy not given)</c>
<c>Fail</c>
<c>NA</c>
<c></c>
<c></c>
<c>Skype text chat</c>
<c>Pass</c>
<c>NA</c>
<c></c>
<c></c>
<c>Skype video chat</c>
<c>Pass</c>
<c>20</c>
<c></c>
<c></c>
<c>Oovoo</c>
<c>Pass</c>
<c>15</c>
<c></c>
<c></c>
<c>MS Smooth streaming</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>Internet Archive - video streaming</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
<c>Internet Archive - audio streaming</c>
<c>Pass</c>
<c>5</c>
<c></c>
<c></c>
<c>Internet Archive - file download</c>
<c>Pass</c>
<c>80 Mb</c>
<c></c>
<c></c>
<c>Iclips</c>
<c>Pass</c>
<c>10</c>
<c></c>
<c></c>
</texttable>
</section>
</section>
<section title="2010 Summary of Results">
<t>The tables below summarize results from 2010 NAT444 testing at
CableLabs, Time Warner Cable, and Rogers Communications. They are
included for comparison with 2011 results, documented above.</t>
<section title="Case1: Single Client, Single Home Network, Single Service Provider">
<texttable style="all" title="Case1">
<ttcol>Test Case</ttcol>
<ttcol>Results</ttcol>
<ttcol>Notes</ttcol>
<c>Web browsing</c>
<c>pass</c>
<c></c>
<c>Email</c>
<c>pass</c>
<c></c>
<c>FTP download</c>
<c>pass</c>
<c>performance degraded on very large downloads</c>
<c>Bittorrent leeching</c>
<c>pass</c>
<c></c>
<c>Bittorrent seeding</c>
<c>fail</c>
<c></c>
<c>Video streaming</c>
<c>pass</c>
<c></c>
<c>Voice chat</c>
<c>pass</c>
<c></c>
<c>Netflix streaming</c>
<c>pass</c>
<c></c>
<c>Instant Messaging</c>
<c>pass</c>
<c></c>
<c>Ping</c>
<c>pass</c>
<c></c>
<c>Traceroute</c>
<c>pass</c>
<c></c>
<c>Remote desktop</c>
<c>pass</c>
<c></c>
<c>VPN</c>
<c>pass</c>
<c></c>
<c>Xbox live</c>
<c>pass</c>
<c></c>
<c>Xbox online</c>
<c>pass</c>
<c>Blocked by some LSNs.</c>
<c>Xbox network test</c>
<c>fail</c>
<c>Your NAT type is moderate. For best online experience you need an
open NAT configuration. You should enable UPnP on the router.</c>
<c>Nintendo Wii</c>
<c>pass behind one LSN, fail behind another</c>
<c></c>
<c>Playstation 3</c>
<c>pass</c>
<c></c>
<c>Team Fortress 2</c>
<c>fail</c>
<c>pass behind one LSN, but performance degraded</c>
<c>Starcraft II</c>
<c>pass</c>
<c></c>
<c>World of Warcraft</c>
<c>pass</c>
<c></c>
<c>Call of Duty</c>
<c>pass</c>
<c>performance degraded behind one LSN</c>
<c>Slingcatcher</c>
<c>fail</c>
<c></c>
<c>Netflix Party (Xbox)</c>
<c>fail</c>
<c>pass behind one LSN</c>
<c>Hulu</c>
<c>pass</c>
<c>performance degraded behind one LSN</c>
<c>AIM File Tranfer</c>
<c>pass</c>
<c>performance degraded</c>
<c>Webcam</c>
<c>fail</c>
<c></c>
<c>6to4</c>
<c>fail</c>
<c></c>
<c>Teredo</c>
<c>fail</c>
<c></c>
</texttable>
</section>
<section title="Case2: Two Clients, Single Home Network, Single Service Provider">
<texttable style="all" title="Case2">
<ttcol>Test Case</ttcol>
<ttcol>Results</ttcol>
<ttcol>Notes</ttcol>
<c>Bittorrent leeching</c>
<c>pass</c>
<c></c>
<c>Bittorrent seeding</c>
<c>fail</c>
<c></c>
<c>Video streaming</c>
<c>fail</c>
<c></c>
<c>Voice chat</c>
<c>pass</c>
<c></c>
<c>Netflix streaming</c>
<c>pass</c>
<c>performance severely impacted, eventually failed</c>
<c>IM</c>
<c>pass</c>
<c></c>
<c>Limewire leeching</c>
<c>pass</c>
<c></c>
<c>Limewire seeding</c>
<c>fail</c>
<c></c>
</texttable>
</section>
<section title="Case3: Two Clients, Two Home Networks, Single Service Provider">
<texttable style="all" title="Case3">
<ttcol>Test Case</ttcol>
<ttcol>Results</ttcol>
<ttcol>Notes</ttcol>
<c>Limewire leeching</c>
<c>pass</c>
<c></c>
<c>Limewire seeding</c>
<c>fail</c>
<c></c>
<c>Utorrent leeching</c>
<c>pass</c>
<c></c>
<c>Utorrent seeding</c>
<c>fail</c>
<c></c>
</texttable>
</section>
<section title="Case4: Two Clients, Two Home Networks, Two Service Providers Cross ISP">
<texttable style="all" title="Case4">
<ttcol>Test Case</ttcol>
<ttcol>Results</ttcol>
<ttcol>Notes</ttcol>
<c>Skype voice call</c>
<c>pass</c>
<c></c>
<c>IM</c>
<c>pass</c>
<c></c>
<c>FTP</c>
<c>fail</c>
<c></c>
<c>Facebook chat</c>
<c>pass</c>
<c></c>
<c>Skype video</c>
<c>pass</c>
<c></c>
</texttable>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security considerations are described in <xref
target="I-D.shirasaki-nat444"></xref>.</t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.shirasaki-nat444;
&RFC3056;
&RFC4380;
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.1918'?>
<?rfc include='reference.RFC.6269'?>
</references>
<section title="Acknowledgements">
<t>Thanks to the following people for their testing, guidance, and
feedback: <list style="hanging">
<t>Paul Eldridge</t>
<t>Abishek Chandrasekaran</t>
<t>Vivek Ganti</t>
<t>Joey Padden</t>
<t>Lane Johnson</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:03:02 |