huitema / dnsoquic

DNS over QUIC
10 stars 7 forks source link

"Design for minimum latency" section is inaccurate and should be minimized #79

Closed mjoras closed 3 years ago

mjoras commented 3 years ago

The most obvious issue I assume was a simple mistake:

Support for advanced error recovery procedures as specified in "QUIC Loss Detection and Congestion Control"

Surely "error recovery" should be "loss recovery" since losses aren't really "errors" in the common sense of the word. I also don't really see how this part of QUIC is relevant to a DNS over QUIC mapping.

I also don't see why this section mentions HTTP and "latency" at all. QUIC was indeed designed in lockstep and by those with a particular interest in HTTP, but the section seems to imply it was designed for HTTP in particular, which isn't true and doesn't seem very relevant to a DNS mapping.

To me it seems like there are two relevant things for a DNS over QUIC mapping worth calling out here: 0RTT and multiple independent streams. The former is relevant because it's very useful to minimize latency for DNS queries. The latter is relevant because QUIC provides an application semantic for multiplexing queries over a single connection.

huitema commented 3 years ago

Yes, this should be "loss recovery". Easy fix.

You are right that we do not really need to mention HTTP. How about replacing:

QUIC is specifically designed to reduce the delay between HTTP
queries and HTTP responses.  This is achieved through three main
components:

By:

QUIC is specifically designed to reduce protocol-induced delays.  This is achieved through three main
components:
huitema commented 3 years ago

PR #86 addresses the comment "error recovery" should be "loss recovery"

huitema commented 3 years ago

@mjoras can you take a look at PR #107?

huitema commented 3 years ago

I think this is addressed by recent PR #86 and #107. @mjoras please reopen if resolution is not adequate.