Thanks Yiu, your suggestion makes a lot of sense, and I'm considering it. Cheers, Xiaohong
|-----Original Message----- |From: Lee, Yiu [mailto:[email protected]] |Sent: Thursday, August 11, 2011 1:45 AM |To: [email protected] |Subject: Re: [Softwires] Clarification of the |stateles/stateful discussion | |I also agree this is a very nice piece of work. The current |title is "Implementing AplusP in the provider's IPv6-only |network". I think this not only covers "Implementing AplusP in |an IPv6-only network", but also captures very important |information about the port usage in various applications. I |would like to see the draft to expand to include more popular |applications and OS, and the radio between port usage and |number of sessions. By reading Fig. 3 and Fig. 4 in |http://opensourcev6transtechnologies.weebly.com/experiments-res |ults.html, |the radio is roughly 1 to 4. These experiments give concrete |results to operators to plan for any port-sharing technology. | |Cheers, |Yiu | | |On 8/10/11 8:38 AM, "Rajiv Asati (rajiva)" <[email protected]> wrote: | |>Xiaohong, |> |>Your work is very insightful. Thanks for pointing it out. |> |>In your experimentation, did you use 'consecutive' port-set or |>'scattered' port-set or both? If just the former, then is it possible |>to experiment using 'scattered' port-set? |> |>Cheers, |>Rajiv |> |> |>> -----Original Message----- |>> From: [email protected] |[mailto:xiaohong.deng@orange- |>>ftgroup.com] |>> Sent: Wednesday, August 10, 2011 5:35 AM |>> To: [email protected]; Rajiv Asati (rajiva) |>> Cc: [email protected] |>> Subject: RE: [Softwires] Clarification of the stateles/stateful |>>discussion |>> |>> |>> |>> |-----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-r |esults.ht |>>ml 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 | | | _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
