IETF Logo Mail Archive

Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Christian Huitema <huitema@huitema.net> Fri, 12 May 2017 01:12 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D3129B72 for <5gangip@ietfa.amsl.com>; Thu, 11 May 2017 18:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LlTg1AXMDypa for <5gangip@ietfa.amsl.com>; Thu, 11 May 2017 18:12:04 -0700 (PDT)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E821200B9 for <5gangip@ietf.org>; Thu, 11 May 2017 18:06:50 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1d8z2e-0008Fp-SY for 5gangip@ietf.org; Fri, 12 May 2017 03:06:49 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1d8z2a-0000Rr-FA for 5gangip@ietf.org; Thu, 11 May 2017 21:06:48 -0400
Received: (qmail 19725 invoked from network); 12 May 2017 01:06:43 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <cb.list6@gmail.com>; 12 May 2017 01:06:43 -0000
To: Lorenzo Colitti <lorenzo@google.com>
References: <149376035152.21552.16267155218438524059.idtracker@ietfa.amsl.com> <CAC8QAcfXDAQsv1MsCu7RAtBF6LC7Y_v8zutz1hOYkcbbRKT_cw@mail.gmail.com> <340a9b7fbfe5408bbc2f6d56e839009f@HE105831.emea1.cds.t-internal.com> <CAKD1Yr3qd=KRTNbNMY8OEwMbV_t4-MQd3bQHKcbeuGhRb-dH5A@mail.gmail.com> <CAD6AjGQTBeMt6WjwE4FvOjMBBLv0EYysk+Dc3uXpmpux9FpVvg@mail.gmail.com> <CAC8QAcctwk19Q6MRxrZfXtQqbM85qNr3bAcP2XfDP02M28o+Ow@mail.gmail.com> <CAKD1Yr3+hSjAAwsmwvS9DgpyWsT0PpB-DsDdbPGQMOzun6cU_w@mail.gmail.com> <CALx6S35ugvHXwp3NraicK76qigT-YscCMp+WoMPqgFH+oq+YCw@mail.gmail.com> <4C5F465B-EAF7-4B1D-9E57-71EA8C2F56AC@gmail.com> <756632AE-228A-4A99-90BB-A9444ABB3610@huitema.net> <CALx6S36VSpts=XxwMhE=z_eygJG=Ha-PmrBOvaGN3TSuh3UX8A@mail.gmail.com> <3272f15a-29df-e676-a370-c11c66c621f2@huitema.net> <CAKD1Yr15-Pc17FTrKNeMcrX87RLpWrXtCNdr56HmjMVj4wyUYg@mail.gmail.com>
Cc: Tom Herbert <tom@herbertland.com>, Jouni <jouni.nospam@gmail.com>, Behcet Sarikaya <sarikaya@ieee.org>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, 5gangip@ietf.org, Ca By <cb.list6@gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <01e7822f-2437-44cc-0aa4-cd04f7593b17@huitema.net>
Date: Thu, 11 May 2017 18:06:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr15-Pc17FTrKNeMcrX87RLpWrXtCNdr56HmjMVj4wyUYg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------08A0F150068E708B63FAFCDC"
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.27)
X-Recommended-Action: accept
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrSeLNWkSTo6mFAqDf0OPn+RcOb18WfxGyg6Om6u4YYm0AsJd8jVyFG/VFE LChI/ck5hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpF3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0+y0u6oVB F/ziZ3c/UW7aYrbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/itAn4jcdMxF7IZwZcQI3pIch5GgWTfn+efO qwWUHo8NGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+e+iK9O1xmYbh4XXhNvoIwzGyf0aq+d/9I/bGpNg5cA+
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/2ZZbCt0G2_0E3KHEjZ-NVRrszJ0>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2017 01:12:06 -0000

On 5/11/2017 2:04 AM, Lorenzo Colitti wrote:

> On Tue, May 9, 2017 at 3:15 AM, Christian Huitema <huitema@huitema.net
> <mailto:huitema@huitema.net>> wrote:
>
>     The dominant idea is that the client will obtain a set of "equivalent"
>     connection ID provided by the server. When the client moves to a new
>     address, t will pick one of yet unused connection ID provided by the
>     server. It will also insert a random gap in the sequence number. This
>     will still enable servers to maintain the connection, but will remove
>     the linkability hole.
>
>
> Have people thought about how to implement such a scheme in hardware
> load-balancers? Seems like it would require
>
>   * The network be able to guarantee stable hashing for a set of
>     connection IDs much larger than the total number of connections.
>   * The server to be able to predict how the network will hash given
>     connection IDs.
>
Would it not be better to discuss that on the QUIC WG's mailing list?

-- Christian Huitema

v2.23.0 | Report a Bug | By Email