Tina, > The problem with static allocation is that it cannot adapt quickly to > subscriber demand.
Exactly; so it cannot optimise the number of ports in use. What strikes me in this conversation is that all these solutions are a tremendous amount of work to deal with legacy equipment, and I have to wonder whether that is economically rational. That is for the market to decide, but I don't see that the IETF is obliged to solve each possible case. In other words I'm not sure where to find the requirements analysis that this new burst of activity is based on. Regards Brian On 2011-08-24 07:23, Tina TSOU wrote: > Dear Brian, > Thank you and in line... > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Sunday, August 21, 2011 3:21 PM > To: Tina TSOU > Cc: Rémi Després; [email protected]; > [email protected] > Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation > > Hi Tina, > > On 2011-08-21 14:08, Tina TSOU wrote: > ... >> If an average IPv4 user is consuming 200 ports (or whatever >> value you prefer to assume) with their favourite p2p app, that >> is what sets the number of IPv4 users per shared address. It's >> the number of simultaneous ports, not the amount of traffic, >> that counts. >> [Tina: >> These drafts attempt to solve this issue. >> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ > > This doesn't create new ports; it just helps to allocate > them more rationally. > [Tina: When I see your comments about consuming 200 ports, I thought about > the motivation of NAT-COORD is to solve the issue of one iTunes, Google Map > application consumes 200~300 ports at a time. I did not think about > Stateful/Stateless at that time. > > In the use cases you mentioned above, do you only mean static port allocation > issue with stateless mechanisms? Or it can be either stateful or stateless? > > The stateless address sharing schemes (4rd and friends) allocate a port range > to each subscriber statically. Static allocation is necessary for the > mechanism to be stateless. > There are all the advantages of a stateless mechanism (see the motivation > draft for a list of these advantages). > > The problem with static allocation is that it cannot adapt quickly to > subscriber demand. If for example you have one subscriber that is consuming a > lot of ports, you cannot assign more ports to it. Once it's assigned, it's > static and hard to change. > ] > >> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ > > If I understand this correctly, it avoids NAT444 (which is a > good thing, and would make > draft-weil-shared-transition-space-request unnecessary). But > again, it doesn't create new ports or new public IPv4 addresses, > which was my point. > > 4rd and 4via6 share this property of course. > > Brian _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
