the 5tuple includes protocol so increased adoption of QUIC alongside TCP bound services effectively does increase the potential size of the NAT binding table but if we're really a single-browser model and all going to QUIC enabled webs, the effective outcome is to burn the port space in UDP, not in TCP. its same-same if everyone jumps ship. On the plus side, QUIC is a session: it multiplexes. So for a given endpoint, there might only be one long-held QUIC binding. Sure, TCP HTTPS in principle did this, but most of the code appeared to open multiple simultaneous TCP connections. I am less sure this is happening with the QUIC stack as presented. Maybe somebody smarter can say. the real problem is not the port count, its the amount of buffer space the tiny chip has set aside, to hold "open" bindings in. We're revisiting 1980s kernels and the TCB and ways to flush it, at this point. By now, manufacturers should be making home routers out of devices which have more memory purely for connection holding, than prior devices had overall to boot a kernel in. But, consumers hold on to WRT54G forever. (I'm old. this may be a bad take on history, and current technology) On Tue, Jun 1, 2021 at 1:52 PM John Levine <johnl@iecc.com> wrote:
It appears that Robert Brockway <robert@timetraveller.org> said:
Does the existence of Connection IDs separate from IP mean that the host/IP contention ratio in CGNAT can be higher? IE, can a single CGNAT device provide Internet access for a greater number of end-users?
No, QUIC runs over UDP which runs over IP. QUIC replaces the TCP sessions that a web browser uses but the device is still doing all of the other IP stuff that it does.
I could imagine that the connection ID might slightly increase the load on a NAT since a device might be hopping back and forth between networks, e.g. mobile and wifi, and be considered a new NAT client each time it does.