IETF Logo Mail Archive

Re: Connection IDs

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 08 March 2018 08:25 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 034051205F0 for <quic@ietfa.amsl.com>; Thu, 8 Mar 2018 00:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 D-nKNSWkIFDv for <quic@ietfa.amsl.com>; Thu, 8 Mar 2018 00:25:47 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C0C39129515 for <quic@ietf.org>; Thu, 8 Mar 2018 00:19:00 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2C2801B0013B; Thu, 8 Mar 2018 08:18:18 +0000 (GMT)
Message-ID: <5AA0F1CA.7050803@erg.abdn.ac.uk>
Date: Thu, 08 Mar 2018 08:18:18 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Christian Huitema <huitema@huitema.net>
CC: "Lubashev, Igor" <ilubashe@akamai.com>, Martin Thomson <martin.thomson@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, 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>
Subject: Re: Connection IDs
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> <900955f0-5c6b-be3e-fba6-0d53c8148d20@huitema.net>
In-Reply-To: <900955f0-5c6b-be3e-fba6-0d53c8148d20@huitema.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z1DCsQNDI-zJvFt9Pef3UtHY5Yk>
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 08:25:48 -0000

Christian,

Do you see anything different here for QUIC compared to any other 
datagram transport?

It looks like the same problem for probing for PMTU for any UDP-based 
transport, and the ICMP issue with load-balancing is well-known (at 
least was discussed in the context of ECMP). I'd be interested in 
understanding experience with QUIC.

Gorry

On 08/03/2018, 00:45, Christian Huitema wrote:
> 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

v2.23.0 | Report a Bug | By Email