That's a laughable low limit. Even the "pro" plan would be marginal for a single person without running into limits from time to time. And nevermind power users that might do something with p2p or have a couple more devices connected to the network.

But that's besides the point. Your home router can easily have millions of connections open (if they didn't skimp on the ram anyway), but if you have CGNAT boxes that do the same for tens of thousands of customers you also have to take into account that they have to move a lot of traffic. This means routing and doing NAT in software won't cut it anymore, but you need dedicated hardware coupled with very fast specialized memory to handle that traffic.

You can still do hardware NAT for the few thousand connections with the most packets and software NAT for everything else.

I bet across even an ISP network of a million users, 80% of the traffic at any point in time is within 10,000 connections.

You do realise that almost all connections are long-lived, and burst up and down in throughput? So the 10,000 “heaviest” connections right now are not the same as in, say, 3 seconds from now ?

So you propose constantly swapping in and out connections from “hardware NAT” to “software NAT”? What heuristic will you use to decide which connections go where?

Such a heuristic will probably look a lot like QoS, which is even more (much more!) resource hungry than NAT.

At which point will the obvious conclusion be, “maybe the carriers who actually deal with these problems have a point, NAT is indeed a significant amount of complexity, and let’s be happy IPv6 starts to make actual economic sense?”

How do you ensure each user is capped at 100 connections without that check incurring additional resources?

You have a per user counter. So instead of 1200 bytes it's 1201 bytes per user.

Memory isn’t the only dimension we care about.

You’ve basically proposed an absolutely horrible solution, for both the end-user and the ISP. Something tells me you haven’t actually done any actual low level network engineering, and just brush all this off as “how hard can it be”.

how are you going to keep this counter? Do you identify the bytes that are processed in individual flows? Which system will keep track of this? the control plane of the router maybe? great... you just added additional complexity instead of just pushing packets through a forwarding plane.

When an unrecognized flow shows up, punt it to software. Handle the counter there, and if it overflows then you drop the packets. No need to add anything to the control plane.

"punting it to software" from a router with seperate control and forwarding planes perspective, is forwarding it to a control plane, instead of relying on the logic programmed inside the ASIC to forward traffic.

Sorry, I meant no need to add anything to the forwarding plane, or interfere with its efficiency at all.

The point is, the really fast part doesn't need to be more complex.

The part that handles new connections needs to be marginally more complicated, but not enough that it should really matter.

Please don’t give Comcast ideas