Re: Fwd: New Version Notification for draft-piraux-quic-additional-addresses-00.txt

[Maxime Piraux <[e-mail]>]

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 :     [e-mail]
> Pour :     Maxime Piraux <[e-mail]>, Olivier 
> Bonaventure <[e-mail]>, Olivier Bonaventure 
> <[e-mail]>
>
>
>
>
> 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
>
>