IETF Logo Mail Archive

Re: [quicwg/base-drafts] Connection migration optional? (#1271)

Praveen Balasubramanian <notifications@github.com> Mon, 09 April 2018 15:59 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63D312D0C3 for <quic-issues@ietfa.amsl.com>; Mon, 9 Apr 2018 08:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 tSB_GxB6U7nW for <quic-issues@ietfa.amsl.com>; Mon, 9 Apr 2018 08:59:04 -0700 (PDT)
Received: from o3.sgmail.github.com (o3.sgmail.github.com [192.254.112.98]) (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 1141812025C for <quic-issues@ietf.org>; Mon, 9 Apr 2018 08:59:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=PkAWFyRpuZp46ZN2n+y6eluVpIY=; b=es7305gGmW8Mt9w0 D7TePn5u++NCILSOjNBTz0Rr9kg9KwlNtZJCpLZRP40nQ/TKdqeIpOYmXMKlR7nY 64dJQumQKC62QL+sbmdtPohS8JRt9gtRdV+WkAXRqQ/NqGWKh3EndweOpk7Q/Ynn DYyXiqOpqy3hnHo34L+psFj1J5I=
Received: by filter0461p1las1.sendgrid.net with SMTP id filter0461p1las1-24594-5ACB8DA6-2C 2018-04-09 15:58:30.830220859 +0000 UTC
Received: from smtp.github.com (out-2.smtp.github.com [192.30.252.193]) by ismtpd0001p1iad2.sendgrid.net (SG) with ESMTP id jOG5gyJzTHG72vlMEn9Vwg for <quic-issues@ietf.org>; Mon, 09 Apr 2018 15:58:30.851 +0000 (UTC)
Date: Mon, 09 Apr 2018 15:58:30 +0000
From: Praveen Balasubramanian <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9fbf83c57914ef99c360d3338d22a3db1e9f2bd592cf0000000116e34fa692a169ce129955d7@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1271/379802605@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1271@github.com>
References: <quicwg/base-drafts/issues/1271@github.com>
Subject: Re: [quicwg/base-drafts] Connection migration optional? (#1271)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5acb8da6a86c6_36693fa7193daf2c7605f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: pravb
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3LGndy7aicf28dKdtEDkZoDgBVk4teIEI01V FAGiV5eo3okvB1mWTK7GdQ47fqemp3CBowy4oiSQHxU8Yw3q4pw/4lIkajKpdAZQn5uW8zRAVe2Tcu A0FpbujBJyZS2YH8hLWzMh/zmXG9BYPk4B1MUJaS5omvTjXtrIKmrsa8pQoZ6zQro2Z9t05ZI4pmrg 0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/9d98_iq8HTijDIJw7HI_baY7lpQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2018 15:59:06 -0000

"if you don't support migrations, don't send a NEW_CONNECTION_ID" mechanism can work as long as it stated that using a new connection ID for gratuitous migration is a MUST. I would add this requirement in addition to the sentence that @ianswett requested. 

The only downside I can think for this mechanism is that it will preclude use of multiple connection IDs on the same path without migration. Do we foresee use of multiple connection IDs for the same connection for unreliable semantics? Is there any other use case for NEW_CONNECTION_ID outside of gratuitous migration that will get affected?

>we should entertain a system whereby clients request new connection IDs rather than have them provided spontaneously
One problem with requesting connection IDs is that this will anyways have to be really early in the connection because if client loses cellular connectivity it will not have any means to contact the server over wifi. So for the parking lot problem, up front supply of at least one connection ID seems to be necessary?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1271#issuecomment-379802605

v2.23.0 | Report a Bug | By Email