Subject: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-stateless-nat44

From: "George, Wes" <[email-masked]>
Date: Wed, 11 Jul 2012 10:23:50 -0400

The answers to our questions on two drafts are below. Please review and comment on the content of the answers, either together or separately. I'd like some discussion on the draft or the questions on-list before we get into the meeting.

Thanks

Wes George

-----Original Message-----
From: Will Liu (Shucheng) [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 5:42 AM
To: George, Wes
Cc: [email-masked]
Subject: Asking for two 10min slots

Hi George,

Thanks for your kindly reminding. Sorry for my carelessness. :D May I ask for 2 time slots for draft-Li-Behave-NAT444-Test-00 and draft-tsou-stateless-nat44？Each presentation would last for 10min and the presenter will be Will Liu.

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.

draft-tsou-stateless-nat44-00
1)  To let the NAT44 CGN simple, to reduce the cost of CGN. Different from traditional NAT44: no per-session state on the CGN, no binding table, no per-flow state to be maintained, zero log, high speed, easy to deploy hot backup.
2)  Traditional NAT44 CGN need per-session state on the CGN, binding table, per-flow state to be maintained. These make the CGN expensive and difficult to achieve CGN hot backup.
3)  Solve the exhaustion of IPv4 address when the network migrate to IPv6. Because it is stateless, the ISPs don’t need too much cost to deploy it. It can also be implemented in dual-stack network(IPv4 traffic pass through stateless NAT44 and IPv6 traffic pass by stateless NAT44), so the network can migrate to IPv6 smoothly.

Regards,
Will

-----Original Message-----
From: George, Wes [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 12:48 PM
To: Will Liu (Shucheng); [email-masked]
Subject: RE: Asking for a 10min slot

Please see the message I sent to the list this AM.

Thanks,

Wes

> -----Original Message-----
> From: Will Liu (Shucheng) [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2012 5:30 AM
> To: [email-masked]
> Subject: Asking for a 10min slot
>
> Hi Chairs,
>
> I am writing to ask for a 10 min slot for a presentation for
> draft-tsou- stateless-nat44.
> Presenter name is Will Liu and length of presentation is 10 minutes.
> Thanks.
>
> Have a nice day!
> Will

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.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Jul 2012 09:44:05 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of George, Wes
> Sent: Wednesday, July 11, 2012 7:24 AM
> To: [email-masked]
> Subject: [sunset4] FW: draft-li-behave-NAT444-Test and draft-tsou-
> stateless-nat44
> 
> The answers to our questions on two drafts are below. Please review and
> comment on the content of the answers, either together or separately.
> I'd like some discussion on the draft or the questions on-list before
> we get into the meeting.

See below.

> Thanks for your kindly reminding. Sorry for my carelessness. :D May I
> ask for 2 time slots for draft-Li-Behave-NAT444-Test-00 and draft-tsou-
> stateless-nat44？Each presentation would last for 10min and the
> presenter will be Will Liu.
> 
> 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:
> 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.

Other applications have a similar restriction.  For example, Mohamed
has done extensive testing with BitTorrent and described the precise
slowdowns and the precise failures when two users are sharing the 
same IPv4 address, draft-boucadair-pcp-bittorrent.

Cablelabs published results of some of their testing using a 
different mix of applications.  I have previously raised 
objections to their testing methodology and results.  Their 
document is draft-donley-nat444-impacts.

> 1)  To let the NAT44 CGN simple, to reduce the cost of CGN. Different
> from traditional NAT44: no per-session state on the CGN, no binding
> table, no per-flow state to be maintained, zero log, high speed, easy
> to deploy hot backup.
> 2)  Traditional NAT44 CGN need per-session state on the CGN, binding
> table, per-flow state to be maintained. These make the CGN expensive
> and difficult to achieve CGN hot backup.
> 3)  Solve the exhaustion of IPv4 address when the network migrate to
> IPv6. Because it is stateless, the ISPs don’t need too much cost to
> deploy it. 

This seems to be a MAP solution.  But differs from MAP in that it uses
an IPv4 network between the subscriber and the ISP's "stateless NAT44"
device, whereas MAP uses an IPv6 network between the subscriber and 
the ISP's "MAP border relay" device.

> It can also be implemented in dual-stack network(IPv4
> traffic pass through stateless NAT44 and IPv6 traffic pass by stateless
> NAT44), so the network can migrate to IPv6 smoothly.

Typo in that sentence?

-d

> 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.
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Mon, 16 Jul 2012 04:00:16 +0000

Thanks for your comments. Followings are my reply to them.
1)I will read those drafts you mentioned and search your comments. 
2)What we proposed is focused to do and only do modification on the CGN, without too many changes on the current v4 network. Map with IPv6 is another scenario.
3) Should be "bypass". Sorry for that.

Cheers,
Will

> Behalf Of Dan Wing
> Sent: Thursday, July 12, 2012 12:44 AM
> To: 'George, Wes'; [email-masked]; Will Liu (Shucheng)
> Subject: Re: [sunset4] FW: draft-li-behave-NAT444-Test and
> draft-tsou-stateless-nat44
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Jul 2012 14:58:44 -0400

> the ISP's "MAP border relay" device.

I think this is a fair comparison.

One advantage of SLNAT44 over MAP is that the necessary changes to the
CPE are minimal. For example, a vanilla Linux can do SLNAT44 today.

Another advantage of SLNAT44 is simpler provisioning: CPEs don't need to
have access to all the "mapping rules" for direct communication to work.
In MAP/4rd, a CPE needs to compute the IPv6 address to which the IPv4
address it wants to reach is mapped. That's why rules need to be
downloaded to the CPE. In SLNAT44, you just send the packet directly to
the IPv4 address you want to reach. There is no overlay network, so no
rules to be downloaded.

Simplicity! :)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: GangChen <[email-masked]>
Date: Fri, 20 Jul 2012 14:01:30 +0800

The draft is quite interesting
One question for clarification

Is the mapping between Internal Prefix & External Prefix  1:1 or N:1 ?

BRs

Gang

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Fri, 20 Jul 2012 06:57:54 +0000

Thanks for your interests in our draft. 

I am not quite sure whether you were asking the mapping between prefixs or IPs. Let me explain both. In our method, mapping between internal prefix and external prefix is 1:1, while mapping between internal IP and external IP is N:1. As shown in Figure 2 and 3, the length of external prefix is longer than the internal prefix. More specifically, the difference between them is the length of port set id. Did this answer the question, or do you have other questions regarding the mapping?

Regards,
Will

> Behalf Of GangChen
> Sent: Friday, July 20, 2012 2:02 PM
> To: Simon Perreault
> Cc: George, Wes; [email-masked]; Dan Wing; Will Liu (Shucheng)
> Subject: Re: [sunset4] Stateless NAT44 vs MAP/4rd
>

---

From: GangChen <[email-masked]>
Date: Fri, 20 Jul 2012 16:01:37 +0800

2012/7/20, Will Liu (Shucheng) <[email-masked]>:
> I am not quite sure whether you were asking the mapping between prefixs or
> IPs. Let me explain both. In our method, mapping between internal prefix and
> external prefix is 1:1, while mapping between internal IP and external IP is
> N:1. As shown in Figure 2 and 3, the length of external prefix is longer
> than the internal prefix. More specifically, the difference between them is
> the length of port set id. Did this answer the question, or do you have
> other questions regarding the mapping?

Thanks.
To be more precise, I guess N=2^(b-a) if I understood correctly
In another words, when network assigns external prefix, the
multiplexing ratio was been pre-determined by length of internal
prefix, i.e. deterministic NAT behaviour

BRs

Gang

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 Jul 2012 09:27:17 -0400

> prefix, i.e. deterministic NAT behaviour

Right. The with SLNAT44 the ISP chooses the address sharing ratio 
statically, just like A+P/MAP/4rd/etc.

Simon