AWS to start charging for IPv4 addresses.

[animats]

AWS to start charging for IPv4 addresses.

Each SL region needs its own IP address. SL does not support IPv6 yet.

27722 regions at US$43.8/year = US$1,214,223/yr.

 

 

[Ardy Lay]

2 hours ago, animats said:

AWS to start charging for IPv4 addresses.

Each SL region needs its own IP address. SL does not support IPv6 yet.

27722 regions at US$43.8/year = US$1,214,223/yr.

 

 

See BYOIPv4.  Maybe Linden Lab has some?  Oh, looks like LL was using addresses belonging to Level 3 and Metronet.  Ow.

[AmeliaJ08]

Expensive!

There was me in the early 00's thinking I'd have needed to wrap my head around ipv6 by now but it never really seemed to happen. Maybe it never really will for plebs like me but I'm sure eventually something like SL will have to use it, can't see how it's worth paying that much for IP addresses when there's an alternative.

 

[Kathrine Jansma]

Sadly there are still stupid ISPs that only offer IPv4 access (mine for example 😞 ). So going IPv6 only is still not a good option for all cases.

IPv6 has a whole list of changes but for most simple uses adapting code to do IPv6 is mostly trivial. The tricky parts come in when you try to do dualstack IPv4/IPv6 and stuff like "happy eyeballs" to try parallel connections via IPv4 & IPv6 and use the quicker one.

The other stuff is on the routing and DNS layer but not really interesting to simple client applications. So if the regions used IPv6, I'm sure that viewers would have no real trouble adapting to that. But getting all user to IPv6 is more of a problem. 

[Zalificent Corvinus]

Breaking News: Overpriced Cloudcrap Service Supplier plans to charge for Overpriced Cloudcrap Service.

Pictures at 11!

 

$44 a year for an IPV$ is a DROP IN THE OCEAN compared to what LL are already paying for 27,000 plus regions worth of cloudcrap. If it bothers them to any degree, they will just hike MP saless tax, and Lindex Transaction charges again.

/thread

[Love Zhaoying]

These charges - and any future charges by AWS is a risk LL took when migrating to AWS from their own data centers. I didn't see anyone mention it yet, but "obviously" LL "should" be paying less overall with AWS, or they would not have made the migration (unless other tangible benefits like scalability make up for it).

[Henri Beauchamp]

8 hours ago, Love Zhaoying said:

These charges - and any future charges by AWS is a risk LL took when migrating to AWS from their own data centers. I didn't see anyone mention it yet, but ”obviously” LL ”should” be paying less overall with AWS, or they would not have made the migration (unless other tangible benefits like scalability make up for it).

+1 for the risks they took. Sadly, we also share those risks as users (costs are reflected in the fees we pay, technical risks in the service quality, plus the viability of SL itself).

As for the ”benefits” of the migration, I would bet they are regretting their decision now, and that it is not a benefit at all in terms of costs.

I personally think the AWS migration was a mistake: loss in autonomy, competences, infrastructure specification choices (agility and adaptation to future needs). But of course, it is just my opinion.

15 hours ago, Kathrine Jansma said:

Sadly there are still stupid ISPs that only offer IPv4 access (mine for example 😞 ). So going IPv6 only is still not a good option for all cases.

My ISP offers IPv6; in fact, this is the other way around: they use IPv6 by default and offer IPv4 over IPv6, with also optional static IPv4 (at least for now). However I am still using IPv4 only on my local network and blocking IPv6 traffic, the reason being:

15 hours ago, Kathrine Jansma said:

The tricky parts come in when you try to do dualstack IPv4/IPv6

Indeed quite tricky, especially when you want to secure properly your local network (not to mention I still have antediluvian computers on this network, that cannot even ”speak” IPv6).

15 hours ago, Kathrine Jansma said:

But getting all user to IPv6 is more of a problem.

I would say it is Mission: impossible for now, and probably one or two more decades...

Edited August 6, 2023 by Henri Beauchamp

[Kathrine Jansma]

7 hours ago, Love Zhaoying said:

These charges - and any future charges by AWS is a risk LL took when migrating to AWS from their own data centers. I didn't see anyone mention it yet, but "obviously" LL "should" be paying less overall with AWS, or they would not have made the migration (unless other tangible benefits like scalability make up for it).

Cloud like AWS is always more expensive for "always-on" servers, when you do not need the dynamic scaling or other services.

But you gain a few nice things that may or may not be worth it.

• A different allocation of money, you do not need to sink a lot of money into operating a datacenter and estimate your growth for proper sizing. So you can save on taking on debt for the investment.
• Flexibility to experiment with technologies, for example the new even regions
• Commodity infrastructure options you could use to replace your aging home grown systems with 
• Theoretical options to geo-distribute your regions
• Easier rampup / hiring of admins 
• etc.

I'm not sure if LL regrets the move to the AWS system. But i am pretty sure they have not yet used all the useful opportunities they could get from the infrastructure, so currently it feels is a little worse for some systems.

 

[Henri Beauchamp]

34 minutes ago, Kathrine Jansma said:

• A different allocation of money, you do not need to sink a lot of money into operating a datacenter and estimate your growth for proper sizing.

.../...

• Commodity infrastructure options you could use to replace your aging home grown systems with

Drawbacks: loss of in-house competency, ”big bucks” paid for this, relative and short term, ”advantage”.

35 minutes ago, Kathrine Jansma said:

• Flexibility to experiment with technologies, for example the new even regions

Can do exactly the same with an in-house infrastructure, with even more agility/reactivity... Not a valid argument, at all, I'm afraid.

36 minutes ago, Kathrine Jansma said:

• Commodity infrastructure options you could use to replace your aging home grown systems with 

Yes, and this is likely what LL considered as the biggest advantage... But it also comes at a cost, which is far from negligible and, on the long term, may be not that advantageous compared with an in-house solution... It may however help spreading the costs and avoid investments ”spikes” (but a competent manager could instead anticipate these by sparing money and placing it on a separate investment account).

42 minutes ago, Kathrine Jansma said:

Theoretical options to geo-distribute your regions

All the more theoretical since LL is not even using it (not really suitable to run sim servers anyway)...

43 minutes ago, Kathrine Jansma said:

Easier rampup / hiring of admins 

As an entrepreneur, I'd prefer finding it ”hard” to hire good admins, but in exchange gain a strong team of very competent and dedicated admins, rather than have to deal with third party admins and explain them again and again that, no, SL is not just about HTTP, and no, its not a web service, and yes, it got very specific and even unique needs and requirements, and please, hurry up !...

 

Just my two cents (which is pretty cheap, compared with AWS rates)... 😛

[Love Zhaoying]

2 hours ago, Henri Beauchamp said:

+1 for the risks they took. Sadly, we also share those risks as users (costs are reflected in the fees we pay, technical risks in the service quality, plus the viability of SL itself).

As for the ”benefits” of the migration, I would bet they are regretting their decision now, and that it is not a benefit at all in terms of costs.

Unpopular opinion: IPv6 is inevitable. So, any associated activities with a move to IPv6 (including foreseen and/or unforeseen costs) are inevitable.

[Henri Beauchamp]

12 minutes ago, Love Zhaoying said:

Unpopular opinion: IPv6 is inevitable. So, any associated activities with a move to IPv6 (including foreseen and/or unforeseen costs) are inevitable.

Inevitable or not, popular or not, it is, for now, impossible to migrate to an IPv6 only service for any public facing Internet service: the end users are just not yet all able to deal with IPv6, and it would cause the said service to loose an enormous amount of users... Things will change when, say, 95% of end users will be able to do IPv6 (then the pressure on the remaining 5% will be so high that they won't have another choice than to migrate their hardware to IPv6).

Note that, in the mean time, and to avoid AWS IPv4 fees, LL could perfectly route all the AWS servers IPv6 traffic via their own, in-house router with IPv4 public facing interface. Then they could manage their own IPv4 block at lower costs.

Of course, it means adding a bottleneck for the sims traffic, but since the latter got lower over years (with migration to CDN servers for textures, meshes and inventory assets, which was a Good(TM) move, unlike the AWS one), this might not be too much of an issue... To mitigate this bottleneck, LL could also add IPv6 support to the viewer, and then users able to do IPv6 would directly connect to the AWS servers, while the rest would go through LL's ”private” IPv4 router.

Edited August 6, 2023 by Henri Beauchamp

[animats]

7 hours ago, Henri Beauchamp said:

Inevitable or not, popular or not, it is, for now, impossible to migrate to an IPv6 only service for any public facing Internet service: the end users are just not yet all able to deal with IPv6, and it would cause the said service to loose an enormous amount of users... Things will change when, say, 95% of end users will be able to do IPv6 (then the pressure on the remaining 5% will be so high that they won't have another choice than to migrate their hardware to IPv6).

Note that, in the mean time, and to avoid AWS IPv4 fees, LL could perfectly route all the AWS servers IPv6 traffic via their own, in-house router with IPv4 public facing interface. Then they could manage their own IPv4 block at lower costs.

Of course, it means adding a bottleneck for the sims traffic, but since the latter got lower over years (with migration to CDN servers for textures, meshes and inventory assets, which was a Good(TM) move, unlike the AWS one), this might not be too much of an issue... To mitigate this bottleneck, LL could also add IPv6 support to the viewer, and then users able to do IPv6 would directly connect to the AWS servers, while the rest would go through LL's ”private” IPv4 router.

What complicates this is how region servers tell the viewer about adjacent regions. At login, the login server tells the viewer the IPv4 address and port number of the initial region over an HTTP connection. After that, whatever region you're in tells the viewer about nearby regions. That's done by sending an IPv4 address and a 2-byte port number. The viewer then connects and starts talking.

LL seems to have done some prep work for conversion to IPv6. Some of the UDP messages still have 4-byte IP addresses in them.  Search that file for "IPADDR". But almost all the messages with an IPADDR do not go out to the viewer, or were listed as "deprecated" or "blacklisted" long ago. The main messages that still have an IPADDR are SimulatorPresentAtLocation and KickUser. That's low-bandwidth data and could be moved to the HTTP event poll channel and sent in LSL, which allows variable length binary fields. It looks like about six years ago someone started on IPv6 conversion, but the job wasn't finished.

[Henri Beauchamp]

3 hours ago, animats said:

What complicates this is how region servers tell the viewer about adjacent regions.

Not really an issue. Given IPv6 connections would be incompatible with old viewers, all LL needs is to add a new UDP message conveying the IPv6 address, sent in excess to the one containing the IPv4. The updated viewers will then pick up whatever works for the network they are connected to, while old viewers would still get the IPv4.

Edited August 7, 2023 by Henri Beauchamp

[Gabriele Graves]

Here in New Zealand, we have a couple of ISPs that provide IPV6 but the majority have gone behind CGNAT (Carrier-Grade NAT) with IPV4 addresses now and that's what the majority of people here are using.  There's no plan to get everyone onto IPV6 at all and nothing to suggest that those ISPs will change from IPV4 anytime in even the long term.

The main issue seems to be that nobody knows how to migrate the less technical customers over in a seamless way without making some of their devices unusable.

[Paul Hexem]

On 8/6/2023 at 4:29 PM, animats said:

It looks like about six years ago someone started on IPv6 conversion, but the job wasn't finished.

Linden Lab started something and then didn't finish?! I'm shocked! Shocked, I tell you!

[Extrude Ragu]

Maybe a hybrid approach would suit LL better, in retrospective.

Ie. the majority of what resources LL use today in their own data center, and use AWS for quick growth space.