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 912241202A0 for ; Sun, 15 Sep 2019 23:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0zxwE2o6ich for ; Sun, 15 Sep 2019 23:07:03 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066CB1200FD for ; Sun, 15 Sep 2019 23:07:03 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id p2so30754826edx.11 for ; Sun, 15 Sep 2019 23:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=mLvOu4SEJ788lc+m92Zrza6zpABvf5rCekq+o8gPHH4=; b=ohxo1QqcS++373lJGQDx27lDNYtTALskFZcUTFRD0Ucv2rbWq9WM2OBZru1Bi/7v2/ Tj5Nzo2z9xmmXHoaWXINPPKMVv1JzxucI8qipUQz3bNqe9wREl26x9MaOAoqGmcEgrhD D9WJujZpcLuSehMGGAZoPJGsYXw3XsDL6oxnWm8MeT5f1qsSyO1Ob6p9liBdYtdQQ9ql P9n4TlLNFdfx4oyk9quW8duSxbPUce1Xy2Wax0tGnb/SYuUamnvxHtSOiBvUG7DZxFGs c3i8USLAYeRVBviTqe+3I5mPesk4JlPGGELoCtn42UAEUBDnX7pkUpgLz3pkHzEkhbOJ Um5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=mLvOu4SEJ788lc+m92Zrza6zpABvf5rCekq+o8gPHH4=; b=OFoZsnldE02RM8/aqvoR+eJmVxfC/eQQXE59edX7M/md56AHS2y/SEq6U9VO+uyTUs UTqWN9DNKZS7VODBO2zgASV1Gp/eZZyN2JFsiPnwdvpPUD/99nY/+zo58MoeE+T2Dh5J NIOa2yVi4yWUlyPWVqNUmKEI+Fh14v1m9/QepVqWq2/3mgqPQI9B8+af9nN/AIxQHtTg lG86QeXWukuv/x301OD1HjD9sFRNss2lRDLRPmwwUT8OMLYKqn7e+2P4+viDmY+n6DET GISO0m0L6YbOqllK9gAJONnPbg/leLY20rtamm0KJz0lJDhqfg2TOoWIoWwOln8L208x f5ug== X-Gm-Message-State: APjAAAX2iXFCTHdpJSrUgB4gDv5YrAIoz/KJVb4JQirEgvCamYa7EMF4 Hg4V6mfYLb4aKQXFEXoEWjKtg70Ynm4L7Vvm/TKp2g== X-Google-Smtp-Source: APXvYqzJwrN2RQ2kbFw5L0xZgoOumUU6hVHh5PKULqxGifkI6uXMrPE3BVtK35wOwipzS15HiFu1d0bfP9Vx07Etvo4= X-Received: by 2002:a17:906:4a19:: with SMTP id w25mr50559271eju.239.1568614021518; Sun, 15 Sep 2019 23:07:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 15 Sep 2019 23:07:00 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 15 Sep 2019 23:07:00 -0700 Message-ID: Subject: Re: preferred_address outside of handshake To: Luke Curley , quic@ietf.org Content-Type: multipart/alternative; boundary="0000000000008adabc0592a5690b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 16 Sep 2019 06:07:05 -0000 --0000000000008adabc0592a5690b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This lands under migration. It was deliberate choice to only allow clients to migrate in QUIC v1 to avoid excessive complexity and because the most common use case are mobile clients connecting to stationary servers. There is an inherent feed-back problem in allow both to migrate. Even seeming simple problems such as allowing both peers to change encryption keys has caused at lot of design discussions and change. QUIC v2 will likely explore multi-path connections and server migration. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 16 September 2019 at 08.02.05, Luke Curley (kixelated@gmail.com) wrote: Hey guys, I've spent the last few days reading the QUIC spec and it's amazing. One thing I love is preferred_address as it gives the server the ability to redirect traffic from an anycast address to a unicast address (among other uses). This would obsolete DNS load balancing in many cases! However, it's only possible to use preferred_address during the handshake. If there was a frame that behaved the same way, then it would be possible to migrate traffic to another address. This would be extremely useful; you could migrate to another port for graceful restarts or another IP address (including anycast!) to drain the entire host. This is almost possible today as the new server can send packets (from a new address) and cause the client to initiate a PATH_CHALLENGE. However, this won't always work when the client is behind a NATs. What you really need is the client to punch a hole in the NAT by explicitly telling the client when to initiate a PATH_CHALLENGE. What about something like PATH_CHALLENGE_REQUEST, containing similar information as preferred_address? I even think this frame should replace preferred_address as it's not a critical handshake parameter. Thanks! --0000000000008adabc0592a5690b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = This lands under mig= ration.

<= /div>
It was delibe= rate choice to only allow clients to migrate in QUIC v1 to avoid excessive = complexity and because the most common use case are mobile clients connecti= ng to stationary servers.

There is an inherent feed-back problem in allow both to migrate. Even = seeming simple problems such as allowing both peers to change encryption ke= ys has caused at lot of design discussions and change.

QUIC v2 will likely explore multi-path co= nnections and server migration.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


=

On 16 September 2019 at 08.02.05, Luke Curley (kixelated@gmail.com) wrote:

Hey guys,

I've spent the last few days reading the QUIC spec and it's amazing. One thing I love is=C2=A0preferred_address as it=C2=A0gives the=C2=A0server the ability to redirect traffic from an anycast address to a unicast address (among other uses). This would obsolete DNS load balancing in many cases!

However, it's only possible to use=C2=A0preferred_address=C2=A0duri= ng the handshake. If there was a frame that behaved the same way, then it would be possible to migrate traffic to another address. This would be extremely useful; you could migrate to another port for graceful restarts or another IP address (including anycast!) to drain the entire host.

This is almost possible today as the new server can send packets (from a new address) and cause the client to initiate a PATH_CHALLENGE. However, this won't always work when the client is behind a NATs. What you really need is the client to punch a hole in the NAT by explicitly telling the client when to initiate a=C2=A0PATH_CHALLENGE.

What about something like=C2=A0PATH_CHALLENGE_REQUEST,=C2=A0containing similar information as preferred_address? I even think this frame should replace=C2=A0preferred_address=C2=A0as it's not a critical handshake parameter.


Thanks!
 --0000000000008adabc0592a5690b--