Re: ECN in QUIC connection migration
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 12 February 2018 15:42 UTC
Return-Path: <mikkelfj@gmail.com>
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 4650512D82E for <quic@ietfa.amsl.com>; Mon, 12 Feb 2018 07:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 lS2OIFS_JyG5 for <quic@ietfa.amsl.com>; Mon, 12 Feb 2018 07:42:07 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 39C6712D82F for <quic@ietf.org>; Mon, 12 Feb 2018 07:42:07 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id p188so17678483ioe.12 for <quic@ietf.org>; Mon, 12 Feb 2018 07:42:07 -0800 (PST)
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 :cc; bh=hETOOrRWhgoKHE4352QAwqFs+51OfSM6DjcjKRz9jgI=; b=SPihQTjpSq2jACfKQOc5mDHiv8MGIIZ4ztNLa4CFq4d2lmiExzul2NHEtNa900XHvt AHhQgtecgSeM0csv9VPKLkfiTClrw+MduW6+04c31fAwD+vkyuBsAsqWG6uIRto2Dt98 hH8mTB7ZOGj534Tm1ubE7YUewFBCkSiuSpfHjsFArLgiIuvX+u18GOgg0JqBEXetNokx S24Zj4U+Rq4r7BEMDbkFtwL8ho+Q++j9P1su5dJDMoe43VvdJpaMspttqOl2akeENQBY Ap/+DA8wFknEL90BAyy2zf6CcZ4hhiBnigOTrjBQ1IBpjTQfOK/XdLUVqkhLOETa18AD ReJg==
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:cc; bh=hETOOrRWhgoKHE4352QAwqFs+51OfSM6DjcjKRz9jgI=; b=bcY2v2xvitxiyBCpjSLYR2p73U+PtgKKPpNMQCo9SFZu8xiQi01bMbvwW+31G08nu3 1yAAw9WH2VRATDOlxgEXpkTPKzpz6lPBvJKNRGJGhP8eys2zdw7mJ6OJBaKgW9GYqPBy IqC6KkzbW+OndDEhZ237IJDtueyOmkNyA/wtHRCqNjq9bmCEvou+1oveIZDynndXL1ty lZ1ilFy2Sf3J4wnYYxras73dpvG25UJ/6jd2q8aB3T9lVpL7QdWvI0ieqsBBr4isMnF6 ipXkB57s7AmjFc5yIatHtfm8woaHM66a1azF/kyS7DypjNkPOvKJZRxfIDjLETgzCA1S vIwQ==
X-Gm-Message-State: APf1xPBvmLeuUItGisIZswUMDaN+8OuvCBmCwB+yE4ZpQjTJ/0rbK7Ri K8PkdtNvgD7oKt9lGzcZ6SK4AZP8FiupeYPL6as=
X-Google-Smtp-Source: AH8x22645zDWk6bv2LPhd6cLaM7U2X3fAKS0dWi8biuJGHDgfrs92fD9bpiKZV8hvygAVRyvDjQI4sAUUALRMMl/L+4=
X-Received: by 10.107.34.199 with SMTP id i190mr14139444ioi.297.1518450126578; Mon, 12 Feb 2018 07:42:06 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 07:42:05 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <EFA61DBC-1F6F-49C2-906C-D0054F2341C7@tik.ee.ethz.ch>
References: <HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0@HE1PR0702MB3625.eurprd07.prod.outlook.com> <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <VI1PR0701MB2126E79A17DB715F6C91EA05B9F90@VI1PR0701MB2126.eurprd07.prod.outlook.com> <HE1PR0702MB36256D92C008302CBD908DE9C2F20@HE1PR0702MB3625.eurprd07.prod.outlook.com> <EFA61DBC-1F6F-49C2-906C-D0054F2341C7@tik.ee.ethz.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 12 Feb 2018 07:42:05 -0800
Message-ID: <CAN1APdcLO8HsT5cbbzHSvYBbBzz=3pfXLqm_2gLhZN-TiWVCbw@mail.gmail.com>
Subject: Re: ECN in QUIC connection migration
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: Christian Huitema <huitema@huitema.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, QUIC WG <quic@ietf.org>, Ian Swett <ianswett@google.com>, "ekinnear@apple.com" <ekinnear@apple.com>, "Lubashev, Igor" <ilubashe@akamai.com>
Content-Type: multipart/alternative; boundary="001a1140d9446776c2056505b856"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kWeY8jnWhmNMcD1oyl7BwHMYSKM>
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: Mon, 12 Feb 2018 15:42:11 -0000
I haven’t followed the ECN discussion very closely, but I miss a discussion of possible abuse scenarios and how to avoid them. On 12 February 2018 at 16.26.32, Mirja Kühlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: Hi Ingemar, two points. I think it would be good to be as explicit as possible here, therefore I would prefer if an endpoint that knows that it can not access the ECN IP bits indicates this directly in the handshake. In this case no further testing is needed. Further, the path testing itself is independent of QUIC and can be used for any protocol. Moreover, it’s more complicated than just testing ECT. I guess the general advice here is to remember which codepoints were send and compare this to the feedback provided. If discrepancies are observed that indicate that a middlebox has changed these bits, all packets should be marked as no-ECT (while additional testing MAY be performed at any later point in time). However, how exactly this testing should look like, should not be specified in this doc (but more generally). Mirja > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S < ingemar.s.johansson@ericsson.com>: > > Hi Eric, Koen + others > > Thanks for the comments and the update. A question to the rest of the audience, does the presented text explain sufficiently enough how ECN works with connection migration ? > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration > > > /Ingemar > > > From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto: koen.de_schepper@nokia-bell-labs.com] > Sent: den 2 februari 2018 15:44 > To: ekinnear@apple.com; Ingemar Johansson S < ingemar.s.johansson@ericsson.com> > Cc: QUIC WG <quic@ietf.org>; Ian Swett <ianswett@google.com>; Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema <huitema@huitema.net> > Subject: RE: ECN in QUIC connection migration > > Hi Ingemar, > > I also read again through the document, and had following comments: > > I replaced: > “The ACK_ECN frame is used to convey ACKs when the ECN capability exchange concludes that ECN should be used for the given connection.” > Originally it sounds as if the counters are not echoed anymore if the ECN capability check fails. I assume this was not the intention, but if it is: First, we don’t have a protocol or decision point defined when that condition is met (sender should let the receiver know in the next packet), and second, I would always send the echo, as we might “try again later (with another ECT?)”, or might decide to use the ECN bits differently later. > > I also changed the text around the connection migration, I think before Eric reviewed it. I made it such that every new path creates a new connection state with an initialized congestion control state and ECN counters (at least ECN counters reset to 0s). Not sure if this matches with the other sections in the QUIC draft. > > I also had the thought whether it was really needed to have the 2 cases. I agree we should simplify, by just starting over and doing the check unconditionally whether it was successful or not in a previous path. > > Regards, > Koen. > > From: ekinnear@apple.com [mailto:ekinnear@apple.com] > Sent: Friday, February 2, 2018 12:02 AM > To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com> > Cc: QUIC WG <quic@ietf.org>; Ian Swett <ianswett@google.com>; Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema <huitema@huitema.net>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> > Subject: Re: ECN in QUIC connection migration > > Hi Ingemar, > > This generally looks good to me! > A few questions and observations: > > There are two unique cases: > > • ECN capability check successful at initial connection setup > • ECN capability check failed at initial connection setup > > Are these actually any different in terms of action taken by an endpoint? > It seems like on the new network path the endpoint would go through the same process of: (a) verify ECN capability and if successful to whatever degree then (b) run the rest of the ECN machinery as appropriate. > > In other words, as long as you allow people to start using ECN upon migration (in other words, to allow starting it after the initial connection establishment), then the specifics for ECN with migration is essentially one statement, which is “do the ECN process on each new network path that you use”. > > Connection migration has impact on the number of reported CE marked packets. A new connection state with new congestion control state and ECN counters is instantiated at the sender and receiver. The ECN counters MUST start from zero again. > > This seems fine to me, it’s inline with the rest of the congestion control/loss recovery state that also needs to be reset for the new path. > > Given that each migration requires at least one exchange of packets at the beginning (at the very least for address validation from the side of the endpoint that didn’t migrate), it seems like that’s an excellent moment to mark the packets and perform the ECN capability detection. Those packets are also likely padded, etc. similar to initial packets since they’re on a previously unused network path. > > I think the current proposed requirement of just using the “first” packets and marking those is sufficient (and good to avoid any requirement as to which frames are contained in those packets), since we are always exchanging packets in both directions immediately after migration. > > This has the added benefit such that any endpoint “probing” possible network paths could include the bits necessary to detect ECN capability on the path being probed, so it could even know before migrating whether or not it would be able to use ECN on that new path. > > Thanks, > Eric > > > > > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > > Hi > I have written up different aspects of connection migration and how it plays with ECN. > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration > > A caveat.. I am a bit unsure about the definition of connection migration . My interpretation is that a client moves to a new IP address due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new connection instantiated at a connection migration ? > > /Ingemar > > ================================== > Ingemar Johansson M.Sc. > Master Researcher > > Ericsson Research > Network Protocols & E2E Performance > Labratoriegränd 11 > 971 28, Luleå, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > > You can't start a fire > Worrying 'bout your little world falling apart > Bruce Springsteen > ==================================
- ECN in QUIC connection migration Ingemar Johansson S
- Re: ECN in QUIC connection migration Eric Kinnear
- RE: ECN in QUIC connection migration Ingemar Johansson S
- RE: ECN in QUIC connection migration De Schepper, Koen (Nokia - BE/Antwerp)
- RE: ECN in QUIC connection migration Ingemar Johansson S
- Re: ECN in QUIC connection migration Mirja Kühlewind
- Re: ECN in QUIC connection migration Mikkel Fahnøe Jørgensen
- Re: ECN in QUIC connection migration Mirja Kühlewind
- Re: ECN in QUIC connection migration Mikkel Fahnøe Jørgensen
- Re: ECN in QUIC connection migration Mirja Kühlewind
- RE: ECN in QUIC connection migration Ingemar Johansson S
- RE: ECN in QUIC connection migration Ingemar Johansson S
- Re: ECN in QUIC connection migration Mirja Kühlewind
- RE: ECN in QUIC connection migration Ingemar Johansson S
- RE: ECN in QUIC connection migration De Schepper, Koen (Nokia - BE/Antwerp)
- RE: ECN in QUIC connection migration Ingemar Johansson S
- Re: ECN in QUIC connection migration Gorry Fairhurst
- RE: ECN in QUIC connection migration Ingemar Johansson S