Hello QUIC wg,
I am working on the draft to integrate the feedback received here. I
plan to finalise a second version for Prague. The current state of the
text can be consulted on its repository:
https://github.com/mpiraux/draft-piraux-quic-additional-addresses.
The document now specifies a transport parameter to negotiate the use of
a frame. The frame enables the server to advertise additional addresses
at any time during the connection. The document specifies that a client
can use these addresses to reach the server. Use implicitly means that a
QUIC client can migrate to one of these addresses, while an MP-QUIC
client can establish new paths to these addresses.
I also updated the transport parameter ID to reduce possible collisions.
I feel there are two more aspects that need further discussion.
1) What behaviour should we specify for a client using one server
address that no longer appears in a subsequent frame ?
2) Should this list of addresses include the handshake address when it
is still used, i.e. when Preferred Address has not been used ?
The document currently sets the bar low regarding these two questions:
1) The text says the client SHOULD stop using an address that is not
advertised any more in favour of another one.
2) The text specifies that the frame contains only additional addresses
to the handshake address.
Mandating the server to announce all its addresses, including the
handshake address, requires the server to know it. I feel this is not
practical in a number of deployments, e.g., when a server is behind a
NAT. At the same time, not being able to announce this handshake address
in the frame makes the server unable to signal it should not be used any
more. The Preferred Address TP can be used for this purpose right after
the handshake. There might be a gap later in the connection, and I need
more opinions from the wg on whether it needs to be filled in this document.
Maxime Piraux
Le 17/10/22 à 17:29, Maxime Piraux a écrit :
Hello QUIC wg,
We have submitted a document proposing a new QUIC Transport Parameter
for servers to announce additional addresses that can be used in a
QUIC connection.
The proposed mechanism addresses scenarios in which dual-stack and
multihomed servers would like to advertise several server addresses so
that clients can use them to cope with the loss of an address family
and a provider failure. When Multipath QUIC is used over the
connection, this extension can also be used to advertise addresses
towards which additional paths can be established.
The transport parameter is complementary to the use of Preferred
Address and this point is also discussed in the document. We hope the
document will spark interesting discussions and welcome any feedback.
Maxime Piraux
-------- Message transféré --------
Sujet : New Version Notification for
draft-piraux-quic-additional-addresses-00.txt
Date : Fri, 14 Oct 2022 04:55:31 -0700
De : [email protected]
Pour : Maxime Piraux <[email protected]>, Olivier
Bonaventure <[email protected]>, Olivier Bonaventure
<[email protected]>
A new version of I-D, draft-piraux-quic-additional-addresses-00.txt
has been successfully submitted by Maxime Piraux and posted to the
IETF repository.
Name: draft-piraux-quic-additional-addresses
Revision: 00
Title: Additional addresses for QUIC
Document date: 2022-10-14
Group: Individual Submission
Pages: 7
URL:
https://www.ietf.org/archive/id/draft-piraux-quic-additional-addresses-00.txt
Status:
https://datatracker.ietf.org/doc/draft-piraux-quic-additional-addresses/
Html:
https://www.ietf.org/archive/id/draft-piraux-quic-additional-addresses-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-piraux-quic-additional-addresses
Abstract:
This document specifies a QUIC Transport Parameter enabling a QUIC
server to advertise additional addresses that can be used for a QUIC
connection.
The IETF Secretariat
