From nobody Mon Oct 17 08:52:40 2022 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3513C15271C for ; Mon, 17 Oct 2022 08:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWGd7tM4XYJu for ; Mon, 17 Oct 2022 08:52:35 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A276C15271B for ; Mon, 17 Oct 2022 08:52:35 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id q19so16675905edd.10 for ; Mon, 17 Oct 2022 08:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GcK4CDN7G89+5mxU2q4nwEtFBRu2VN3D4R5OzRphgq4=; b=GLXIPbaq6oU0IajlArltteZfuM0ZmuFUrqUmc1sy7R0jkxU5sPRnAq4rNCP3x3js+v MmszI46mNzyCYL1WUlbxRpBYZzOhzg0kLIrSyoXUSWM2vwLflE55Fslgnfb2ebZ+mAFM IvxeJ7EMD6Bt3/fcubDikDGXOdjhE5NPZJFwzQEPyfE6+nfOSSggkFNDG+WRsbnw4NPI C9eu4oDsBxYc8k5YtZmOvM/mj7/IKp7HGqaWQFE+K2ZnP1nVmZ4uI/0uOY2qyNO6hTMg xBmTRTdDmjXyt0CuPQyzEsdonGeuZ8+cFIpqQR144rj1Hkk2vugo7oYt5BuBtF+54mdI AkoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GcK4CDN7G89+5mxU2q4nwEtFBRu2VN3D4R5OzRphgq4=; b=JFiHPvBY2eObCzSxHwThCfSpqKRHqWIAL4jwMGkX16BYI43pj7lx/q5PuF17TNNdOv xfkjatOPVrK8KKbQuizAe8+bfvjuNfxx4adwtThkYwmIFQ5wbvYxRVE+e3u6mk/6cOGr WyZ/dvqCDzfC0RnZGkRdSQFzytiFDm+FgquYIrz7LIkreWFNf7+GFOfegCfK3B0dYvC4 MLD6JqW+BXp05bKFhAiZzTcpL/73W5pE3wKeRCNE/bQfjpnZfiIaro3sKmMtUsH+UnFx hMkwYS0yiz2oTs9m9RfymtM0QsUltG2IahXPCqKuIY++hiAA6Sm3GIh8tPAoG3Le/ndP WgwQ== X-Gm-Message-State: ACrzQf1w6DvCJ1DEVN3pHBu6OlGjIiLJI5eZnDNwfXP6g1luIC/Nm1mL 2OrA0yyXnAOxT1Wt9n8voMC9EXLwNaw4cnJ9EflivJBp X-Google-Smtp-Source: AMsMyM4OxDlhQeiIfgoQuQ+ZQ37xpjGoRGhRBSDNU90LbvKasKvHAwo8wsvbwqWAn3SaqRupwdHRW0F6L2Nwkj95Qgs= X-Received: by 2002:a05:6402:5212:b0:45c:c37d:4be2 with SMTP id s18-20020a056402521200b0045cc37d4be2mr10841215edd.31.1666021952824; Mon, 17 Oct 2022 08:52:32 -0700 (PDT) MIME-Version: 1.0 References: <166574853172.8972.17114215374822825173@ietfa.amsl.com> <9612bc63-26c8-fc46-edd3-6aaf712a26c3@uclouvain.be> In-Reply-To: <9612bc63-26c8-fc46-edd3-6aaf712a26c3@uclouvain.be> From: Marten Seemann Date: Mon, 17 Oct 2022 16:52:21 +0100 Message-ID: Subject: Re: New Version Notification for draft-piraux-quic-additional-addresses-00.txt To: Maxime Piraux Cc: Olivier Bonaventure , QUIC WG Content-Type: multipart/alternative; boundary="000000000000afaf6005eb3cf6ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2022 15:52:38 -0000 --000000000000afaf6005eb3cf6ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the draft. I was wondering if this should be a QUIC frame instead of a transport parameter. A frame would make this more interesting for the more general case where the set of addresses of a node is not static. Take for example a QUIC connection between two mobile devices (where interfaces / path can come up / go down), or for servers located behind NATs / firewalls (which might need some time to discover their public addresses). On Mon 17. Oct 2022 at 16:30, Maxime Piraux wrote: > 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 th= at > 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 additiona= l > 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 wi= ll > spark interesting discussions and welcome any feedback. > > Maxime Piraux > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : New Version Notification for > draft-piraux-quic-additional-addresses-00.txt > Date : Fri, 14 Oct 2022 04:55:31 -0700 > De : internet-drafts@ietf.org > Pour : Maxime Piraux > , Olivier Bonaventure > , > Olivier Bonaventure > > > > 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-addres= ses > > > 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 > > > --000000000000afaf6005eb3cf6ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the draft. I was wondering if this should b= e a QUIC frame instead of a transport parameter.
A frame would make this more interesting for the m= ore general case where the set of addresses of a node is not static. Take f= or example a QUIC connection between two mobile devices (where interfaces /= path can come up / go down), or for servers located behind NATs / firewall= s (which might need some time to discover their public addresses).


On Mon 17. Oct 2022 at 16:3= 0, Maxime Piraux <maxime.p= iraux@uclouvain.be> wrote:
=20

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=C3=A9r=C3=A9 --------
Sujet=C2=A0: New Version Notification for draft-piraux-quic-additional-addresses-00.txt
Date=C2=A0: Fri, 14 Oct 2022 04:55:31 -0700
De=C2=A0: internet-drafts@ietf.org
Pour=C2=A0: Maxime Piraux <maxime.piraux@uclouvain.be>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, Olivier Bonaventure <olivier.bonaventure@uclouvain.be>



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-pira= ux-quic-additional-addresses-00.txt
Status: https://datatracker.ietf.org/doc/draft-pi= raux-quic-additional-addresses/
Html: https://www.ietf.org/archive/id/draft-pir= aux-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


--000000000000afaf6005eb3cf6ba--