Re: [BEHAVE] comments on draft-donley-nat444-impacts

[Reinaldo Penno <[e-mail]>]

I fully support the questions this draft is trying to answer, but without a
'control group' most of the data and results are open the questions.

In order to become useful the draft need to provide another table with the
same experiments done with same CPE, host, etc but behind a single NAT (no
LSN). And then possibly a host directly connected to the Internet. These
would be the control groups.

For example, the Netflix error mentioned is _very_ common when there is not
enough bandwidth and there is no low bandwidth codec that fits the
situation. Personally I have seen this error when starting multiple movies
at the same time.

The statement about degradation when using high bandwidth applications is
true but the bottleneck is not clear. High bandwidth streaming (1.5Mb+) is
well know to cause problems on certain CPEs that were designed for bursts of
traffic or sustained (but low bandwidth) traffic. If I put my old home
router back in action and start two HD Netflix streaming (5.0Mbps+)
sustained it will:

* lock up and reboot or
* Netflix will adapt first and reduce quality considerably because CPE can
not keep up.

Thanks,

Reinaldo


On 11/4/10 10:09 AM, "Dan Wing" <[e-mail]> wrote:

> draft-donley-nat444-impacts-01 is somewhat misleading.  It claims to analyze
> NAT444, but it really analyzes what fails when two problems occur: (a) port
> forwarding isn't configured and (b) UPnP is unavailable or is broken.
> Several architectures share those two problems:
>
>   * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network)
>   * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home)
>   * DS-Lite (which is an LSN / NAPT44 in the carrier's network)
>   * stateful NAT64
>
> It is unfortunate, to put it mildly, that draft-donley-nat444-impacts-01
> singles out NAT444 as the sole architecture with these two problems.
>
> In all four architectures, port forwarding isn't available via UPnP IGD
> because the large-scale NAT doesn't support UPnP IGD.  In the first
> architecture (NAT444), the in-home NAT might still have UPnP IGD enabled,
> which can confuse applications attempting to use UPnP IGD.  Was UPnP IGD
> enabled in the home CPE in your tests?  The error message from the XBox test
> *implies* that UPnP IGD was disabled, but I don't know for sure.  UPnP IGD
> needs to be disabled in the CPE in all four of the above architectures,
> because UPnP IGD doesn't know how to speak to upstream NATs (and no carrier
> NAT on the market supports UPnP IGD).  When the PCP working group specifies
> a UPnP IGD-to-PCP interworking function, and it is implemented in CPE, it
> will be safe (and useful) to enable UPnP IGD on the in-home CPE in all three
> scenarios.  Until then, enabling UPnP IGD in a CPE is harmful when the CPE
> is behind any sort of NAT.
>
>
>
> Detailed review:
>
> "2.1. NAT444 Additional Challenges
>
>    There are other challenges that arise when using shared IPv4 address
>    space, as with NAT444.  Some of these challenges include:
>
>    "o  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."
>
>    o  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 [I-D.ietf-intarea-shared-addressing-issues]
>
>    o  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."
>
> All three of these points are not specific to NAT444.  They are aspects
> common to any address sharing system, including any large-scale NAT --
> NAT444, LSN, DS-Lite, NAT64 (especially stateful NAT64), A+P -- and has no
> difference if the subscriber operates a NAT in their home.
> draft-ietf-intarea-shared-addressing-issues does a good job of summarizing
> all of the issues.  Thus, these are not "Additional Challanges" of NAT444,
> as stated in the title of Section 2.1.
>
>
> Section 3's diagrams would be clearer if, instead of "home router", the
> diagrams clearly showed the device in the home is a NAPT44.
>
>
> Section 3 -- were tests not run without the LSN?  That is, were tests run
> with just the "home router", with UPnP disabled?  This would separate
> failures that are caused by "port forwarding not enabled" from failures
> caused by NAT444 itself from failures caused by the LSN itself.
>
>
> Section 3 -- was an RFC1918 address used between the in-home CPE and the
> LSN?  If so, did the in-home CPE disable its NAT function (turn itself into
> a bridge)?  If not, were any problems attributable to the in-home CPE
> enabling its 6to4 function, or the in-home CPE mistakenly thinking its WAN
> address was publicly routable on the Internet?
>
>
> Section 3.1,
>
>    "Also, large FTP downloads experienced issues when
>     translation mappings timed out."
>
> I assume that refers to the FTP control connection being timed out while the
> data connection is active.
>
> In a NAT444 environment, there are two elements that might time out FTP's
> control TCP connection:  (a) the home NAT or (b) the large-scale NAT:
>
> a. If the home NAT causes the timeout, that problem exists today with
>     all subscribers using that specific firmware of that specific home
>     NAT. This is not a problem caused by NAT444.
>  b. If the LSN causes the timeout, this affects all LSN deployments
>     (stateful NAT64, NAT444, DS-Lite, etc.), and is something that
>     should be captured in a requirements document somewhere ("for
>     FTP, don't time out the control connection if the data
>     connection is still active" or suchlike).  This is not a problem
>     caused by NAT444.
>
> I can't tell if the FTP problem mentioned in 3.1 ("mappings timed out") is
> the same as "performance degraded on very large downloads", mentioned in
> Section 4.1.  Is it the same?
>
>
> Section 3.1,
>
>    "Bittorrent seeding also failed during some tests."
>
> Not caused by NAT444.
>
> draft-boucadair-behave-bittorrent-portrange can explain why, but
> the problem is that port forwarding is needed for successful BitTorrent
> seeding.  The inability to forward ports is a problem of all LSN
> architectures at this time (NAT444, LSN, DS-Lite, NAT64).  An ISP-operated
> portal and recipe (like http://portforward.com) could solve the problem
> for all of the LSN architectures.  Or wait for PCP.
>
>
> Section 3.2,
>
>   "Torrent leeching was performed
>    from the two clients to a public server in the Internet.  The
>    observed speed was considerably slower than with only one client
>    connected to the home network."
>
> Not caused by NAT444.
>
> This is a problem with *any* address sharing when two hosts behind the
> same IP address are attempting to retrieve the same data from the same
> remote BitTorrent peer.  BitTorrent behaves like that on purpose, in
> order to reduce the threat of leeching bandwidth.  The bt.allow_same_ip
> setting, on the remote BitTorrent hosts, controls this behavior.  See
> draft-boucadair-behave-bittorrent-portrange which is an extensive
> analysis of BitTorrent behavior in conjunction with IP address
> sharing.
>
> draft-boucadair-behave-bittorrent-portrange also shows that, absent
> port forwarding, BitTorrent leeching is considerably slower than with
> port forwarding.  Anyone can verify that behavior in the comfort of
> their own home.  I found the same torrent, after 4 hours of running,
> was downloading at only 50kbps without port forwarding but would
> download 10x faster with port forwarding.  A large legal torrent
> is one of the ~160Gb torrents from three Nine Inch Nails concerts
> listed at http://forum.nin.com/bb/read.php?52,378166 -- they have
> only a few seeds to the behavior of (stingy) peers is more obvious.
>
>
> Section 3.2,
>
>   "It is generally noted that the performance decreases in
>    bandwidth intensive applications."
>
> Sure, but is that different from today's behavior (without a LSN)
> in some way?
>
>
>   "Netflix video
>    streaming is also observed to be considerably choppy.  When streaming
>    starts on one client, it does not start on the other, generating a
>    message saying that the Internet connection is too slow.
>
> Unlikely a fault of NAT444.
>
> Was the Internet connection in fact too slow?  That is, was this test
> successful without an LSN?  Was this test successful with two hosts in
> the same home network without a NAPT44 in the home?  I doubt "NAT444" was
> at fault here, either.  But this I-D doesn't indicate if there was other
> testing of this scenario to rule out NAT444 as the cause, a bona-fide
> bandwidth issue, the in-home NAPT44 is the cause, or what.
>
>
> Section 4.1,
>
>   Bittorrent leeching:  pass
>
> Without port forwarding, I don't think I would characterize this as "pass"
> -- it is painfully slow in my experience to do BitTorrent leeching without
> port forwarding.  But that is not a problem solely with NAT444:  it is a
> problem of any type of NAT (LSN, NAT444, DS-Lite, home NAT) if port
> forwarding isn't configured.
>
>
>   Xbox network test: fail: Your NAT type is moderate.  For best online
>                            experience you need an open NAT configuration.
>                            You should enable UPnP on the router.
>
> Not a problem specific to NAT444.
>
> The error "your NAT type is moderate" means some ports aren't forwarded.  I
> found this nifty article that explained the error -- it's caused by port
> forwarding not working
> http://www.question-defense.com/2010/02/15/xbox-360-your-nat-type-is-moderat
> e-configure-port-forwarding-on-your-router, which says:
>
>   "You will need to add two port forwards which include port 3074 and
>    port 53 and make sure in both cases that you are forwarding both
>    the UDP and TCP ports."
>
> and which is also stated in "Open network ports" section of the following
> link on the XBox website,
> http://support.xbox.com/en-us/pages/xbox-live/troubleshoot/marketplace.aspx
>
> If this information is accurate -- and it certainly appears to be accurate
> -- XBox will not work well behind any sort of NAPT if there are more than
> one XBox behind the NAPT.  Don't buy two XBox's in the same home; a quick
> search on the Internet reveals that appears to be a common problem with
> XBox.  Of course the same problem occurs with large scale NAT44 of any kind
> (LSN without in-home NAT, NAT444, and DS-Lite) -- only one subscriber can
> use all of their XBox's functionality over the Internet.
>
> The second half of that XBox error message encourages the user to enable
> UPnP.  But of course that won't fix anything with any of the LSN scenarios
> (NAT444, DS-Lite, LSN).  Users won't know that, though.
>
>
>   Nintendo Wii: pass behind one LSN, fail behind another
>
> Would be useful to know what caused that success and that failure, and if it
> is specific to NAT444 or common with all large-scale NAT (DS-Lite, LSN,
> etc.), or due to UPnP IGD being broken/disabled.
>
>
>   Team Fortress 2: fail, pass behind one LSN, but performance degraded
>
>
> Would be useful to know what caused that success and that failure, and if it
> is specific to NAT444 or any large-scale NAT (DS-Lite, LSN, etc.), or due to
> UPnP IGD being broken/disabled.
>
>
>    Slingcatcher: fail
>
> Slingcatcher is no longer manufactured by Sling Media, but I am surprised by
> the failure because Sling does a *lot* of tricks to deal with NAPT.  (Wish
> it was still manufactured by Sling Media, I could use one myself.)  Does a
> regular Sling Player also fail (such as a PC connected to the Internet,
> attempting to view content on an in-home Slingbox)?  Does Slingcatcher work
> without LSN?
>
>   Netflix Party (Xbox): fail, pass behind one LSN
>
> Would be useful to know what caused that success and that failure, and if it
> is specific to NAT444 or common with all large-scale NAT (DS-Lite, LSN,
> etc.), or due to UPnP IGD being broken/disabled.
>
>   Webcam: fail
>
> This must have failed because of lack of port forwarding, so would be common
> to all large-scale NAT architectures (LSN, NAT444, DS-Lite).
>
>   6to4: fail
>
> Does this mean that 6to4 failed to come up, or that attempted IPv6
> connectivity was broken because the CPE's WAN IPv4 address is not globally
> routable?  Of all the problems listed, this one problem appears to be the
> only one that is directly attributable to NAT444, and caused by using a
> non-RFC1918 address on the CPE's WAN interface.  Note the severity of this
> problem is decreasing quickly as modern OSs have a very low preference for
> 6to4 addresses (Windows 7,
> http://packetblog.wordpress.com/2010/10/03/windows-7-user-you-are-ipv6-capab
> le; OSX 10.6.5,
> http://lists.cluenet.de/pipermail/ipv6-ops/2010-September/003932.html).
>
>   Teredo: fail
>
> Teredo was designed to work through all sorts of icky NATs.  I run two NATs
> at home, and have successfully set up Teredo through both of them, without
> doing any port forwarding.  Let's just say that I "have doubt" this test was
> conducted properly.
>
>
> I didn't repeat my comments for Sections 4.2, 4.3, and 4.4 (they are similar
> to my comments for 3.*).
>
> -d
>
>
>
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave