|-----Original Message----- |From: Rémi Després [mailto:[email protected]] |Sent: Wednesday, August 03, 2011 4:02 PM |To: Rajiv Asati (rajiva) |Cc: [email protected] |Subject: Re: [Softwires] Clarification of the |stateles/stateful discussion | | |Le 3 août 2011 à 00:39, Rajiv Asati (rajiva) a écrit : | |> Satoru-san, |> |> This is an important point that most of us forget that |restricting to |> "n" ports doesn't equate to just "n" NAT sessions rather many more |> than n sessions. We must add that to the 4v6 motivation |draft as well |> as to the 4v6 comparison draft. | |+1
+1. Session number are usually many more than ports number. We tested port and sessions assumptions of applications on the A+P NAT, which has been documented in A+P experiments draft, to investigate how many ports and sessions they are costing on the NAT mapping table dynamically from the first NAT bindings being established to the last one being destroyed. Some results below: Usually, apps consume some more sessions than ports, and for the P2P apps, sessions number could even be as a couple of times as ports number. For example, BitTorrent established five hundreds of sessions while the port consumption was under a hundred in the first minute of the communication, because when BitTorrent initiates a downloading, it first uses the same source port to connect to the different destinations (destination IP and port) therefore one source port multiplexing different sessions. Skype is another example that uses one source port to multiplex different sessions thereby saving source port consumptions on NAT. For exact figures of ports/session number for apps, see my page: http://opensourcev6transtechnologies.weebly.com/experiments-results.html The session consumption comparison among the same set of applications is illustrated in Figure 4. Xiaohong | |RD | |> |>> port. There may be multiple session to different destinations using |> the same |>> external port. The 900G figure is valid, as long as internal hosts |> reuse the |>> same source address+port for different destinations. |> |> Cheers, |> Rajiv |> |> |>> -----Original Message----- |>> From: [email protected] [mailto:[email protected]] |> On Behalf |>> Of Simon Perreault |>> Sent: Tuesday, August 02, 2011 9:55 AM |>> To: [email protected] |>> Subject: Re: [Softwires] Clarification of the stateles/stateful |> discussion |>> |>> Simon Perreault wrote, on 08/02/2011 09:24 AM: |>>> Satoru Matsushima wrote, on 08/01/2011 10:41 PM: |>>>> Thanks, a clarification has made to clear a confusion of |restricted |> port |>>>> set/ranges and NAT session table limitation. Even if a CPE is |> allocated 256 |>>>> ports, NAT session can be made over 900G sessions in theory. |> ('2^32'<Full |>>>> 32bits v4 address> - '2^29'<class-D/E> - '2^7'<0/8,127/8>) * |> 2^8<256 |>> ports>. |>>> |>>> This is only true for endpoint-dependent NATs, which are forbidden |> by the |>> BEHAVE |>>> RFCs (4787 and 5382). According to these RFCs, NATs MUST have |>>> endpoint-independent mapping behaviour. This means that each NAT |> session |>> will |>>> consume one external port. |>> |>> Sorry, I confused the terminology. Each NAT *binding* will consume |>> one external port. There may be multiple session to different |>> destinations using |> the same |>> external port. The 900G figure is valid, as long as internal hosts |> reuse the |>> same source address+port for different destinations. |>> |>> 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 |>> _______________________________________________ |>> Softwires mailing list |>> [email protected] |>> https://www.ietf.org/mailman/listinfo/softwires |> _______________________________________________ |> Softwires mailing list |> [email protected] |> https://www.ietf.org/mailman/listinfo/softwires | | | _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
