RE: ECN in QUIC connection migration

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Fri, 02 February 2018 14:40 UTC

Return-Path: <ingemar.s.johansson@ericsson.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 ADA5012D84F for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 06:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=McDcnP5/; dkim=pass (1024-bit key) header.d=ericsson.com header.b=KSxbzsn2
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 rZaAgBaCPLzN for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 06:40:54 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1F0B812D881 for <quic@ietf.org>; Fri, 2 Feb 2018 06:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517582452; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Y/S6f4sa7Is5rfHhv87A9FA0IZanSOtycNTBjsiMcs=; b=McDcnP5/t1NNRa6EtojQu/z+kKHda4WLtRx3LAb/lKzPMESF+SiRQ6sYGBwSQr+Q /PIfeEW2EIscGewXjdDcWtibl36ggws6DaPayJlTHWiuW2BRYiGABoHxvuVW1R9y NoHWZb4j+E1iKL2tGuqfk1IZIrLsfepkwZYBjavae1c=;
X-AuditID: c1b4fb2d-b35ff70000007932-1e-5a7478739b97
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.F8.31026.378747A5; Fri, 2 Feb 2018 15:40:52 +0100 (CET)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Feb 2018 15:40:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Y/S6f4sa7Is5rfHhv87A9FA0IZanSOtycNTBjsiMcs=; b=KSxbzsn2VfIHzNGjWRabGLOExVSi4PzdLEJO1e8Kc5DR931VrJ42T03ANTXKjetQk6MWaYGkGlM4PSu6y++eUib0DEl0N+sT0zQst4rsxCNZcawWmfN98YjDNy45hjWN4PXWbp54xe7aSkKrSWRuBQdDJ8Uqkgbu4sggVkjw8/0=
Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3771.eurprd07.prod.outlook.com (52.133.7.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 14:40:49 +0000
Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0%13]) with mapi id 15.20.0464.012; Fri, 2 Feb 2018 14:40:49 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "ekinnear@apple.com" <ekinnear@apple.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
Thread-Topic: ECN in QUIC connection migration
Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAACCgj4A=
Date: Fri, 02 Feb 2018 14:40:49 +0000
Message-ID: <HE1PR0702MB3625B28D967738A0EE8A2BABC2F90@HE1PR0702MB3625.eurprd07.prod.outlook.com>
References: <HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0@HE1PR0702MB3625.eurprd07.prod.outlook.com> <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com>
In-Reply-To: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3771; 7:QU2yfq9dhtitQ0aOgSk/AJ1B7hmv8fR8VRaIhi24OD+dgUNauEP+aCmTXivW7azLeDj/PDqystlP7btIaB5FFchhHT1vVQ9lgM2iTDwRTO3Id/CciZ68CTM/F8ydkArGWm7aG6BBqA3olY43lfLfdExrq8lrbIDBGVR/dGfANEL1oODMXhiVMkGLHWZvPUZ3FZVdIJOYuZD1KZ8l7z1fxcFBHLxRMypxMlFL52XrzLrwt+gJylZkiJX9vAEyJ3/T
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 19e0e02a-3482-4a7d-fdcf-08d56a4af3f2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3771;
x-ms-traffictypediagnostic: HE1PR0702MB3771:
x-microsoft-antispam-prvs: <HE1PR0702MB37713EDC7B237DAB1CE288BBC2F90@HE1PR0702MB3771.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(211936372134217)(202460600054446)(153496737603132)(21748063052155)(31960201722614);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0702MB3771; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3771;
x-forefront-prvs: 05715BE7FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(39380400002)(346002)(199004)(189003)(51914003)(9686003)(6306002)(8936002)(55016002)(790700001)(186003)(6116002)(74316002)(53936002)(606006)(3846002)(236005)(97736004)(8666007)(2906002)(2900100001)(7736002)(229853002)(86362001)(59450400001)(5660300001)(68736007)(14454004)(478600001)(6246003)(5640700003)(99286004)(4326008)(966005)(54896002)(6436002)(66066001)(5250100002)(3280700002)(76176011)(19609705001)(54906003)(316002)(105586002)(25786009)(5630700001)(106356001)(2501003)(6506007)(7696005)(53546011)(6916009)(8676002)(26005)(9326002)(33656002)(1730700003)(102836004)(2351001)(3660700001)(2950100002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3771; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lNQF+lS4iQcEPegq3N96ffSE/YZ7r1bGEXpgaiS4ipbetHXo+e3FLQOG0PAG2CRyRsnMQy5MvbtM/a44b3/Cug==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB3625B28D967738A0EE8A2BABC2F90HE1PR0702MB3625_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19e0e02a-3482-4a7d-fdcf-08d56a4af3f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 14:40:49.4299 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3771
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OzvOjpyW4pNllxHdyGXZh1Ea9akJ2YWIYh+ykQeVthk7 UzSIbFaITjJMTae1SstbWTLNruQqa5q1DK1EXU7TRgZdl5ZW294Ffvv9///ned/neXkZUuoQ RTCpOgOv16k1MlpCle29GRNlyDSoop3llML0ZYui6JhZrJgcvCVSGLNrSEW7p5pQmCzBm2hl 0SMLqWy2T9BKS1O6su9sB6WsqpoklEbPRXoHrZLEJvGa1Axev3rjfknKo7pz9CHXdZSZW++g slFuA8pDQQxw66DNZaLzkISRcg8RvPtyl8TiCYLevwWET1DcVwKq+yfEOCkmwF3rEWExiuBJ Tpf/MJqLhVrbTz+HclFgHnyNfEUk50IwXT1K+oI53qDZ2EniIjm4TcdFmNeD63ijnyluCThP NhE+Zrn9MGHuDdxWhKDr3CDlC4K4OChsqPQz4iLB+RP7JBcOfSPnCbweB1V3X5CYw8A9/EeE 6w/A17cFIuwvgqluF405ErrP5/unBq6FgA5HCYUDOTSf/hR4swS4UvZQjLkDwdjzfZhXwase V8BPg/5nxYHeawg6TVp8aAUJvZ5W70SMV8yH/PHoQiQvnzF3uTchve1nemLL/fvPBnvZCIXt FdB4ezWuXgxn8ofEmJfDiYpK8UzfgsR1KEzgBUGbvDZGzutTDwhCmk6u4w1NyPvP2qy/o1pR /cfNNsQxSDaLzTEYVFKROkPI0toQMKQslG1J8FpskjrrMK9PS9Sna3jBhuYxlCyctcezKimX rDbwB3n+EK//nxJMUEQ2WkB8kpXmFNwngqemzVnDkrkbQubZg921jn2Pa+IvPGj/YX5qtS22 HCmc86bf+Ov91d1j4vptxeaFKcu2G63LJldppJV3dg2x7frLR/O2J9778HnBy51dW0MyYuKc S0vN+Y0D/Pe6G+OXuscf74lgNcsL558YOFWjbf2x49udg3+tKSUySkhRr1lJ6gX1PzZF0p5j AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vTApKFeZbIU6JJ1vOiUtmn2iSHA>
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: Fri, 02 Feb 2018 14:40:58 -0000

Hi
Thanks for the comments.
You are right, eventually the specifics around ECN capability at connection migration should be very simple. I chose to overspecify the text, hopefully to make it sufficiently clear that byte counters should do the job just fine.

/Ingemar

From: ekinnear@apple.com [mailto:ekinnear@apple.com]
Sent: den 2 februari 2018 00:02
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<mailto: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<mailto:ingemar.s.johansson@ericsson.com>
www.ericsson.com<x-msg://316/www.ericsson.com>

                 You can't start a fire
  Worrying 'bout your little world falling apart
               Bruce Springsteen
==================================