Xiaohong, It shouldn't, I agree. And your test could attest to that (as some may not agree otherwise).
Cheers, Rajiv > -----Original Message----- > From: [email protected] [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Thursday, August 11, 2011 7:02 AM > To: Rajiv Asati (rajiva); [email protected] > Cc: [email protected] > Subject: RE: [Softwires] Clarification of the stateles/stateful discussion > > Rajiv, > > Thanks! > > It's 'consecutive' port-set, and thanks for your proposal for testing > 'scattered' port-set. > > But I don't understand will the figure be different with 'scattered' port-set > NAT? To my knowledge, it's something todo with app's behaviours and NAT > type(EIM in our test). > Would you explain if I miss something? Thanks > > Cheers, > Xiaohong > > |-----Original Message----- > |From: Rajiv Asati (rajiva) [mailto:[email protected]] > |Sent: Wednesday, August 10, 2011 8:39 PM > |To: DENG Xiaohong ESP/PEK; [email protected] > |Cc: [email protected] > |Subject: RE: [Softwires] Clarification of the > |stateles/stateful discussion > | > |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.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
