Closed mjoras closed 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:
PR #86 addresses the comment "error recovery" should be "loss recovery"
@mjoras can you take a look at PR #107?
I think this is addressed by recent PR #86 and #107. @mjoras please reopen if resolution is not adequate.
The most obvious issue I assume was a simple mistake:
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.