On 12/14/2020 2:38 AM, Mikkel Fahnøe Jørgensen wrote:
Sorry, “async design “ should read asymmetric design, in that only one
endpoint can create multiple paths, as opposed to a symmetric design
where both can.
On 14 December 2020 at 11.33.46, Mikkel Fahnøe Jørgensen
([email protected] <mailto:[email protected]>) wrote:
async design
The proposal indeed keeps the asymmetric design of QUIC v1. That design
is grounded in practical realities, such as the prevalence of NAT and
stateful firewalls that would drop "unexpected" packets sent to a
client. Also, the client typically knows about the cost of paths better
than the server, for example whether sending more data on a given path
will generate larger invoices from the provider. The design goal is to
let the client express these preference to the server using a simple
priority scheme.
Anything more complex probably requires application level decisions.
That why the design provides the QOE frame. That frame let applications
exchange information about paths in an application specific way. The
expectation is that the application posts them as it sees fit, and the
transport delivers them as they are received. The application then uses
locally provided API to affect the way data is sent over multiple paths.
We could debate whether the QOE frame is needed at all. Applications
could also exchange the data as part of application protocol itself. I
think that having a separate frame reduce the overall complexity, by
separating application specific path control from the application
protocol itself.
We could also debate whether the QOE frame should be specified in
greater details. The current design simply passes a byte string. The DNS
SVCB RR type addresses a related problem by an SvcParams field that
contains a list of key-value pairs. It is possible that having a similar
list of key-value pairs would be useful there. On the other hand, we do
not yet have a lot of experience. And open design with a byte string is
probably good enough for now.
-- Christian Huitema
