QUIC, Connection IDs and NAT
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) 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.
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 -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Robert Brockway Sent: May 31, 2021 11:15 PM To: The source of all things networking <nanog@nanog.org> Subject: QUIC, Connection IDs and NAT 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
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 -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Jean St-Laurent via NANOG Sent: June 1, 2021 6:51 AM To: 'The source of all things networking' <nanog@nanog.org> Subject: RE: QUIC, Connection IDs and NAT 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 -----Original Message----- From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Robert Brockway Sent: May 31, 2021 11:15 PM To: The source of all things networking <nanog@nanog.org> Subject: QUIC, Connection IDs and NAT 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
participants (4)
-
George Michaelson -
Jean St-Laurent -
John Levine -
Robert Brockway