[sunset4] draft-li-behave-NAT444-Test

["George, Wes" <[e-mail]>]

I have some comments below on this draft.

> From: Will Liu (Shucheng) [mailto:[e-mail]]
> Sent: Wednesday, July 11, 2012 5:42 AM
> To: George, Wes
> Cc: [e-mail]
> Subject: Asking for two 10min slots
>
>
> Following are my answers to your three question for both drafts:
> Q:
> 1) describe the problem to be solved and show that there is widespread
> demand for a solution
> 2) demonstrate that the problem can not be solved with existing
> technologies
> 3) provide a description of the proposed solution along with its impact
> on current IPv4-only use and justification that it does not harm or
> delay the deployment of IPv6
>
> A:
> draft-Li-Behave-NAT444-Test-00
> 1) NAT444 is a common scenario in operators' network.  Operators are
> worried whether applications will be affected when they pass though
> multi-level NAT. This test document provides experiences for both
> operators and researchers.
> 2) During testing, we find some problems such as QQ online Gaming
> doesn't permit two user with the same public IP address in same game
> room.
> 3) This is a testing draft. Proposed solution is not related.
>

[WEG] Originally, I tried to separate my comments into comments as an individual and comments as a chair, but I'm having trouble doing so. Therefore I'll just present my feedback with the caveat that my personal opinions are coloring my guidance and response, and hope that my comments are helpful. The last few sentences regarding whether we discuss this draft in Vancouver are definitely spoken as Sunset4 co-chair.

In its current form, I'm not certain that this draft has a lot of value as a WG draft, whether for sunset4 or otherwise. It's already well-known that NAT, especially when it is NAT444 will break certain applications and this requires either an ALG or for the maintainer of that application to make changes to their behavior so that it works properly through NAT. This draft has only one failed test case, and as others have pointed out, it's a known address-sharing problem based on faulty assumptions about 1:1 mapping between end users and their IP addresses, rather than a problem specific to CGN's implementation. Therefore it cannot be solved by changes to CGN, nor "fixed" by IETF action. We want to continue to educate web and application providers on this problem, but I think that has been well-covered by existing IETF work such that it doesn't justify another draft.

IETF drafts, due to the time that they take to get to published state, and the fact that they cannot be updated after publishing, do not lend themselves well to publishing something like test results of this nature, because test results are a snapshot in time. As soon as the test results are published, (hopefully) the problems identified get resolved, and the results get outdated. There is also a concern about the choices of the sites/applications to test - they may be very popular at the time when the test was undertaken, but their popularity may have waned to the point where the test is now irrelevant. Unless the test results highlight an overall problem with a certain class of site or application, or a certain common behavior that must be changed, they are relevant only if one knows the specific details of the implementation of the application or site under test, and only if that implementation does not undergo changes after publishing, either to fix brokenness, or sometimes to break something that was previously working. These sorts of specific problems are best addressed directly with the site or application maintainer. IETF focuses on more widely applicable problems, such as whether a new ALG should be standardized for a given class of application that is broken, or if we should be providing updated guidance to application and web providers to ensure that more applications work through CGN.

Sunset4, and IETF as a whole, has a bit of a love/hate relationship with CGN and NAT444. It's a necessary evil to preserve IPv4 functionality until IPv6 is fully deployed. However, the message has been clear-  use it only as little as necessary, deploy IPv6, and be ready for things to break. Drafts that give a false sense of security (all test cases passed except for one) of how well CGN works are probably not in keeping with this message, especially if they in no way mention that IPv4 + CGN is a temporary solution, and that IPv6 is the long-term resolution.

This draft is also too specific. It is discussing test results for one vendor's CGN solution, and since there is little in the way of standards for implementing CGN, that may not be indicative of general CGN performance. This is likely more appropriate to be published as a use case/test results whitepaper on said vendor's website rather than via IETF. It is also very geographically specific given its focus on a specific region of a specific country and mostly country/language-specific content and applications. While that may be useful for those in that region, it limits the utility and relevance of the test results for the wider IETF audience. In addition, it may lead to confusion by causing the reader to draw a conclusion that the results will be indicative of the experience in other applications with other sites, users, locations, etc. In truth, I think that the best message we can send about CGN is "do your own testing on the applications that are important to you and your customers, your mileage may vary significantly."

It may be appropriate to pursue publishing this draft via independent submission, but I would need to hear strong support from the WG before adding it to the agenda to be discussed further in Vancouver.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.