QUIC has Connection IDs independent from IP. This was done to make it easier to move from one IP network to another while keeping connections active, as most here will know.
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?
And if so, does this reduce demand on IPv4 resources?
It's ok, I'm wearing a fire-resistant suit with self-contained breathing apparatus as I type this.
Rob
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.
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)
The first thing that comes to mind is to check the NAT timers.
By default, TCP is 86400 seconds or 24h.
Udp is usually shorter at around 300 seconds or 5 minutes.
This is not a standard, but it seems to be broadly accepted in the industry.
I am not sure, if UDP/443 should be left at 300 or increase a bit.
Anyone?
Jean
P.S.: I'm not a fan of Quic. It's opening the gates to massive DDoS for
Akamai and all the others CDN. Good luck
Hey Rob, quick question for you.
Are you able to see the connection ID when you are forwarding the frames and
doing NAT?
I thought this is encrypted. Can you confirm?
Thanks
Jean