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-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
