Comment by commandersaki
Comment by commandersaki 10 months ago
What is the latency or bandwidth bottleneck in nat v4?
Comment by commandersaki 10 months ago
What is the latency or bandwidth bottleneck in nat v4?
NAT registers in the microseconds for packet processing time, that isn’t even comparable to Internet path jitter.
> NAT registers in the microseconds for packet processing time, that isn’t even comparable to Internet path jitter.
NAT, at scale, can get expensive:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
Okay, but back to the original question, how does this affect latency or bandwidth?
Its the $$ cost of big nat hardware, compared with dumber routers
If someone is torrenting behind the NAT you can get exhaustions
You'd be looking at having on upwards of 10k (probably much more) peers to even come close to exhaustion.
No, I mean that the IPv4 packets go through a stateful NAT engine on the provider side, instead of going through potentially multi-path L2/L3 switching fabrics that are stateless w.r.t. the content of the packets (especially if they're actually routed L3 fabrics, not auto-discovering L2 fabrics).
Thus the packets have to take a detour through the NAT engine instead of taking the shortest physical path to the destination as they can with a plain stateless L3 switched fabric. E.g. in an AON with L2/L3 switches on the provider side of the last-mile link, you can easily bend the packets right around in that switch if you're WebRTC calling your neighbor. No need to even go beyond the curbside switch.
Other than that, it's still typically gonna be a physical detour to the NAT engine instead of going straight to the destination, as the NAT engine isn't fused into the main fabric data plane.
Your typical router shouldn't fill up its port mapping table. In fact, the 4th layer isn't involved at all so "ports" don't even exist as a concept.
Sure but none of this poses a latency or bandwidth bottleneck.
Taking the detour to the NAT.