4 ms·

Performance. Making every network-element, every hop, have to add something to the routing table is slow. QUIC is either 1 or 0-RTT encryption, depending on if

Performance. Making every network-element, every hop, have to add something to the routing table is slow. QUIC is either 1 or 0-RTT encryption, depending on if there's existing contact (irrc), so I guess we can't argue encryption delays matter much. There's other abstract concerns though- having multiple short-lived connections in your OS and routing tables consumes resources- minimizing resource consumption is a decent goal. I don't know how long the "connection" is expected to remain around. It could be long lived. QUIC is over UDP, and connection becomes more a QUIC concept & pattern of use than otherwise. But I don't see how this is worse than what we do now, which involves an ongoing long dialog with one or two select dns servers. I guess one could say there's some ambiguity at the moment, now, about who exactly a request is coming from, if you allow for NAT, and that starts to go away some here. It may indeed be an ok idea to limit the lifetime of these QUIC connections, but you'd probably need to start taking the 1-RTT latency hit for each new connection to really reap a privacy gain- pretend you had never talked to the server before. The spec notes this[1] & mentions the speed vs privacy trade off. [1] https://www.rfc-editor.org/rfc/rfc9250.html#name-session-resumption-and-0-rt https://www.rfc-editor.org/rfc/rfc9250.html#name-session-res...

phh 4y ago
Uh sorry, what? You say ""your OS"" so I'm guessing you mean an eyeball device. Routing tables (well, it's just knowing which pid bound which socket really) on eyeball devices is pretty much free at the order of magnitude of a standard website where 99.99% of the CPU and RAM is spent in the browser. I don't even understand what kind of resource we would be talking about here? I'm guessing I'm missing something, though I can't see what, could you help me?
fanf2 4y ago
I deployed DNS-over-TLS on Cambridge University’s resolvers in late 2018, and at that time Android already had a superb implementation, that respected the DNS server’s advertised connection idle times, and used TLS session caching to make reconnection faster. IIRC an idle time of about 10 seconds seemed reasonable: long enough to be used for all the DNS requests even from a slow web page, but not so long that the server spends ages keeping state that will never be reused.
- rektide 4y ago
  In general the Privacy Considerations section (7, slightly below what I cited, 5) is quite impressive & well considered. There are pretty strong & conservative recommendations: only use session resumption once, for one example. I have a lot of faith a) these specs have identified the potential issues fairly well, b) they have adequate & good recommendations, c) most implementations will follw these recommendations, and d) the alarm/alert will go up if implemenatations start undercutting significantly on privacy measures. Generally I think there's no present due cause for alarm, at all. Privacy is a real concern & risking it is an acknowledged existential risk that no standards bodies would pave over in todays or tomorrows world.
bogomipz 4y ago
>"There's other abstract concerns though- having multiple short-lived connections in your OS and routing tables consumes resources- minimizing resource consumption is a decent goal." I'm not understanding this. Your OS's network stack would just see these destinations as not being part of the local network and send these UDP packets to the configured default route. Why would there be a need to create a route?
mhio 4y ago
> Making every network-element, every hop, have to add something to the routing table is slow How do you see the QUIC stream layout relating to routing cost? It's been a few years since I've done larger scale networking but I wouldn't say IP routing changes much between protocols. Router see's destination IP bytes, matches destination IP to network route in table, forwards packet. 10 UDP, TCP or QUIC UDP packets in any stream arrangement are unlikely to route differently or to add/remove cost (in a contrived example ignoring QUIC or TCP protocol overhead). Most "middle" hops are just pushing the packet, at least until you are hitting an AS that controls the endpoint of a connection. Are you referring to hops where application level decisions are being made? Towards each end of a packets route there may be hops to NAT, QoS, L4 routers or firewalls that will try to reconstruct packets into logical sessions where there's a memory/lookup overhead and usually rules applied to the packet. This is likely to decide where the packet ends up but that's not slow and I don't believe QUIC connections are a fundamental leap in this type of tracking over TCP src/dst 4 tuples, apart from the observability improvements the additional quic headers add onto basic src/dst rules.

phh 4y ago

Uh sorry, what? You say ""your OS"" so I'm guessing you mean an eyeball device. Routing tables (well, it's just knowing which pid bound which socket really) on eyeball devices is pretty much free at the order of magnitude of a standard website where 99.99% of the CPU and RAM is spent in the browser. I don't even understand what kind of resource we would be talking about here? I'm guessing I'm missing something, though I can't see what, could you help me?

fanf2 4y ago

I deployed DNS-over-TLS on Cambridge University’s resolvers in late 2018, and at that time Android already had a superb implementation, that respected the DNS server’s advertised connection idle times, and used TLS session caching to make reconnection faster. IIRC an idle time of about 10 seconds seemed reasonable: long enough to be used for all the DNS requests even from a slow web page, but not so long that the server spends ages keeping state that will never be reused.

rektide 4y ago
In general the Privacy Considerations section (7, slightly below what I cited, 5) is quite impressive & well considered. There are pretty strong & conservative recommendations: only use session resumption once, for one example. I have a lot of faith a) these specs have identified the potential issues fairly well, b) they have adequate & good recommendations, c) most implementations will follw these recommendations, and d) the alarm/alert will go up if implemenatations start undercutting significantly on privacy measures. Generally I think there's no present due cause for alarm, at all. Privacy is a real concern & risking it is an acknowledged existential risk that no standards bodies would pave over in todays or tomorrows world.

bogomipz 4y ago

>"There's other abstract concerns though- having multiple short-lived connections in your OS and routing tables consumes resources- minimizing resource consumption is a decent goal." I'm not understanding this. Your OS's network stack would just see these destinations as not being part of the local network and send these UDP packets to the configured default route. Why would there be a need to create a route?

mhio 4y ago

> Making every network-element, every hop, have to add something to the routing table is slow How do you see the QUIC stream layout relating to routing cost? It's been a few years since I've done larger scale networking but I wouldn't say IP routing changes much between protocols. Router see's destination IP bytes, matches destination IP to network route in table, forwards packet. 10 UDP, TCP or QUIC UDP packets in any stream arrangement are unlikely to route differently or to add/remove cost (in a contrived example ignoring QUIC or TCP protocol overhead). Most "middle" hops are just pushing the packet, at least until you are hitting an AS that controls the endpoint of a connection. Are you referring to hops where application level decisions are being made? Towards each end of a packets route there may be hops to NAT, QoS, L4 routers or firewalls that will try to reconstruct packets into logical sessions where there's a memory/lookup overhead and usually rules applied to the packet. This is likely to decide where the packet ends up but that's not slow and I don't believe QUIC connections are a fundamental leap in this type of tracking over TCP src/dst 4 tuples, apart from the observability improvements the additional quic headers add onto basic src/dst rules.