QUIC, Connection IDs and NAT

Tue Jun 1 03:58:31 UTC 2021

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 at iecc.com> wrote:
>
> It appears that Robert Brockway <robert at 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.
>