Re: Connection IDs

Christian Huitema <huitema@huitema.net> Thu, 08 March 2018 00:46 UTC

Return-Path: <huitema@huitema.net>
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 4C6FD126CB6 for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 16:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 BGXz3nHyw_5q for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 16:46:01 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 463CE126BF6 for <quic@ietf.org>; Wed, 7 Mar 2018 16:45:56 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1etjgw-0009Dt-24 for quic@ietf.org; Thu, 08 Mar 2018 01:45:54 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1etjgt-0000iL-Fs for quic@ietf.org; Wed, 07 Mar 2018 19:45:52 -0500
Received: (qmail 8943 invoked from network); 8 Mar 2018 00:45:49 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.195]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 8 Mar 2018 00:45:49 -0000
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>
Cc: Ian Swett <ianswett@google.com>, Subodh Iyengar <subodh@fb.com>, Mike Bishop <mbishop@evequefou.be>, Patrick McManus <pmcmanus@mozilla.com>, IETF QUIC WG <quic@ietf.org>
References: <CABkgnnVSCnmzjWOZwQM+ctTxFXVzsVYe6Q3Zzk4yj3LNTYUtHw@mail.gmail.com> <CAOdDvNo9qmZqmEXBGM4bM6q3EO1FGuUxLSSWsVhNEYsn5u9puQ@mail.gmail.com> <CAKcm_gMR070JUegQbDw--RNr+0XYiBMwaTM3MBmqUo21u922TQ@mail.gmail.com> <CACpbDccpuNWnX=Y+gKaPxLEjUOnvu+hr9FqH+R6ZspwOfUq-qg@mail.gmail.com> <CABkgnnUPJYG-QE4qxfOd-6AoHHgxVq4K=EyRfoxkcvdDF=oaZA@mail.gmail.com> <MWHPR15MB18215C39DCB3DC5398778EC6B6D80@MWHPR15MB1821.namprd15.prod.outlook.com> <SN1PR08MB1854C45248CD637877C50FACDAD80@SN1PR08MB1854.namprd08.prod.outlook.com> <CACpbDccER27gggsst4DPf-JhtZNDQGdYMX8neaHVcfR19T3hzA@mail.gmail.com> <CABkgnnXcuH8tsgSud-3=8-V96NVVUoYFQe1EZJAbLeTJ74fc_A@mail.gmail.com> <585499f5ea2d49ca8691dc05d06e99fb@usma1ex-dag1mb5.msg.corp.akamai.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <900955f0-5c6b-be3e-fba6-0d53c8148d20@huitema.net>
Date: Wed, 7 Mar 2018 16:45:45 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <585499f5ea2d49ca8691dc05d06e99fb@usma1ex-dag1mb5.msg.corp.akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Connection IDs
X-Originating-IP: 168.144.250.223
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.55)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5uBRn0QyW79C7U1hdgpLJ4l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViWkGKr2tyABZPqmi13UUloc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQY5T+fsIz86TG72Lx5ZI1p INh8UHPssUrY3MbbkBcNcJM4tFgNsmdaWK69jAe3NvX/26h6lKBTg0hnYaA9jp5rWRpBOi7IfT+J o+6tsQI5W/ewkYi/XXej6UeAUN96sXI71lsFqhWb3P21BZ9jlHPbPFwq1OWq5AgT2u0X1EqIKkuY N2TKwXSs5yzvA+Jj8cparOr3e9uZYNezbxzCM5Ox64YsYGX6RGcy4uiMmsjJiTRc9aUV1oY4fX3W 5eOCNA395VKQZZ28EUZBFBO/fNvHx3CWeDma04jVK+GALZ9kurnuymSkQySlRRw9754xJI2lUW/F XbMuS2WlB161/YGFavTgs5pdKJpNpy9rpzw+UwWR2z7Rjs3BT1o4+6YSC6IfVgW9/bktU41htiJ8 fk7NkCSgONC3rqaXJrYXVXXByjf4baeCkx0hN8MDgAhE+CBnCUTZMc2PfI2VFTu1YYhfjg==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OmOFbiwSWYDe6sbqf4SD5QwkWzo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 00:46:03 -0000

On 3/7/2018 4:36 PM, Lubashev, Igor wrote:

> +1 for the connid direction from someone from an "eligible" employer.
>
> That said, the proposal precludes load balancers from using Conn ID possibly present in ICMP TooBig payload for routing the ICMP TooBig back to the server, so I am looking forward to "PMTUD for QUIC" talks in QUIC and TSVWG.
Funny, Patrick and I were just discussing preparing a draft based on the
experience with PMTU discovery in our implementation. Both work by
sending PMTU probes composed or PING and/or PAD.

I think that this kind of probing strategy is a good fit for an
encrypted transport like QUIC. I would not want to let cleartext ICMP
packets change the state of the connection. But this is a different thread.

And yes, by the way, I do like the new Connection IDs.

-- Christian Huitema