From nobody Wed Jul 1 00:51:23 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F793A09BB for ; Wed, 1 Jul 2020 00:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 yUweXnD5Oz_n for ; Wed, 1 Jul 2020 00:51:18 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A40EF3A09BC for ; Wed, 1 Jul 2020 00:51:18 -0700 (PDT) Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0844CB274620127A975D; Wed, 1 Jul 2020 08:51:16 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 1 Jul 2020 08:51:15 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 1 Jul 2020 15:51:12 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 1 Jul 2020 15:51:12 +0800 From: Liyizhou To: Michael Welzl , Carsten Bormann CC: Lars Eggert , loops Thread-Topic: [LOOPS] Charter github issue #4: ECN-Only Thread-Index: AQHWSrx6cDXubVw2rkqK/m/rdlFYT6joaAiAgAADJACAB+1QgIAAApAAgAACYACAAA3hAIAB8sdA Date: Wed, 1 Jul 2020 07:51:12 +0000 Message-ID: References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> In-Reply-To: <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 07:51:21 -0000 SGksDQoNClJGQyA4MDg3IGlzIGdyZWF0IHNvdXJjZSB0byBrbm93LiBUaGFuayB5b3UsIE1pY2hh ZWwuDQoNClRoZSBwcm9wb3NlZCBjaGFydGVyIHNheXM6DQoNCiIod2hpY2ggdHlwaWNhbGx5IHJl cXVpcmVzIGFsbCByb3V0ZXMgb24gdGhlIHBhdGggc2VnbWVudCB0byBiZSBFQ04tZW5hYmxlZCki DQoNCkZyb20gbXkgdW5kZXJzdGFuZGluZyBvbiB0aGUgZGlzY3Vzc2lvbiwgDQp3b3VsZCByZXBs YWNpbmcgInR5cGljYWxseSIgd2l0aCAicHJlZmVyYWJseSIgcmVhc29uYWJsZT8NCg0KRm9yIG5v bi1mdWxseSBFQ04gc2VnbWVudCwgYSBzaW1wbGUgc3RyYXRlZ3kgb2YgY29udmVydGluZyBsb3Nz IHNpZ25hbCB0byBFQ04gY2FuIGJlIHVzZWQgKGluZ3Jlc3Mgb3IgZWdyZXNzIFRCRCkuDQpGb3Ig ZnVsbHkgRUNOIHNlZ21lbnQsIG1vcmUgc3RyYXRlZ2ljIENFIG1hcmtpbmcgY291bGQgYmUgdXNl ZC4NCiANCg0KUmVnYXJkcywNCllpemhvdQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBMT09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNaWNoYWVsIFdlbHpsDQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDIwIDU6NDcgUE0NClRv OiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0Bl Z2dlcnQub3JnPjsgbG9vcHMgPGxvb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtMT09QU10g Q2hhcnRlciBnaXRodWIgaXNzdWUgIzQ6IEVDTi1Pbmx5DQoNCg0KDQo+IE9uIEp1biAzMCwgMjAy MCwgYXQgMTA6NTcgQU0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4g DQo+IA0KPiANCj4+IE9uIDIwMjAtMDYtMzAsIGF0IDEwOjQ5LCBMYXJzIEVnZ2VydCA8bGFyc0Bl Z2dlcnQub3JnPiB3cm90ZToNCj4+IA0KPj4gU2lnbmVkIFBHUCBwYXJ0DQo+PiBIaSwNCj4+IA0K Pj4gT24gMjAyMC02LTMwLCBhdCAxMTozOSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KPj4+IFJpZ2h0LiAgSXQgc2VlbXMgd2UgaGF2ZSBtaXNzZWQgb25lIHVzZSBjYXNl IGhlcmU6IFVzaW5nIExPT1BTIHRvIGNvbnZlcnQgYSBkcm9wLWJhc2VkIHNlZ21lbnQgdG8gYW4g RUNOLW1hcmtpbmcgc2VnbWVudCAoZXZlcnkgbG9zcyBiZWNvbWVzIGEgQ0UtbWFya2VkIHBhY2tl dCwgYnV0IHRoZSBwYWNrZXQgaXMgYWN0dWFsbHkgdGhlcmUgYW5kIG5vdCBiZWluZyBkcm9wcGVk KS4gIFRoZSBiZW5lZml0cyBoZXJlIChpZiB0aGUgc2VnbWVudCBpcyByZWxhdGl2ZWx5IHNob3J0 KSBhcmUgaW4gbG93ZXIgbGF0ZW5jeSBmb3IgdGhlIGRldGVjdGlvbiBhbmQgcmVjb3ZlcnkuICAo VGhlcmUgaXMgYWxzbyBhIG1ldGEtYmVuZWZpdCBpbiBwcm92aWRpbmcgbW9yZSBFQ04tbWFya2lu Zy4pDQo+PiANCj4+IHNvcnJ5LCBJIGRvbid0IGdldCB0aGlzIHVzZSBjYXNlLCBjb3VsZCB5b3Ug ZWxhYm9yYXRlIGEgYml0Pw0KPj4gDQo+PiBJIHRob3VnaHQgdGhlIGJlbmVmaXQgb2YgTE9PUFMg d2FzIHRvIGhpZGUgYW55IGxvc3Mgb24gdGhlIExPT1BTIHNlZ21lbnQgZnJvbSB0aGUgZW5kcG9p bnRzLCBlaXRoZXIgYnkgbG9jYWwgUlRYIG9yIHJlY292ZXJ5IHZpYSBGRUMuIEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aGVyZSBhIHNpbWlsYXIgYmVuZWZpdCB3b3VsZCBjb21lIGZyb20gaWYgeW91IGp1 c3QgbWFyayAoYW5kIHRoZW4gc3RyaXA/KSBFQ04/DQo+IA0KPiBUaGUgYmVuZWZpdCB3b3VsZCBi ZSBhY3R1YWxseSBnZXR0aW5nIHRoZSBwYWNrZXQsIGZhc3QuDQo+IFRoZSBiZW5lZml0IHdvdWxk IG5vdCBiZSBoaWRpbmcgdGhlIGxvc3MgZnJvbSB0aGUgY29uZ2VzdGlvbiBjb250cm9sLg0KDQpJ IHRoaW5rIHRoYXTigJlzIGEgZ3JlYXQgaWRlYSEgIEUuZy4sIHRoaXMgY2FuIHJlZHVjZSBoZWFk LW9mLWxpbmUgYmxvY2tpbmcgIChzZWUgUkZDIDgwODcgZm9yIG1vcmUpLg0KDQoNCj4gDQo+IEdy w7zDn2UsIENhcnN0ZW4NCj4gDQo+IA0KPj4+IFNvIHRoaXMgd291bGQgYXJndWUgZm9yIGRlZmlu aW5nIExPT1BTIGZvciB0aGUgbm9uLW1hcmtpbmcgc2VnbWVudCBjYXNlIGFzIHdlbGwsIG1heWJl IHNwZWNpZmljYWxseSBpZ25vcmluZyBhbnkgYmVuZWZpdHMgY29taW5nIGZyb20gZGV0ZWN0aW5n IG5vbi1jb25nZXN0aXZlIGxvc3NlcyBhcyBzdWNoLg0KPj4gDQo+PiBJIGRvbid0IGdldCB0aGlz IGVpdGhlciwgc29ycnkuDQoNCisxLCB0aGlzIHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFyc2UuIEkg ZG8gZ2V0IHRoZSBmaXJzdCBoYWxmIG9mIGl0IHRob3VnaCwgYW5kIEkgYWdyZWUgd2l0aCBpdDog aWYgKGFuZCBvbmx5IGlmKSB0aGUg4oCccmVhbCIgc2VuZGVyIGFuZCByZWNlaXZlciBzcGVhayBF Q04sIHRoZW4gKGV2ZW4gaWYgdGhlIExPT1BTIHNlZ21lbnQgZG9lc27igJl0IHN1cHBvcnQgRUNO KSwgYSBsb3NzICsgcmV0cmFuc21pdCBvbiB0aGUgTE9PUFMgc2VnbWVudCBjYW4gYmUgdHVybmVk IGludG8gYSBzdWNjZXNzZnVsbHkgZm9yd2FyZGVkIHBhY2tldCBjYXJyeWluZyBDRT0xIGJ5IHRo ZSBMT09QUyBlZ3Jlc3MgKHdlbGwsIGluIGZhY3QsIG1heWJlIHRoZSBpbmdyZXNzIHdvdWxkIGRv IHRoZSBDRT0xIG1hcmtpbmc7IHdoYXRldmVyIGlzIG1vcmUgZWZmaWNpZW50IHRvIGltcGxlbWVu dCkuDQoNCkNoZWVycywNCk1pY2hhZWwNCg0KLS0gDQpMT09QUyBtYWlsaW5nIGxpc3QNCkxPT1BT QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xvb3BzDQo= From nobody Wed Jul 1 00:59:07 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA353A09D9 for ; Wed, 1 Jul 2020 00:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7JyLOiMNs9WM for ; Wed, 1 Jul 2020 00:59:04 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 C23DC3A09D5 for ; Wed, 1 Jul 2020 00:59:03 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jqXdr-000CKq-H2; Wed, 01 Jul 2020 09:58:51 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.3]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jqXdq-0006Vx-H8; Wed, 01 Jul 2020 09:58:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Michael Welzl In-Reply-To: Date: Wed, 1 Jul 2020 09:58:49 +0200 Cc: Carsten Bormann , Lars Eggert , loops Content-Transfer-Encoding: quoted-printable Message-Id: <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> To: Liyizhou X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.3]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FB6C0D427F76D0DEDFE6934C85F29C4D51AD5F04 Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 07:59:07 -0000 Hi! > On Jul 1, 2020, at 9:51 AM, Liyizhou wrote: >=20 > Hi, >=20 > RFC 8087 is great source to know. Thank you, Michael. >=20 > The proposed charter says: >=20 > "(which typically requires all routes on the path segment to be = ECN-enabled)" >=20 > =46rom my understanding on the discussion,=20 > would replacing "typically" with "preferably" reasonable? No, I think we should replace: *** Initially, LOOPS will focus on path segments that do not include either = end host, and where the primary congestion signaling method is ECN = (which typically requires all routes on the path segment to be = ECN-enabled).=20 *** with: *** Initially, LOOPS will focus on path segments that do not include either = end host. *** I am getting quite excited about this =E2=80=9Closs to ECN conversion=E2=80= =9D idea. Right now, the lack of routers that really do apply ECN = marking is the missing piece in ECN deployment - so this opens a new = option for gradual deployment of ECN, where path segments containing = non-ECN-enabled routers can be changed into actually providing that = signal without even touching the routers in that segment. > For non-fully ECN segment, a simple strategy of converting loss signal = to ECN can be used (ingress or egress TBD). Yes. > For fully ECN segment, more strategic CE marking could be used. I don=E2=80=99t understand this; what would such =E2=80=9Cmore strategic = CE marking=E2=80=9D be? Cheers, Michael >=20 >=20 > Regards, > Yizhou >=20 >=20 > -----Original Message----- > From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: Tuesday, June 30, 2020 5:47 PM > To: Carsten Bormann > Cc: Lars Eggert ; loops > Subject: Re: [LOOPS] Charter github issue #4: ECN-Only >=20 >=20 >=20 >> On Jun 30, 2020, at 10:57 AM, Carsten Bormann wrote: >>=20 >>=20 >>=20 >>> On 2020-06-30, at 10:49, Lars Eggert wrote: >>>=20 >>> Signed PGP part >>> Hi, >>>=20 >>> On 2020-6-30, at 11:39, Carsten Bormann wrote: >>>> Right. It seems we have missed one use case here: Using LOOPS to = convert a drop-based segment to an ECN-marking segment (every loss = becomes a CE-marked packet, but the packet is actually there and not = being dropped). The benefits here (if the segment is relatively short) = are in lower latency for the detection and recovery. (There is also a = meta-benefit in providing more ECN-marking.) >>>=20 >>> sorry, I don't get this use case, could you elaborate a bit? >>>=20 >>> I thought the benefit of LOOPS was to hide any loss on the LOOPS = segment from the endpoints, either by local RTX or recovery via FEC. I = don't understand where a similar benefit would come from if you just = mark (and then strip?) ECN? >>=20 >> The benefit would be actually getting the packet, fast. >> The benefit would not be hiding the loss from the congestion control. >=20 > I think that=E2=80=99s a great idea! E.g., this can reduce = head-of-line blocking (see RFC 8087 for more). >=20 >=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>>> So this would argue for defining LOOPS for the non-marking segment = case as well, maybe specifically ignoring any benefits coming from = detecting non-congestive losses as such. >>>=20 >>> I don't get this either, sorry. >=20 > +1, this sentence is hard to parse. I do get the first half of it = though, and I agree with it: if (and only if) the =E2=80=9Creal" sender = and receiver speak ECN, then (even if the LOOPS segment doesn=E2=80=99t = support ECN), a loss + retransmit on the LOOPS segment can be turned = into a successfully forwarded packet carrying CE=3D1 by the LOOPS egress = (well, in fact, maybe the ingress would do the CE=3D1 marking; whatever = is more efficient to implement). >=20 > Cheers, > Michael >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Wed Jul 1 01:19:12 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE533A0AA6 for ; Wed, 1 Jul 2020 01:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 hbX4hZIwvWZq for ; Wed, 1 Jul 2020 01:19:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 34D4C3A0A96 for ; Wed, 1 Jul 2020 01:19:09 -0700 (PDT) Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D39D56D4029A1228B0DF; Wed, 1 Jul 2020 09:19:06 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 1 Jul 2020 09:19:06 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 1 Jul 2020 16:19:03 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 1 Jul 2020 16:19:03 +0800 From: Liyizhou To: Michael Welzl CC: Carsten Bormann , Lars Eggert , loops Thread-Topic: [LOOPS] Charter github issue #4: ECN-Only Thread-Index: AQHWSrx6cDXubVw2rkqK/m/rdlFYT6joaAiAgAADJACAB+1QgIAAApAAgAACYACAAA3hAIAB8sdA//+BPoCAAIe5AA== Date: Wed, 1 Jul 2020 08:19:03 +0000 Message-ID: References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> In-Reply-To: <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 08:19:11 -0000 UGxlYXNlIHNlZSBbeXpdIGlubGluZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IE1pY2hhZWwgV2VsemwgW21haWx0bzptaWNoYXdlQGlmaS51aW8ubm9dIA0KU2VudDogV2Vk bmVzZGF5LCBKdWx5IDEsIDIwMjAgMzo1OSBQTQ0KVG86IExpeWl6aG91IDxsaXlpemhvdUBodWF3 ZWkuY29tPg0KQ2M6IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgTGFycyBFZ2dlcnQg PGxhcnNAZWdnZXJ0Lm9yZz47IGxvb3BzIDxsb29wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb TE9PUFNdIENoYXJ0ZXIgZ2l0aHViIGlzc3VlICM0OiBFQ04tT25seQ0KDQpIaSENCg0KDQo+IE9u IEp1bCAxLCAyMDIwLCBhdCA5OjUxIEFNLCBMaXlpemhvdSA8bGl5aXpob3VAaHVhd2VpLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IFJGQyA4MDg3IGlzIGdyZWF0IHNvdXJjZSB0byBrbm93 LiBUaGFuayB5b3UsIE1pY2hhZWwuDQo+IA0KPiBUaGUgcHJvcG9zZWQgY2hhcnRlciBzYXlzOg0K PiANCj4gIih3aGljaCB0eXBpY2FsbHkgcmVxdWlyZXMgYWxsIHJvdXRlcyBvbiB0aGUgcGF0aCBz ZWdtZW50IHRvIGJlIEVDTi1lbmFibGVkKSINCj4gDQo+IEZyb20gbXkgdW5kZXJzdGFuZGluZyBv biB0aGUgZGlzY3Vzc2lvbiwgd291bGQgcmVwbGFjaW5nICJ0eXBpY2FsbHkiIA0KPiB3aXRoICJw cmVmZXJhYmx5IiByZWFzb25hYmxlPw0KDQoNCk5vLCBJIHRoaW5rIHdlIHNob3VsZCByZXBsYWNl Og0KDQoqKioNCkluaXRpYWxseSwgTE9PUFMgd2lsbCBmb2N1cyBvbiBwYXRoIHNlZ21lbnRzIHRo YXQgZG8gbm90IGluY2x1ZGUgZWl0aGVyIGVuZCBob3N0LCBhbmQgd2hlcmUgdGhlIHByaW1hcnkg Y29uZ2VzdGlvbiBzaWduYWxpbmcgbWV0aG9kIGlzIEVDTiAod2hpY2ggdHlwaWNhbGx5IHJlcXVp cmVzIGFsbCByb3V0ZXMgb24gdGhlIHBhdGggc2VnbWVudCB0byBiZSBFQ04tZW5hYmxlZCkuIA0K KioqDQoNCndpdGg6DQoNCioqKg0KSW5pdGlhbGx5LCBMT09QUyB3aWxsIGZvY3VzIG9uIHBhdGgg c2VnbWVudHMgdGhhdCBkbyBub3QgaW5jbHVkZSBlaXRoZXIgZW5kIGhvc3QuDQoqKioNCg0KW3l6 XSBBZ3JlZWQuDQoNCkkgYW0gZ2V0dGluZyBxdWl0ZSBleGNpdGVkIGFib3V0IHRoaXMg4oCcbG9z cyB0byBFQ04gY29udmVyc2lvbuKAnSBpZGVhLiBSaWdodCBub3csIHRoZSBsYWNrIG9mIHJvdXRl cnMgdGhhdCByZWFsbHkgZG8gYXBwbHkgRUNOIG1hcmtpbmcgaXMgdGhlIG1pc3NpbmcgcGllY2Ug aW4gRUNOIGRlcGxveW1lbnQgLSBzbyB0aGlzIG9wZW5zIGEgbmV3IG9wdGlvbiBmb3IgZ3JhZHVh bCBkZXBsb3ltZW50IG9mIEVDTiwgd2hlcmUgcGF0aCBzZWdtZW50cyBjb250YWluaW5nIG5vbi1F Q04tZW5hYmxlZCByb3V0ZXJzIGNhbiBiZSBjaGFuZ2VkIGludG8gYWN0dWFsbHkgcHJvdmlkaW5n IHRoYXQgc2lnbmFsIHdpdGhvdXQgZXZlbiB0b3VjaGluZyB0aGUgcm91dGVycyBpbiB0aGF0IHNl Z21lbnQuDQoNCg0KPiBGb3Igbm9uLWZ1bGx5IEVDTiBzZWdtZW50LCBhIHNpbXBsZSBzdHJhdGVn eSBvZiBjb252ZXJ0aW5nIGxvc3Mgc2lnbmFsIHRvIEVDTiBjYW4gYmUgdXNlZCAoaW5ncmVzcyBv ciBlZ3Jlc3MgVEJEKS4NCg0KWWVzLg0KDQoNCj4gRm9yIGZ1bGx5IEVDTiBzZWdtZW50LCBtb3Jl IHN0cmF0ZWdpYyBDRSBtYXJraW5nIGNvdWxkIGJlIHVzZWQuDQoNCkkgZG9u4oCZdCB1bmRlcnN0 YW5kIHRoaXM7IHdoYXQgd291bGQgc3VjaCDigJxtb3JlIHN0cmF0ZWdpYyBDRSBtYXJraW5n4oCd IGJlPw0KDQpbeXpdIElmIHdlIGtub3cgYWxsIHJvdXRlcnMgYXJlIEVDTi1lbmFibGVkIGFsb25n IHRoZSBwYXRoIHNlZ21lbnQsIHdlIGtub3cgdGhhdCB0aGV5IHdvbuKAmXQgdXNlIHBhY2tldCBk cm9wcGluZyBhcyBhIGNvbmdlc3Rpb24gc2lnbmFsLCBleGNlcHQgaW4gaGVhdnkgb3ZlcmxvYWQg c2l0dWF0aW9ucyAoaW4gd2hpY2ggd2UgYWxyZWFkeSBzaG91bGQgaGF2ZSBwbGVudHkgQ0UtbWFy a2VkIHBhY2tldHMpLiAgU28gd2UgaGF2ZSBhIHNpbXBsZSBoZXVyaXN0aWMgZm9yIGRpc3Rpbmd1 aXNoaW5nIG5vbi1jb25nZXN0aW9uIGZyb20gY29uZ2VzdGlvbiBsb3NzZXMuIExPT1BTIGVncmVz cyBuZWVkIG5vdCBzZXQgQ0UgZm9yIG5vbi1jb25nZXN0aW9uIGxvc3MuDQoNCkNoZWVycywNCk1p Y2hhZWwNCg0KDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gWWl6aG91DQo+IA0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTE9PUFMgW21haWx0bzpsb29wcy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbCBXZWx6bA0KPiBTZW50OiBUdWVzZGF5LCBK dW5lIDMwLCAyMDIwIDU6NDcgUE0NCj4gVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3Jn Pg0KPiBDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz47IGxvb3BzIDxsb29wc0BpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFtMT09QU10gQ2hhcnRlciBnaXRodWIgaXNzdWUgIzQ6IEVD Ti1Pbmx5DQo+IA0KPiANCj4gDQo+PiBPbiBKdW4gMzAsIDIwMjAsIGF0IDEwOjU3IEFNLCBDYXJz dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+Pj4gT24g MjAyMC0wNi0zMCwgYXQgMTA6NDksIExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+IHdyb3Rl Og0KPj4+IA0KPj4+IFNpZ25lZCBQR1AgcGFydA0KPj4+IEhpLA0KPj4+IA0KPj4+IE9uIDIwMjAt Ni0zMCwgYXQgMTE6MzksIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4+ Pj4gUmlnaHQuICBJdCBzZWVtcyB3ZSBoYXZlIG1pc3NlZCBvbmUgdXNlIGNhc2UgaGVyZTogVXNp bmcgTE9PUFMgdG8gDQo+Pj4+IGNvbnZlcnQgYSBkcm9wLWJhc2VkIHNlZ21lbnQgdG8gYW4gRUNO LW1hcmtpbmcgc2VnbWVudCAoZXZlcnkgbG9zcyANCj4+Pj4gYmVjb21lcyBhIENFLW1hcmtlZCBw YWNrZXQsIGJ1dCB0aGUgcGFja2V0IGlzIGFjdHVhbGx5IHRoZXJlIGFuZCANCj4+Pj4gbm90IGJl aW5nIGRyb3BwZWQpLiAgVGhlIGJlbmVmaXRzIGhlcmUgKGlmIHRoZSBzZWdtZW50IGlzIA0KPj4+ PiByZWxhdGl2ZWx5IHNob3J0KSBhcmUgaW4gbG93ZXIgbGF0ZW5jeSBmb3IgdGhlIGRldGVjdGlv biBhbmQgDQo+Pj4+IHJlY292ZXJ5LiAgKFRoZXJlIGlzIGFsc28gYSBtZXRhLWJlbmVmaXQgaW4g cHJvdmlkaW5nIG1vcmUgDQo+Pj4+IEVDTi1tYXJraW5nLikNCj4+PiANCj4+PiBzb3JyeSwgSSBk b24ndCBnZXQgdGhpcyB1c2UgY2FzZSwgY291bGQgeW91IGVsYWJvcmF0ZSBhIGJpdD8NCj4+PiAN Cj4+PiBJIHRob3VnaHQgdGhlIGJlbmVmaXQgb2YgTE9PUFMgd2FzIHRvIGhpZGUgYW55IGxvc3Mg b24gdGhlIExPT1BTIHNlZ21lbnQgZnJvbSB0aGUgZW5kcG9pbnRzLCBlaXRoZXIgYnkgbG9jYWwg UlRYIG9yIHJlY292ZXJ5IHZpYSBGRUMuIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGVyZSBhIHNpbWls YXIgYmVuZWZpdCB3b3VsZCBjb21lIGZyb20gaWYgeW91IGp1c3QgbWFyayAoYW5kIHRoZW4gc3Ry aXA/KSBFQ04/DQo+PiANCj4+IFRoZSBiZW5lZml0IHdvdWxkIGJlIGFjdHVhbGx5IGdldHRpbmcg dGhlIHBhY2tldCwgZmFzdC4NCj4+IFRoZSBiZW5lZml0IHdvdWxkIG5vdCBiZSBoaWRpbmcgdGhl IGxvc3MgZnJvbSB0aGUgY29uZ2VzdGlvbiBjb250cm9sLg0KPiANCj4gSSB0aGluayB0aGF04oCZ cyBhIGdyZWF0IGlkZWEhICBFLmcuLCB0aGlzIGNhbiByZWR1Y2UgaGVhZC1vZi1saW5lIGJsb2Nr aW5nICAoc2VlIFJGQyA4MDg3IGZvciBtb3JlKS4NCj4gDQo+IA0KPj4gDQo+PiBHcsO8w59lLCBD YXJzdGVuDQo+PiANCj4+IA0KPj4+PiBTbyB0aGlzIHdvdWxkIGFyZ3VlIGZvciBkZWZpbmluZyBM T09QUyBmb3IgdGhlIG5vbi1tYXJraW5nIHNlZ21lbnQgY2FzZSBhcyB3ZWxsLCBtYXliZSBzcGVj aWZpY2FsbHkgaWdub3JpbmcgYW55IGJlbmVmaXRzIGNvbWluZyBmcm9tIGRldGVjdGluZyBub24t Y29uZ2VzdGl2ZSBsb3NzZXMgYXMgc3VjaC4NCj4+PiANCj4+PiBJIGRvbid0IGdldCB0aGlzIGVp dGhlciwgc29ycnkuDQo+IA0KPiArMSwgdGhpcyBzZW50ZW5jZSBpcyBoYXJkIHRvIHBhcnNlLiBJ IGRvIGdldCB0aGUgZmlyc3QgaGFsZiBvZiBpdCB0aG91Z2gsIGFuZCBJIGFncmVlIHdpdGggaXQ6 IGlmIChhbmQgb25seSBpZikgdGhlIOKAnHJlYWwiIHNlbmRlciBhbmQgcmVjZWl2ZXIgc3BlYWsg RUNOLCB0aGVuIChldmVuIGlmIHRoZSBMT09QUyBzZWdtZW50IGRvZXNu4oCZdCBzdXBwb3J0IEVD TiksIGEgbG9zcyArIHJldHJhbnNtaXQgb24gdGhlIExPT1BTIHNlZ21lbnQgY2FuIGJlIHR1cm5l ZCBpbnRvIGEgc3VjY2Vzc2Z1bGx5IGZvcndhcmRlZCBwYWNrZXQgY2FycnlpbmcgQ0U9MSBieSB0 aGUgTE9PUFMgZWdyZXNzICh3ZWxsLCBpbiBmYWN0LCBtYXliZSB0aGUgaW5ncmVzcyB3b3VsZCBk byB0aGUgQ0U9MSBtYXJraW5nOyB3aGF0ZXZlciBpcyBtb3JlIGVmZmljaWVudCB0byBpbXBsZW1l bnQpLg0KPiANCj4gQ2hlZXJzLA0KPiBNaWNoYWVsDQo+IA0KPiAtLQ0KPiBMT09QUyBtYWlsaW5n IGxpc3QNCj4gTE9PUFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sb29wcw0KDQo= From nobody Wed Jul 1 02:14:47 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5EC3A0C54 for ; Wed, 1 Jul 2020 02:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 h13RXRPZOy71 for ; Wed, 1 Jul 2020 02:14:43 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A781A3A0C69 for ; Wed, 1 Jul 2020 02:14:43 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xbCQ1njtzyRj; Wed, 1 Jul 2020 11:14:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> Date: Wed, 1 Jul 2020 11:14:41 +0200 Cc: Liyizhou , Lars Eggert , loops X-Mao-Original-Outgoing-Id: 615287681.738319-51a5548ac6b1dcfd53a2aacbd2a01e4e Content-Transfer-Encoding: quoted-printable Message-Id: <6328FFD7-DB23-476D-B67E-9B6DC8393166@tzi.org> References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 09:14:46 -0000 On 2020-07-01, at 09:58, Michael Welzl wrote: >=20 > I am getting quite excited about this =E2=80=9Closs to ECN = conversion=E2=80=9D idea. I call it =E2=80=9Cdrop-to-mark=E2=80=9D conversion... > Right now, the lack of routers that really do apply ECN marking is the = missing piece in ECN deployment - so this opens a new option for gradual = deployment of ECN, where path segments containing non-ECN-enabled = routers can be changed into actually providing that signal without even = touching the routers in that segment. >=20 >=20 >> For non-fully ECN segment, a simple strategy of converting loss = signal to ECN can be used (ingress or egress TBD). >=20 > Yes. I was thinking in terms of separate use cases (fully ECN-enabled segment = vs. drop-to-mark conversion), but indeed, this is a continuum. >> For fully ECN segment, more strategic CE marking could be used. >=20 > I don=E2=80=99t understand this; what would such =E2=80=9Cmore = strategic CE marking=E2=80=9D be? Example: Instead of exporting exactly the marks that we see (or recover = from loss and then mark), the egress could run a equation-based = congestion control scheme for the segment and the inverse of that for = marking at egress. This is the =E2=80=9Cunilateral=E2=80=9D part that I was referring to in = a previous message. As with any equation-based scheme, this slows down the end-to-end = congestion response, but then it runs on a faster timescale (the segment = RTT), so that effect could be limited. Lars would rightly ask for some = research on this, first, but if that pans out, I think this will be a = likely way to run a LOOPS segment. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 1 02:18:31 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C971D3A0CA9 for ; Wed, 1 Jul 2020 02:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 R8dRte053218 for ; Wed, 1 Jul 2020 02:18:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7059D3A0CA6 for ; Wed, 1 Jul 2020 02:18:27 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xbHj6c2XzyX8; Wed, 1 Jul 2020 11:18:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> Date: Wed, 1 Jul 2020 11:18:25 +0200 Cc: Lars Eggert , loops X-Mao-Original-Outgoing-Id: 615287905.444342-347a5785674060d2a7369feab2967176 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 09:18:30 -0000 On 2020-06-30, at 11:47, Michael Welzl wrote: >=20 > maybe the ingress would do the CE=3D1 marking It could, but it would forgo the additional information that it would = get from an ECT marking. (This brings up the question how to translate the N+R measurements you = get from sending N original packets and R retransmissions down to N = packets forwarded from the egress. The conservative approach is to = CE-mark everything that was retransmitted, as apparently congestion was = experienced; this throws away the ECN information received in the = retransmitted packets. But that is intended to be locked down to a = small percentage, so maybe it is OK to ignore it.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 2 17:23:12 2020 Return-Path: X-Original-To: loops@ietf.org Delivered-To: loops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC41D3A0A64; Thu, 2 Jul 2020 17:20:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: loops@ietf.org, martin.h.duke@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563780.30173.1523017371903839518@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:37 -0700 Archived-At: Subject: [LOOPS] loops - Requested session has been scheduled for IETF 108 X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 00:20:50 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. loops Session 1 (1:40 requested) Friday, 31 July 2020, Session I 1100-1240 Room Name: Room 7 size: 7 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/loops.ics Request Information: --------------------------------------------------------- Working Group Name: Local Optimizations on Path Segments Area Name: Transport Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: nvo3 panrg intarea tsvwg quic rmcat taps tcpm People who must be present: Magnus Westerlund Martin Duke Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 5 09:49:20 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7B3A0407 for ; Sun, 5 Jul 2020 09:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 6Mma5oK_nnvo for ; Sun, 5 Jul 2020 09:49:15 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AC43A0403 for ; Sun, 5 Jul 2020 09:49:14 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B0F603SkJzyW0; Sun, 5 Jul 2020 18:49:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sun, 5 Jul 2020 18:49:12 +0200 X-Mao-Original-Outgoing-Id: 615660551.935284-2b175bdd0b872f0c8df54917d2fd1f66 Content-Transfer-Encoding: quoted-printable Message-Id: <136CD0E8-B92A-409E-A786-F44D74527CBC@tzi.org> References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 16:49:19 -0000 On 2020-07-01, at 10:19, Liyizhou wrote: >=20 > *** > Initially, LOOPS will focus on path segments that do not include = either end host. > *** >=20 > [yz] Agreed. This is now PR #7, https://github.com/loops-wg/charter/pull/7 : Based on the discussion on the list, I removed the restriction to = ECN-enabled (all routers) path segments. This puts us clearly on the "drop-to-mark" use case =E2=80=94 ECN marks = on the segment will be forwarded, but we also convert drops into marks = by marking recovered packets. This means end-to-end flows will not benefit from fewer congestion = events (which would enhance their throughput), but will benefit from = quick recovery (which will help reduce latency). Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 5 09:53:30 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089023A0598 for ; Sun, 5 Jul 2020 09:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 YYOWo28W4PRv for ; Sun, 5 Jul 2020 09:53:26 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2C73A059F for ; Sun, 5 Jul 2020 09:53:25 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B0FBr2lqTzyW0; Sun, 5 Jul 2020 18:53:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sun, 5 Jul 2020 18:53:23 +0200 X-Mao-Original-Outgoing-Id: 615660803.751246-5d776161f0d9c0e0ba64b6c717856210 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #5: Non-congestive loss X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 16:53:29 -0000 > I'm again unaware of any published information that this kind of = differentiation at the beginning of a congestion episode is actually = doable. Consistent with the resolution of #4 (PR #7), I removed all references = to detecting non-congestion losses in PR #8: https://github.com/loops-wg/charter/pull/8 This does not need to be in the minimum viable protocol and would slow = it down considerably. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 5 09:55:53 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F13A05AA for ; Sun, 5 Jul 2020 09:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QoadgJ9TsCvF for ; Sun, 5 Jul 2020 09:55:48 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0D93A05A0 for ; Sun, 5 Jul 2020 09:55:47 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B0FFY6kc7zyW0; Sun, 5 Jul 2020 18:55:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sun, 5 Jul 2020 18:55:45 +0200 X-Mao-Original-Outgoing-Id: 615660945.3385791-9b912120d1f31a5105e82c9f7a6e1586 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84DA1511-908E-49B5-8273-89E3904EF23B@tzi.org> <4a96814d-4f83-8880-832d-c464f64472a2@steinwurf.com> <41C89F17-C406-4F07-BDB7-1EFB4FB4EA64@eggert.org> <5C69910A-402F-4254-9843-FB838DA746B7@tzi.org> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] Charter github issue #6: FEC X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 16:55:51 -0000 On 2020-06-24, at 18:59, Morten V. Pedersen = wrote: >=20 >> =E2=80=9CDefault=E2=80=9D (hey, get this in so we get some interop): = Yes. >> "MTI" (you must put this in or you can=E2=80=99t play): probably not. >=20 > Sounds like a reasonable approach. I put in PR #9 to clarify this: https://github.com/loops-wg/charter/pull/9 Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 5 18:04:04 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41883A0CD7 for ; Sun, 5 Jul 2020 18:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 WtvoziCNMtJm for ; Sun, 5 Jul 2020 18:04:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 593D73A0CD6 for ; Sun, 5 Jul 2020 18:04:01 -0700 (PDT) Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 60C0F949A9EA364EFC30 for ; Mon, 6 Jul 2020 02:03:57 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 6 Jul 2020 02:03:56 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 6 Jul 2020 09:03:54 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Mon, 6 Jul 2020 09:03:54 +0800 From: Liyizhou To: Carsten Bormann , loops Thread-Topic: [LOOPS] Charter github issue #5: Non-congestive loss Thread-Index: AQHWTq8H8WO+ruMzOUymbHYrDut1a6j4thyAgAEOxqA= Date: Mon, 6 Jul 2020 01:03:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Charter github issue #5: Non-congestive loss X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 01:04:03 -0000 QWdyZWUgd2l0aCB0aGF0Lg0KDQpTdGFydGluZyBmcm9tIHRoZSBtaW5pbXVtIHNldCB3b3VsZCBi ZSBtb3JlIHByYWN0aWNhbC4NCg0KDQpSZ2RzLA0KWWl6aG91DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMT09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IE1vbmRheSwgSnVseSA2LCAyMDIwIDEy OjUzIEFNDQpUbzogbG9vcHMgPGxvb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtMT09QU10g Q2hhcnRlciBnaXRodWIgaXNzdWUgIzU6IE5vbi1jb25nZXN0aXZlIGxvc3MNCg0KPiBJJ20gYWdh aW4gdW5hd2FyZSBvZiBhbnkgcHVibGlzaGVkIGluZm9ybWF0aW9uIHRoYXQgdGhpcyBraW5kIG9m IGRpZmZlcmVudGlhdGlvbiBhdCB0aGUgYmVnaW5uaW5nIG9mIGEgY29uZ2VzdGlvbiBlcGlzb2Rl IGlzIGFjdHVhbGx5IGRvYWJsZS4NCg0KQ29uc2lzdGVudCB3aXRoIHRoZSByZXNvbHV0aW9uIG9m ICM0IChQUiAjNyksIEkgcmVtb3ZlZCBhbGwgcmVmZXJlbmNlcyB0byBkZXRlY3Rpbmcgbm9uLWNv bmdlc3Rpb24gbG9zc2VzIGluIFBSICM4Og0KDQpodHRwczovL2dpdGh1Yi5jb20vbG9vcHMtd2cv Y2hhcnRlci9wdWxsLzgNCg0KVGhpcyBkb2VzIG5vdCBuZWVkIHRvIGJlIGluIHRoZSBtaW5pbXVt IHZpYWJsZSBwcm90b2NvbCBhbmQgd291bGQgc2xvdyBpdCBkb3duIGNvbnNpZGVyYWJseS4NCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQotLSANCkxPT1BTIG1haWxpbmcgbGlzdA0KTE9PUFNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Mon Jul 6 01:38:59 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7113A11F1 for ; Mon, 6 Jul 2020 01:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 kq4H9k4nu7Ck for ; Mon, 6 Jul 2020 01:38:53 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by ietfa.amsl.com (Postfix) with ESMTP id B8C463A11F8 for ; Mon, 6 Jul 2020 01:38:50 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:54800.536469820 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-123.113.202.147?logid-5685d3ab3a1246deb0c17a0d1ebe2086 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 104F528009D; Mon, 6 Jul 2020 16:38:42 +0800 (CST) X-189-SAVE-TO-SEND: 71069678@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id 5685d3ab3a1246deb0c17a0d1ebe2086 for cabo@tzi.org; Mon Jul 6 16:38:48 2020 X-Transaction-ID: 5685d3ab3a1246deb0c17a0d1ebe2086 X-filter-score: filter<0> X-Real-From: wangjl50@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: wangjl50@chinatelecom.cn Date: Mon, 6 Jul 2020 16:38:41 +0800 From: wangjl50 To: cabo , loops References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org>, , , , <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org>, <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org>, <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no>, , <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no>, , <136CD0E8-B92A-409E-A786-F44D74527CBC@tzi.org> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.16.188[cn] Mime-Version: 1.0 Message-ID: <202007061153184363912@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart226624048611_=----" Archived-At: Subject: Re: [LOOPS] Charter github issue #4: ECN-Only X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 08:38:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart226624048611_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QmFzZWQgb24gdGhlIGRpc2N1c3Npb24sIEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZS4gVGhhbmsg eW91DQoNCkJlc3QgcmVnYXJkcw0KSmlhbmdsb25nDQoNCiANCkZyb206IENhcnN0ZW4gQm9ybWFu bg0KRGF0ZTogMjAyMC0wNy0wNiAwMDo0OQ0KVG86IGxvb3BzDQpTdWJqZWN0OiBSZTogW0xPT1BT XSBDaGFydGVyIGdpdGh1YiBpc3N1ZSAjNDogRUNOLU9ubHkNCk9uIDIwMjAtMDctMDEsIGF0IDEw OjE5LCBMaXlpemhvdSA8bGl5aXpob3VAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAqKioNCj4g SW5pdGlhbGx5LCBMT09QUyB3aWxsIGZvY3VzIG9uIHBhdGggc2VnbWVudHMgdGhhdCBkbyBub3Qg aW5jbHVkZSBlaXRoZXIgZW5kIGhvc3QuDQo+ICoqKg0KPiANCj4gW3l6XSBBZ3JlZWQuDQogDQpU aGlzIGlzIG5vdyBQUiAjNywgaHR0cHM6Ly9naXRodWIuY29tL2xvb3BzLXdnL2NoYXJ0ZXIvcHVs bC83IDoNCiANCkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0LCBJIHJlbW92ZWQg dGhlIHJlc3RyaWN0aW9uIHRvIEVDTi1lbmFibGVkIChhbGwgcm91dGVycykgcGF0aCBzZWdtZW50 cy4NCiANClRoaXMgcHV0cyB1cyBjbGVhcmx5IG9uIHRoZSAiZHJvcC10by1tYXJrIiB1c2UgY2Fz ZSDigJQgRUNOIG1hcmtzIG9uIHRoZSBzZWdtZW50IHdpbGwgYmUgZm9yd2FyZGVkLCBidXQgd2Ug YWxzbyBjb252ZXJ0IGRyb3BzIGludG8gbWFya3MgYnkgbWFya2luZyByZWNvdmVyZWQgcGFja2V0 cy4NClRoaXMgbWVhbnMgZW5kLXRvLWVuZCBmbG93cyB3aWxsIG5vdCBiZW5lZml0IGZyb20gZmV3 ZXIgY29uZ2VzdGlvbiBldmVudHMgKHdoaWNoIHdvdWxkIGVuaGFuY2UgdGhlaXIgdGhyb3VnaHB1 dCksIGJ1dCB3aWxsIGJlbmVmaXQgZnJvbSBxdWljayByZWNvdmVyeSAod2hpY2ggd2lsbCBoZWxw IHJlZHVjZSBsYXRlbmN5KS4NCiANCkdyw7zDn2UsIENhcnN0ZW4NCiANCi0tIA0KTE9PUFMgbWFp bGluZyBsaXN0DQpMT09QU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sb29wcw0K ------=_001_NextPart226624048611_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Based on the d= iscussion, I think it is reasonable. Thank you

Best regards
Jianglong

=0A
 
=
Date: 2020-07-06 00:49
To:&nb= sp;loops
Subject:&n= bsp;Re: [LOOPS] Charter github issue #4: ECN-Only
On 2020-07-01, at 10:19, Liyizhou <liyizhou@huawei.com> wrote:=0A
>
=0A
> ***
=0A
> Initially, LOOPS = will focus on path segments that do not include either end host.
=0A<= div>> ***
=0A
>
=0A
> [yz] Agreed.
=0A 
=0A
This is now PR #7, https://github.com/loops-wg/chart= er/pull/7 :
=0A
 
=0A
Based on the discussion on th= e list, I removed the restriction to ECN-enabled (all routers) path segmen= ts.
=0A
 
=0A
This puts us clearly on the "drop-to-= mark" use case =E2=80=94 ECN marks on the segment will be forwarded, but w= e also convert drops into marks by marking recovered packets.
=0AThis means end-to-end flows will not benefit from fewer congestion events= (which would enhance their throughput), but will benefit from quick recov= ery (which will help reduce latency).
=0A
 
=0A
Gr= =C3=BC=C3=9Fe, Carsten
=0A
 
=0A
--
=0A
L= OOPS mailing list
=0A
LOOPS@ietf.org
=0A
https://www.iet= f.org/mailman/listinfo/loops
=0A=0A ------=_001_NextPart226624048611_=------ From nobody Mon Jul 6 19:58:10 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C483A097B for ; Mon, 6 Jul 2020 19:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 zTQSky_s4spg for ; Mon, 6 Jul 2020 19:58:07 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D59F3A0978 for ; Mon, 6 Jul 2020 19:58:06 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb5f03e4b272d-4b353; Tue, 07 Jul 2020 10:57:55 +0800 (CST) X-RM-TRANSID: 2eeb5f03e4b272d-4b353 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[223.69.130.207]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee45f03e4b03e5-d34d2; Tue, 07 Jul 2020 10:57:54 +0800 (CST) X-RM-TRANSID: 2ee45f03e4b03e5-d34d2 From: "qinfengwei" To: "'Carsten Bormann'" , "'loops'" References: <8C2A2024-D501-4E63-A5DC-43C35784913E@tzi.org> <9A77B17E-CD8F-4FC4-92F8-4EEECB44FA00@eggert.org> <2A054D1D-A3AD-4FD5-9E7A-AEC344DC00A0@tzi.org> <5035FF20-46F0-4812-BBC6-4C000463DA8C@ifi.uio.no> <30994DE7-7D31-428C-B32C-8BC0E40D3FBA@ifi.uio.no> <136CD0E8-B92A-409E-A786-F44D74527CBC@tzi.org> In-Reply-To: <136CD0E8-B92A-409E-A786-F44D74527CBC@tzi.org> Date: Tue, 7 Jul 2020 10:57:56 +0800 Message-ID: <031701d6540a$6aab5db0$40021910$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdZS7D/KVuXKmjW1SielZGrFJOMnoQBHhbug Content-Language: zh-cn Archived-At: Subject: [LOOPS] =?utf-8?b?562U5aSNOiAgQ2hhcnRlciBnaXRodWIgaXNzdWUgIzQ6?= =?utf-8?q?_ECN-Only?= X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 02:58:10 -0000 Hi all, I agree with this idea. Thanks, Fengwei Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: LOOPS [mailto:loops-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Carsten Bormann =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=886=E6=97=A5 = 00:49 =E6=94=B6=E4=BB=B6=E4=BA=BA: loops =E4=B8=BB=E9=A2=98: Re: [LOOPS] Charter github issue #4: ECN-Only On 2020-07-01, at 10:19, Liyizhou wrote: >=20 > *** > Initially, LOOPS will focus on path segments that do not include = either end host. > *** >=20 > [yz] Agreed. This is now PR #7, https://github.com/loops-wg/charter/pull/7 : Based on the discussion on the list, I removed the restriction to = ECN-enabled (all routers) path segments. This puts us clearly on the "drop-to-mark" use case =E2=80=94 ECN marks = on the segment will be forwarded, but we also convert drops into marks = by marking recovered packets. This means end-to-end flows will not benefit from fewer congestion = events (which would enhance their throughput), but will benefit from = quick recovery (which will help reduce latency). Gr=C3=BC=C3=9Fe, Carsten --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops From nobody Mon Jul 6 23:34:25 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57363A0796 for ; Mon, 6 Jul 2020 23:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 KGnVZ42vN_ms for ; Mon, 6 Jul 2020 23:34:21 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E61B3A0798 for ; Mon, 6 Jul 2020 23:34:21 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B1CMV4Zl6zyhc; Tue, 7 Jul 2020 08:34:14 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615796453.940527-9173ecfecc3558ef88100bdb0ebd5dff Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 7 Jul 2020 08:34:14 +0200 Message-Id: <94A53546-8D02-419B-9EE5-98CF5E716E73@tzi.org> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Charter github issue #1: security, management, operations X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 06:34:24 -0000 In charter github issue #1 = , cabo writes: =C2=BB Either in the charter proposal itself or in the discussion below, we = should say more about security, management, and operations of a LOOPS = tunnel (comment from Colin Perkins). draft-ietf-tsvwg-transport-encrypt-05 might inform us here with some of = the issues to be addressed. A separate deliverable could expand on this, but we wouldn=E2=80=99t = want to ship the initial one (information model/protocol) without some = thinking about this, so I'm not sure such a deliverable should be called = out separately. We would like to keep the =E2=80=9Corchestrator=E2=80=9D that sets up = LOOPS segments as out of scope, though; this would likely be some form = of SDN controller for the overlay that we don=E2=80=99t have to = standardize to make LOOPS work. (Or maybe we want to standardize some = form of it later [as a YANG model?].) =C2=AB =20 Liyizhou writes: =C2=BB ACL can be used to direct traffic to LOOPS-enalbed tunnel. I think it is = very reasonable to keep the =E2=80=9Corchestrator=E2=80=9D stuff out of = scope. The =E2=80=9Corchestrator=E2=80=9D usually does more work besides = LOOPS enablement. It is also responsible for path selection in our demo = system. Hard to peel LOOPS alone from the whole orchestrator. So it is = not necessary to standardize the LOOPS setup part. I do not think YANG model needs to be included right now. It looks the = LOOPS setup now can be a simple KV configuration file, for example, = initial PSN, recovery mode (rtx/fec), no complex structure is required. =C2=AB I added a sentence about such a K/V configuration data set in: https://github.com/loops-wg/charter/pull/10 Does the charter need any more details on this? (E.g., do we need to explain how such a configuration protocol could be = secure?) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 7 01:56:29 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6C3A0794 for ; Tue, 7 Jul 2020 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 3ye2PFYvKu9P for ; Tue, 7 Jul 2020 01:56:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD253A005F for ; Tue, 7 Jul 2020 01:56:25 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4B1GWX1YBnzFqDX; Tue, 7 Jul 2020 10:56:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1594112184; bh=NiIA1BguWhmpD3DhNoiZFxTzB5Tm8758S25RNHNLhLo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=RN6VwLYMO1cHHa2ZJQ2205KMiQ9yKpOF2R0dtUYPWh4zud/TTr2JR8DhBjJrAUboG XUCVwk1ADHIZI+Se/PpON5//y/0v3vK/9osvIptSV/+78bMYO1krZEurNeXX8nRkc4 R4Cf3+Qmn1u+PFK7vSzaR2t72eI9nyhXbf/ifiuOFKiwOOj1dvb4XXaY82BCP5CsjP Roc06+aUcX7WbEdAldWH9cCMSxUZS8fAKxaoueOa2rfFehi7D5aF8OlkQYxWEUTu3a bDdRsPISFgWX1a2xOWpHlNCAv7VENSa0JxfYsm3g+tiyzSEoJxUr4HtFYCUIBLysRA ff2FyMTKQaEaA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4B1GWX0SFmz2xCM; Tue, 7 Jul 2020 10:56:24 +0200 (CEST) From: To: Carsten Bormann , loops Thread-Topic: [LOOPS] Charter github issue #1: security, management, operations Thread-Index: AQHWVCirnd9pg+r3GkSIQT9FZPDzc6j7zLfw Date: Tue, 7 Jul 2020 08:56:22 +0000 Message-ID: <26214_1594112184_5F0438B8_26214_243_10_787AE7BB302AE849A7480A190F8B9330314F126C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <94A53546-8D02-419B-9EE5-98CF5E716E73@tzi.org> In-Reply-To: <94A53546-8D02-419B-9EE5-98CF5E716E73@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] Charter github issue #1: security, management, operations X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 08:56:27 -0000 SGkgQ2Fyc3RlbiwgYWxsLA0KDQpMb29rcyBnb29kIHRvIG1lLg0KDQpJZiBORVRDT05GIG9yIFJF U1RDT0YgaXMgdXNlZCBmb3IgZXhhbXBsZSwgdGhleSB3aWxsIGNvbWUgd2l0aCB0aGUgYXBwcm9w cmlhdGUgc2VjdXJpdHkgdG9vbHMgdG8gZW5hYmxlIHRoZW0uIEknbSBub3Qgc3VyZSB3ZSBuZWVk IHRvIHRvdWNoIG9uIHRoaXMgaW4gdGhlIGNoYXJ0ZXIuIA0KDQpMaWtld2lzZSwgd2UgbWlnaHQg aW5kaWNhdGUgdGhhdCBzb21lIG5vLWNvbmZpZyBkYXRhIGNhbiBhbHNvIGJlIGV4cG9zZWQgdG8g YSBjb250cm9sbGVyIChlLmcuLCBlcnJvcnMpLiBTdWNoIGluZm8gY2FuIGJlIHVzZWQgdG8gdHdl YWsgYmFjayB0aGUgY29uZmlnIHBhcmFtZXRlcnMuIEJ1dCBhZ2FpbiBJIHRoaW5rIGFsbCB0aGVz ZSBhZGRpdGlvbnMgYXJlIGJldHRlciBoYW5kbGVkIGluIGEgc3BlYyByYXRoZXIgdGhhbiBhIGNo YXJ0ZXIgdGV4dC4gIA0KDQpDaGVlcnMsDQpNZWQgDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IExPT1BTIFttYWlsdG86bG9vcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBDYXJzdGVuIEJvcm1hbm4NCj4gRW52b3nDqcKgOiBtYXJkaSA3IGp1aWxsZXQg MjAyMCAwODozNA0KPiDDgMKgOiBsb29wcw0KPiBPYmpldMKgOiBbTE9PUFNdIENoYXJ0ZXIgZ2l0 aHViIGlzc3VlICMxOiBzZWN1cml0eSwgbWFuYWdlbWVudCwgb3BlcmF0aW9ucw0KPiANCj4gSW4g Y2hhcnRlciBnaXRodWIgaXNzdWUgIzEgPGh0dHBzOi8vZ2l0aHViLmNvbS9sb29wcy13Zy9jaGFy dGVyL2lzc3Vlcy8xPiwNCj4gY2FibyB3cml0ZXM6DQo+IA0KPiDCuw0KPiANCj4gRWl0aGVyIGlu IHRoZSBjaGFydGVyIHByb3Bvc2FsIGl0c2VsZiBvciBpbiB0aGUgZGlzY3Vzc2lvbiBiZWxvdywg d2Ugc2hvdWxkDQo+IHNheSBtb3JlIGFib3V0IHNlY3VyaXR5LCBtYW5hZ2VtZW50LCBhbmQgb3Bl cmF0aW9ucyBvZiBhIExPT1BTIHR1bm5lbA0KPiAoY29tbWVudCBmcm9tIENvbGluIFBlcmtpbnMp Lg0KPiANCj4gZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0wNSBtaWdodCBpbmZv cm0gdXMgaGVyZSB3aXRoIHNvbWUgb2YgdGhlDQo+IGlzc3VlcyB0byBiZSBhZGRyZXNzZWQuDQo+ IA0KPiBBIHNlcGFyYXRlIGRlbGl2ZXJhYmxlIGNvdWxkIGV4cGFuZCBvbiB0aGlzLCBidXQgd2Ug d291bGRu4oCZdCB3YW50IHRvIHNoaXANCj4gdGhlIGluaXRpYWwgb25lIChpbmZvcm1hdGlvbiBt b2RlbC9wcm90b2NvbCkgd2l0aG91dCBzb21lIHRoaW5raW5nIGFib3V0DQo+IHRoaXMsIHNvIEkn bSBub3Qgc3VyZSBzdWNoIGEgZGVsaXZlcmFibGUgc2hvdWxkIGJlIGNhbGxlZCBvdXQgc2VwYXJh dGVseS4NCj4gDQo+IFdlIHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUg4oCcb3JjaGVzdHJhdG9y4oCd IHRoYXQgc2V0cyB1cCBMT09QUyBzZWdtZW50cyBhcyBvdXQNCj4gb2Ygc2NvcGUsIHRob3VnaDsg dGhpcyB3b3VsZCBsaWtlbHkgYmUgc29tZSBmb3JtIG9mIFNETiBjb250cm9sbGVyIGZvciB0aGUN Cj4gb3ZlcmxheSB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0byBzdGFuZGFyZGl6ZSB0byBtYWtlIExP T1BTIHdvcmsuIChPciBtYXliZSB3ZQ0KPiB3YW50IHRvIHN0YW5kYXJkaXplIHNvbWUgZm9ybSBv ZiBpdCBsYXRlciBbYXMgYSBZQU5HIG1vZGVsP10uKQ0KPiANCj4gwqsNCj4gDQo+IExpeWl6aG91 IHdyaXRlczoNCj4gDQo+IMK7DQo+IA0KPiBBQ0wgY2FuIGJlIHVzZWQgdG8gZGlyZWN0IHRyYWZm aWMgdG8gTE9PUFMtZW5hbGJlZCB0dW5uZWwuIEkgdGhpbmsgaXQgaXMNCj4gdmVyeSByZWFzb25h YmxlIHRvIGtlZXAgdGhlIOKAnG9yY2hlc3RyYXRvcuKAnSBzdHVmZiBvdXQgb2Ygc2NvcGUuIFRo ZQ0KPiDigJxvcmNoZXN0cmF0b3LigJ0gdXN1YWxseSBkb2VzIG1vcmUgd29yayBiZXNpZGVzIExP T1BTIGVuYWJsZW1lbnQuIEl0IGlzIGFsc28NCj4gcmVzcG9uc2libGUgZm9yIHBhdGggc2VsZWN0 aW9uIGluIG91ciBkZW1vIHN5c3RlbS4gSGFyZCB0byBwZWVsIExPT1BTIGFsb25lDQo+IGZyb20g dGhlIHdob2xlIG9yY2hlc3RyYXRvci4gU28gaXQgaXMgbm90IG5lY2Vzc2FyeSB0byBzdGFuZGFy ZGl6ZSB0aGUNCj4gTE9PUFMgc2V0dXAgcGFydC4NCj4gDQo+IEkgZG8gbm90IHRoaW5rIFlBTkcg bW9kZWwgbmVlZHMgdG8gYmUgaW5jbHVkZWQgcmlnaHQgbm93LiBJdCBsb29rcyB0aGUNCj4gTE9P UFMgc2V0dXAgbm93IGNhbiBiZSBhIHNpbXBsZSBLViBjb25maWd1cmF0aW9uIGZpbGUsIGZvciBl eGFtcGxlLCBpbml0aWFsDQo+IFBTTiwgcmVjb3ZlcnkgbW9kZSAocnR4L2ZlYyksIG5vIGNvbXBs ZXggc3RydWN0dXJlIGlzIHJlcXVpcmVkLg0KPiANCj4gwqsNCj4gDQo+IEkgYWRkZWQgYSBzZW50 ZW5jZSBhYm91dCBzdWNoIGEgSy9WIGNvbmZpZ3VyYXRpb24gZGF0YSBzZXQgaW46DQo+IA0KPiBo dHRwczovL2dpdGh1Yi5jb20vbG9vcHMtd2cvY2hhcnRlci9wdWxsLzEwDQo+IA0KPiBEb2VzIHRo ZSBjaGFydGVyIG5lZWQgYW55IG1vcmUgZGV0YWlscyBvbiB0aGlzPw0KPiAoRS5nLiwgZG8gd2Ug bmVlZCB0byBleHBsYWluIGhvdyBzdWNoIGEgY29uZmlndXJhdGlvbiBwcm90b2NvbCBjb3VsZCBi ZQ0KPiBzZWN1cmU/KQ0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gLS0NCj4gTE9PUFMg bWFpbGluZyBsaXN0DQo+IExPT1BTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbG9vcHMNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Tue Jul 7 08:28:45 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF793A0E4B for ; Tue, 7 Jul 2020 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 MFBs7vPQS4jJ for ; Tue, 7 Jul 2020 08:28:42 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id DD3953A0E5B for ; Tue, 7 Jul 2020 08:28:41 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E934A1B0014F for ; Tue, 7 Jul 2020 16:28:38 +0100 (BST) To: loops@ietf.org From: Gorry Fairhurst Message-ID: Date: Tue, 7 Jul 2020 16:28:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 15:28:44 -0000 I have a few quetsions about then problem draft: Section 3.4 provides a use-case, which I would like to understand better: “By continuously measuring the delay of path segments    and use them as metrics for path selection, when the number of    overlay nodes is sufficiently large, there is a high chance that a    better path could be found". - This seems in part to rely upon measuring and the choosing which “disjoint segments” to forward over. A previous discussion asked how this would operate when the network itself implemented methods such as BGP and ECMP to do some form of traffic engineerinfg, and whether this introduced additional level of automatic re-routing would in some way conflict? - Is this decision within the network a good idea for stable oeprations? Is this a decision better made at the edge? Gorry From nobody Tue Jul 7 08:59:26 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F53A0E8D for ; Tue, 7 Jul 2020 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 n8rMuJlvyPEI for ; Tue, 7 Jul 2020 08:59:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0353A0E8A for ; Tue, 7 Jul 2020 08:59:20 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B1RvV6RM2zyTh; Tue, 7 Jul 2020 17:59:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Jul 2020 17:59:18 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 615830358.315416-4867ca2abdf4c797ac2d975ce8660f52 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 15:59:24 -0000 Hi Gorry, On 2020-07-07, at 17:28, Gorry Fairhurst wrote: >=20 > I have a few quetsions about then problem draft: >=20 > Section 3.4 provides a use-case, which I would like to understand = better: >=20 > =E2=80=9CBy continuously measuring the delay of path segments > and use them as metrics for path selection, when the number of > overlay nodes is sufficiently large, there is a high chance that a > better path could be found". Multipath operation is out of scope for the LOOPS activity that we are = presenting at the IETF108 BOF. Multipath is a valid use case for = in-network recovery, but I would expect we would want to combine the = considerable knowledge gained with MPTCP and various other multipathing = approaches (e.g., MPDCCP) before even defining the outline of a = standardizable solution. (Running LOOPS on a segment that is internally multipathed, or within a = single segment contributing to a multipath arrangement, should be = considerably simpler.) > - This seems in part to rely upon measuring and the choosing which = =E2=80=9Cdisjoint segments=E2=80=9D to forward over. A previous = discussion asked how this would operate when the network itself = implemented methods such as BGP and ECMP to do some form of traffic = engineerinfg, and whether this introduced additional level of automatic = re-routing would in some way conflict? For LOOPS at IETF108, we are trying to avoid control loops fighting = against each other. For people who enjoy those fights, we can always = ask to add it later. > - Is this decision within the network a good idea for stable = oeprations? Is this a decision better made at the edge? I=E2=80=99m not sure we know the answer to that. A vantage point within = the network may have better data, both with respect to the speed of = reaction (shorter RTTs for a partial path) and with respect to the = aggregated traffic volume providing better measurements. But you said = =E2=80=9Cat the edge=E2=80=9D, which is in the network=E2=80=A6 In any case, getting this right, over a wide range of operating points, = would be quite an accomplishment. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 7 09:46:38 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5897C3A08D4 for ; Tue, 7 Jul 2020 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nPP_lq91p_2q for ; Tue, 7 Jul 2020 09:46:34 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8205C3A08CC for ; Tue, 7 Jul 2020 09:46:34 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BECB31B00204; Tue, 7 Jul 2020 17:46:30 +0100 (BST) To: Carsten Bormann Cc: loops References: From: Gorry Fairhurst Message-ID: Date: Tue, 7 Jul 2020 17:46:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 16:46:36 -0000 Hi Carsten, OK, so if multipath operation is out of scope for the proposed LOOPS activity, what in scenario 3 of the problem statement remains in scope, relative to figure 2. While this scenario is in focus, can you explain section 3.1, this seems a discussion of TLP. Is this an “issue” fixed by RACK or have I missed something? I'm curious why you split RTP, bulk and other transfers apart in this case - to be sure, is this just to explain different merits of the same advocated approach, or is it that you see differentiation within the network based on flow type? Gorry On 07/07/2020 16:59, Carsten Bormann wrote: > Hi Gorry, > > On 2020-07-07, at 17:28, Gorry Fairhurst wrote: >> I have a few quetsions about then problem draft: >> >> Section 3.4 provides a use-case, which I would like to understand better: >> >> “By continuously measuring the delay of path segments >> and use them as metrics for path selection, when the number of >> overlay nodes is sufficiently large, there is a high chance that a >> better path could be found". > Multipath operation is out of scope for the LOOPS activity that we are presenting at the IETF108 BOF. Multipath is a valid use case for in-network recovery, but I would expect we would want to combine the considerable knowledge gained with MPTCP and various other multipathing approaches (e.g., MPDCCP) before even defining the outline of a standardizable solution. > > (Running LOOPS on a segment that is internally multipathed, or within a single segment contributing to a multipath arrangement, should be considerably simpler.) > >> - This seems in part to rely upon measuring and the choosing which “disjoint segments” to forward over. A previous discussion asked how this would operate when the network itself implemented methods such as BGP and ECMP to do some form of traffic engineerinfg, and whether this introduced additional level of automatic re-routing would in some way conflict? > For LOOPS at IETF108, we are trying to avoid control loops fighting against each other. For people who enjoy those fights, we can always ask to add it later. > >> - Is this decision within the network a good idea for stable oeprations? Is this a decision better made at the edge? > I’m not sure we know the answer to that. A vantage point within the network may have better data, both with respect to the speed of reaction (shorter RTTs for a partial path) and with respect to the aggregated traffic volume providing better measurements. But you said “at the edge”, which is in the network… > In any case, getting this right, over a wide range of operating points, would be quite an accomplishment. > > Grüße, Carsten From nobody Tue Jul 7 19:49:59 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53C3A0FEC for ; Tue, 7 Jul 2020 19:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 YNCvAS12nb0u for ; Tue, 7 Jul 2020 19:49:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3E3913A0D00 for ; Tue, 7 Jul 2020 19:49:56 -0700 (PDT) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7CADAE8A46537FA4ED8A for ; Wed, 8 Jul 2020 03:49:54 +0100 (IST) Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Jul 2020 03:49:53 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 8 Jul 2020 10:49:51 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 8 Jul 2020 10:49:51 +0800 From: Liyizhou To: Gorry Fairhurst , Carsten Bormann CC: loops Thread-Topic: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? Thread-Index: AQHWVHNZG1lfYKon4kG86id+E0NZIaj7wCAAgAANL4CAAQ+4YA== Date: Wed, 8 Jul 2020 02:49:51 +0000 Message-ID: <19d1f8379e464b70a00c025371a15e31@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 02:49:59 -0000 SGkgR29ycnkgYW5kIENhcnN0ZW4sDQoNClBsZWFzZSBzZWUgaW5saW5lcyB3aXRoIFt5el0NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExPT1BTIFttYWlsdG86bG9vcHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdvcnJ5IEZhaXJodXJzdA0KU2VudDogV2VkbmVz ZGF5LCBKdWx5IDgsIDIwMjAgMTI6NDYgQU0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHpp Lm9yZz4NCkNjOiBsb29wcyA8bG9vcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0xPT1BTXSBk cmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMtMDUgLSB3aHkgZG8gdHJh ZmZpYyBlbmdpbmVlcmluZyBhdCB0aGUgb3ZlcmxheSBhcyB3ZWxsPw0KDQpIaSBDYXJzdGVuLA0K DQpPSywgc28gaWYgbXVsdGlwYXRoIG9wZXJhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBw cm9wb3NlZCBMT09QUyBhY3Rpdml0eSwgd2hhdCBpbiBzY2VuYXJpbyAzIG9mIHRoZSBwcm9ibGVt IHN0YXRlbWVudCByZW1haW5zIGluIHNjb3BlLCByZWxhdGl2ZSB0byBmaWd1cmUgMi4NCg0KW3l6 XSBDdXJyZW50IHRleHQgb2YgbXVsdGktcGF0aGluZyBiYXNpY2FsbHkgcHJvdmlkZWQgd2h5IG11 bHRpLXBhdGhpbmcgZXhpc3RlZCBpbiB0aGUgc2NlbmFyaW8uIEFwcGx5aW5nIGluLW5ldHdvcmsg cmVjb3ZlcnkgdG8gc2VnbWVudHMgb2Ygb25lIG9mIHRoZSBwYXRocyBpcyBubyBtdWNoIGRpZmZl cmVuY2UgZnJvbSB0aGUgc2VnbWVudHMgb2YgYSBzaW5nbGUgcGF0aCBpbiBjdXJyZW50IHRleHQu IENvbnNpZGVyYXRpb24gb2YgdGhlIG9wZXJhdGlvbnMgb24gdGhlIGZvcmsgcG9pbnQgb2YgbXVs dGktcGF0aHMgd291bGQgZXhwb3NlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGJ1dCBpdCBpcyBv dXQgb2Ygc2NvcGUgZm9yIG5vdy4gU28gYSBzZXBhcmF0ZSBzZWN0aW9uIDMuNCBzZWVtcyBub3Qg dmVyeSBuZWNlc3NhcnkuIFdpbGwgZWRpdCBpdCBmb3IgbmV4dCByZXZpc2lvbi4gIA0KDQpXaGls ZSB0aGlzIHNjZW5hcmlvICBpcyBpbiBmb2N1cywgY2FuIHlvdSBleHBsYWluIHNlY3Rpb24gMy4x LCB0aGlzIHNlZW1zIGEgZGlzY3Vzc2lvbiBvZiBUTFAuIElzIHRoaXMgYW4g4oCcaXNzdWXigJ0g Zml4ZWQgYnkgUkFDSyBvciBoYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8NCg0KW3l6XSBZZXMsIGl0 IHRhbGtzIGFib3V0IG5lZ2F0aXZlIGltcGFjdCBvZiB0YWlsIGxvc3MuIFRMUCBpbiBSQUNLIHRy aWVzIHRvIGZpeCBpdC4gSW4gbXkgdW5kZXJzdGFuZGluZywgSW4tbmV0d29yayByZWNvdmVyeSAo TE9PUFMpIGNhbiBoZWxwIGluIHRoZSBjYXNlcyBvZjogMSkgc2VuZGVyIGhhcyBub3QgdXNlZCB0 aGUgdGltZSBiYXNlZCBsb3NzIGRldGVjdGlvbiBpbiBUQ1AsIG9yIG5vdCBhIFRDUCBzZW5kZXIu IDIpIFNlZ21lbnQgZGV0ZWN0cyB0aGUgbG9zcyBhbmQgdGhlbiByZWNvdmVyIGl0IGZhc3Rlciwg ZmlyZSBvZiBUTFAgdGltZXIgYXQgdGhlIHNlbmRlciBpcyByZWR1Y2VkIHdoZW4gUkFDSyBpcyBp biB1c2UuICANCg0KSSdtIGN1cmlvdXMgd2h5IHlvdSBzcGxpdCBSVFAsIGJ1bGsgYW5kIG90aGVy IHRyYW5zZmVycyBhcGFydCBpbiB0aGlzIGNhc2UgLSB0byBiZSBzdXJlLCBpcyB0aGlzIGp1c3Qg dG8gZXhwbGFpbiBkaWZmZXJlbnQgbWVyaXRzIG9mIHRoZSBzYW1lIGFkdm9jYXRlZCBhcHByb2Fj aCwgb3IgaXMgaXQgdGhhdCB5b3Ugc2VlIGRpZmZlcmVudGlhdGlvbiB3aXRoaW4gdGhlIG5ldHdv cmsgYmFzZWQgb24gZmxvdyB0eXBlPw0KDQpbeXpdIFRoaXMgdHJpZXMgdG8gc2hvdyB0aGF0IGlu LW5ldHdvcmsgcmVjb3ZlcnkgYnJpbmdzIGJlbmVmaXRzIHRvIGRpZmZlcmVudCB0eXBlcyBvZiB0 cmFuc3BvcnRlZCBkYXRhLiBDdXJyZW50IGRvYyBzdHJ1Y3R1cmUgc2VlbXMgYSBiaXQgY29uZnVz aW5nLiBDb3VsZCBiZSBpbnRlcnByZXRlZCBhcyB0aG9zZSBtZXJpdHMgb25seSBhcHBsaWNhYmxl IHRvIG9uZSBzY2VuYXJpby4gSW5kZWVkIHRoZXkgYXJlIGNvbW1vbiB0byBhbGwgc2NlbmFyaW9z LiBXaWxsIHJlLXN0cnVjdHVyZSB0aGUgc2VjdGlvbiBhbGlnbm1lbnQuIFRoYW5rIHlvdS4gICAN Cg0KR29ycnkNCg0KT24gMDcvMDcvMjAyMCAxNjo1OSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0K PiBIaSBHb3JyeSwNCj4NCj4gT24gMjAyMC0wNy0wNywgYXQgMTc6MjgsIEdvcnJ5IEZhaXJodXJz dCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+IHdyb3RlOg0KPj4gSSBoYXZlIGEgZmV3IHF1ZXRzaW9u cyBhYm91dCB0aGVuIHByb2JsZW0gZHJhZnQ6DQo+Pg0KPj4gU2VjdGlvbiAzLjQgcHJvdmlkZXMg YSB1c2UtY2FzZSwgd2hpY2ggSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgYmV0dGVyOg0KPj4N Cj4+IOKAnEJ5IGNvbnRpbnVvdXNseSBtZWFzdXJpbmcgdGhlIGRlbGF5IG9mIHBhdGggc2VnbWVu dHMNCj4+ICAgICBhbmQgdXNlIHRoZW0gYXMgbWV0cmljcyBmb3IgcGF0aCBzZWxlY3Rpb24sIHdo ZW4gdGhlIG51bWJlciBvZg0KPj4gICAgIG92ZXJsYXkgbm9kZXMgaXMgc3VmZmljaWVudGx5IGxh cmdlLCB0aGVyZSBpcyBhIGhpZ2ggY2hhbmNlIHRoYXQgYQ0KPj4gICAgIGJldHRlciBwYXRoIGNv dWxkIGJlIGZvdW5kIi4NCj4gTXVsdGlwYXRoIG9wZXJhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgZm9y IHRoZSBMT09QUyBhY3Rpdml0eSB0aGF0IHdlIGFyZSBwcmVzZW50aW5nIGF0IHRoZSBJRVRGMTA4 IEJPRi4gIE11bHRpcGF0aCBpcyBhIHZhbGlkIHVzZSBjYXNlIGZvciBpbi1uZXR3b3JrIHJlY292 ZXJ5LCBidXQgSSB3b3VsZCBleHBlY3Qgd2Ugd291bGQgd2FudCB0byBjb21iaW5lIHRoZSBjb25z aWRlcmFibGUga25vd2xlZGdlIGdhaW5lZCB3aXRoIE1QVENQIGFuZCB2YXJpb3VzIG90aGVyIG11 bHRpcGF0aGluZyBhcHByb2FjaGVzIChlLmcuLCBNUERDQ1ApIGJlZm9yZSBldmVuIGRlZmluaW5n IHRoZSBvdXRsaW5lIG9mIGEgc3RhbmRhcmRpemFibGUgc29sdXRpb24uDQo+DQo+IChSdW5uaW5n IExPT1BTIG9uIGEgc2VnbWVudCB0aGF0IGlzIGludGVybmFsbHkgbXVsdGlwYXRoZWQsIG9yIHdp dGhpbiANCj4gYSBzaW5nbGUgc2VnbWVudCBjb250cmlidXRpbmcgdG8gYSBtdWx0aXBhdGggYXJy YW5nZW1lbnQsIHNob3VsZCBiZSANCj4gY29uc2lkZXJhYmx5IHNpbXBsZXIuKQ0KPg0KPj4gLSBU aGlzIHNlZW1zIGluIHBhcnQgdG8gcmVseSB1cG9uIG1lYXN1cmluZyBhbmQgdGhlIGNob29zaW5n IHdoaWNoIOKAnGRpc2pvaW50IHNlZ21lbnRz4oCdIHRvIGZvcndhcmQgb3Zlci4gQSBwcmV2aW91 cyBkaXNjdXNzaW9uIGFza2VkIGhvdyB0aGlzIHdvdWxkIG9wZXJhdGUgd2hlbiB0aGUgbmV0d29y ayBpdHNlbGYgaW1wbGVtZW50ZWQgbWV0aG9kcyBzdWNoIGFzIEJHUCBhbmQgRUNNUCB0byBkbyBz b21lIGZvcm0gb2YgdHJhZmZpYyBlbmdpbmVlcmluZmcsIGFuZCB3aGV0aGVyIHRoaXMgaW50cm9k dWNlZCBhZGRpdGlvbmFsIGxldmVsIG9mIGF1dG9tYXRpYyByZS1yb3V0aW5nIHdvdWxkIGluIHNv bWUgd2F5IGNvbmZsaWN0Pw0KPiBGb3IgTE9PUFMgYXQgSUVURjEwOCwgd2UgYXJlIHRyeWluZyB0 byBhdm9pZCBjb250cm9sIGxvb3BzIGZpZ2h0aW5nIGFnYWluc3QgZWFjaCBvdGhlci4gIEZvciBw ZW9wbGUgd2hvIGVuam95IHRob3NlIGZpZ2h0cywgd2UgY2FuIGFsd2F5cyBhc2sgdG8gYWRkIGl0 IGxhdGVyLg0KPg0KPj4gLSBJcyB0aGlzIGRlY2lzaW9uIHdpdGhpbiB0aGUgbmV0d29yayBhIGdv b2QgaWRlYSBmb3Igc3RhYmxlIG9lcHJhdGlvbnM/IElzIHRoaXMgYSBkZWNpc2lvbiBiZXR0ZXIg bWFkZSBhdCB0aGUgZWRnZT8NCj4gSeKAmW0gbm90IHN1cmUgd2Uga25vdyB0aGUgYW5zd2VyIHRv IHRoYXQuICBBIHZhbnRhZ2UgcG9pbnQgd2l0aGluIHRoZSANCj4gbmV0d29yayBtYXkgaGF2ZSBi ZXR0ZXIgZGF0YSwgYm90aCB3aXRoIHJlc3BlY3QgdG8gdGhlIHNwZWVkIG9mIHJlYWN0aW9uIChz aG9ydGVyIFJUVHMgZm9yIGEgcGFydGlhbCBwYXRoKSBhbmQgd2l0aCByZXNwZWN0IHRvIHRoZSBh Z2dyZWdhdGVkIHRyYWZmaWMgdm9sdW1lIHByb3ZpZGluZyBiZXR0ZXIgbWVhc3VyZW1lbnRzLiAg QnV0IHlvdSBzYWlkIOKAnGF0IHRoZSBlZGdl4oCdLCB3aGljaCBpcyBpbiB0aGUgbmV0d29ya+KA piBJbiBhbnkgY2FzZSwgZ2V0dGluZyB0aGlzIHJpZ2h0LCBvdmVyIGEgd2lkZSByYW5nZSBvZiBv cGVyYXRpbmcgcG9pbnRzLCB3b3VsZCBiZSBxdWl0ZSBhbiBhY2NvbXBsaXNobWVudC4NCj4NCj4g R3LDvMOfZSwgQ2Fyc3Rlbg0KDQotLQ0KTE9PUFMgbWFpbGluZyBsaXN0DQpMT09QU0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sb29wcw0K From nobody Thu Jul 9 02:46:55 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731BB3A09EC for ; Thu, 9 Jul 2020 02:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 uHK9AGJo1mdi for ; Thu, 9 Jul 2020 02:46:52 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37F933A09EB for ; Thu, 9 Jul 2020 02:46:51 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 14F641B001D6; Thu, 9 Jul 2020 10:46:48 +0100 (BST) To: Liyizhou , Carsten Bormann Cc: loops References: <19d1f8379e464b70a00c025371a15e31@huawei.com> From: Gorry Fairhurst Message-ID: <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> Date: Thu, 9 Jul 2020 10:46:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <19d1f8379e464b70a00c025371a15e31@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 09:46:55 -0000 On 08/07/2020 03:49, Liyizhou wrote: > Hi Gorry and Carsten, > > Please see inlines with [yz] > > -----Original Message----- > From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Wednesday, July 8, 2020 12:46 AM > To: Carsten Bormann > Cc: loops > Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? > > Hi Carsten, > > OK, so if multipath operation is out of scope for the proposed LOOPS activity, what in scenario 3 of the problem statement remains in scope, relative to figure 2. > > [yz] Current text of multi-pathing basically provided why multi-pathing existed in the scenario. Applying in-network recovery to segments of one of the paths is no much difference from the segments of a single path in current text. Consideration of the operations on the fork point of multi-paths would expose additional requirements but it is out of scope for now. So a separate section 3.4 seems not very necessary. Will edit it for next revision. [gf] That would be really good to see soon, so I and others understand the planned scope. > > > While this scenario is in focus, can you explain section 3.1, this seems a discussion of TLP. Is this an “issue” fixed by RACK or have I missed something? > > [yz] Yes, it talks about negative impact of tail loss. TLP in RACK tries to fix it. In my understanding, In-network recovery (LOOPS) can help in the cases of: 1) sender has not used the time based loss detection in TCP, or not a TCP sender. 2) Segment detects the loss and then recover it faster, fire of TLP timer at the sender is reduced when RACK is in use. [gf] Why? I think I am missing something:  QUIC uses RACK-like recovery. Many TCP stacks are moving to do this. Why is this still a cricial thing to address within the network? > I'm curious why you split RTP, bulk and other transfers apart in this case - to be sure, is this just to explain different merits of the same advocated approach, or is it that you see differentiation within the network based on flow type? > > [yz] This tries to show that in-network recovery brings benefits to different types of transported data. Current doc structure seems a bit confusing. Could be interpreted as those merits only applicable to one scenario. Indeed they are common to all scenarios. Will re-structure the section alignment. Thank you. [gf] It would be good to clarify: So I think that I understand then the proposed methods are neutral to the type of traffic: That is, they will not expose details of the flow to the network to select different treatments? Gorry > Gorry > > On 07/07/2020 16:59, Carsten Bormann wrote: >> Hi Gorry, >> >> On 2020-07-07, at 17:28, Gorry Fairhurst wrote: >>> I have a few quetsions about then problem draft: >>> >>> Section 3.4 provides a use-case, which I would like to understand better: >>> >>> “By continuously measuring the delay of path segments >>> and use them as metrics for path selection, when the number of >>> overlay nodes is sufficiently large, there is a high chance that a >>> better path could be found". >> Multipath operation is out of scope for the LOOPS activity that we are presenting at the IETF108 BOF. Multipath is a valid use case for in-network recovery, but I would expect we would want to combine the considerable knowledge gained with MPTCP and various other multipathing approaches (e.g., MPDCCP) before even defining the outline of a standardizable solution. >> >> (Running LOOPS on a segment that is internally multipathed, or within >> a single segment contributing to a multipath arrangement, should be >> considerably simpler.) >> >>> - This seems in part to rely upon measuring and the choosing which “disjoint segments” to forward over. A previous discussion asked how this would operate when the network itself implemented methods such as BGP and ECMP to do some form of traffic engineerinfg, and whether this introduced additional level of automatic re-routing would in some way conflict? >> For LOOPS at IETF108, we are trying to avoid control loops fighting against each other. For people who enjoy those fights, we can always ask to add it later. >> >>> - Is this decision within the network a good idea for stable oeprations? Is this a decision better made at the edge? >> I’m not sure we know the answer to that. A vantage point within the >> network may have better data, both with respect to the speed of reaction (shorter RTTs for a partial path) and with respect to the aggregated traffic volume providing better measurements. But you said “at the edge”, which is in the network… In any case, getting this right, over a wide range of operating points, would be quite an accomplishment. >> >> Grüße, Carsten > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Thu Jul 9 02:57:58 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149AF3A011B for ; Thu, 9 Jul 2020 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 e8YsvM8ITZLP for ; Thu, 9 Jul 2020 02:57:55 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44E3A00E4 for ; Thu, 9 Jul 2020 02:57:54 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 38EF61B000A3 for ; Thu, 9 Jul 2020 10:57:53 +0100 (BST) To: loops References: <19d1f8379e464b70a00c025371a15e31@huawei.com> From: Gorry Fairhurst Message-ID: <22cf10dc-c85d-255b-8131-6f336b639029@erg.abdn.ac.uk> Date: Thu, 9 Jul 2020 10:57:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <19d1f8379e464b70a00c025371a15e31@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 09:57:57 -0000 Hi, I have questions about congetsion control will be performed. The problem statement says: “LOOPS (Local Optimizations on Path Segments) is a network-assisted    performance enhancement over path segment and it aims to provide    local in-network recovery to achieve better data delivery by making    packet loss recovery faster and by avoiding the senders over-reducing    their sending rate.  “ [gf] ... which seems interesting. Section 3.3 outlines precisely the problem that “In long-haul links, when the loss is caused by non-persistent burst    which is extremely short and pretty random, the sender's reaction of    reducing sending rate is not able to respond in time to the    instantaneous path situation or to mitigate such bursts.  On the    contrary, reducing window size at the sender unnecessarily or too    aggressively harms the throughput for application's long lasting    traffic like bulk data transfer.” [gf] ... Which sounds like it asks questions where I did not find an answer: How does the network segment differentiate between different pathologies that result in loss? I can imagine some random physical layer loss that isn't congestion. I can imagine some random loss that is a result of corruption in a shared media... which may or may not be link-layer congestion? How does the network segment know? So, one reason for asking is I saw these two statements, on informing the end-to-end transport protocol about congestion loss events that distinguish losses: "Existing tools such as ECN will be used." “ A more recent draft,    [I-D.ietf-tsvwg-tunnel-congestion-feedback], proposes to activate ECN    for the tunnel regardless of whether the end-to-end protocol signals    the use of an ECN-capable transport (ECT), which requires more    complicated action at the tunnel egress.” [gf] How does this help, please explain? ... The draft mentioned hasn't been changed since Jan 2017, and has not yet captured much experience or comment, so I am quite uneasy about predicting what will finally happen with thart draft. That aside, I'd like to understand how ECN helps in this case, since the congestion-control reaction seems a key part of any LOOPS method. Best wishes, Gorry From nobody Thu Jul 9 03:09:11 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62163A0853 for ; Thu, 9 Jul 2020 03:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 dGzP48e5tZ-W for ; Thu, 9 Jul 2020 03:09:00 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A17943A080B for ; Thu, 9 Jul 2020 03:09:00 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jtTU1-0009aF-4G; Thu, 09 Jul 2020 12:08:49 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.3]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jtTU0-000Agz-An; Thu, 09 Jul 2020 12:08:49 +0200 From: Michael Welzl Message-Id: <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_6730D12A-371A-40E6-B852-C96ABAD47639" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 9 Jul 2020 12:08:45 +0200 In-Reply-To: <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> Cc: Liyizhou , Carsten Bormann , loops To: " Fairhurst" References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.3]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FCF1E3C4BF55AD6D0A8E0BEE08780DED6184AA9A Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 10:09:10 -0000 --Apple-Mail=_6730D12A-371A-40E6-B852-C96ABAD47639 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99d like to answer one point below: >> While this scenario is in focus, can you explain section 3.1, this = seems a discussion of TLP. Is this an =E2=80=9Cissue=E2=80=9D fixed by = RACK or have I missed something? >>=20 >> [yz] Yes, it talks about negative impact of tail loss. TLP in RACK = tries to fix it. In my understanding, In-network recovery (LOOPS) can = help in the cases of: 1) sender has not used the time based loss = detection in TCP, or not a TCP sender. 2) Segment detects the loss and = then recover it faster, fire of TLP timer at the sender is reduced when = RACK is in use. > [gf] Why? I think I am missing something: QUIC uses RACK-like = recovery. Many TCP stacks are moving to do this. Why is this still a = cricial thing to address within the network? In QUIC, the PTO is based on an RTO type calculation. In RACK it used to = be 2*RTT, now I see an updated algorithm that makes 2*RTT a lower bound = (or 1 sec in the absence of RTT samples). Either way, this is multiple e2e RTTs - that=E2=80=99s potentially much, = much longer than a LOOPS retransmission. Cheers, Michael --Apple-Mail=_6730D12A-371A-40E6-B852-C96ABAD47639 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99d like to answer one point below:


While this scenario  is in = focus, can you explain section 3.1, this seems a discussion of TLP. Is = this an =E2=80=9Cissue=E2=80=9D fixed by RACK or have I missed = something?

[yz] Yes, it talks about = negative impact of tail loss. TLP in RACK tries to fix it. In my = understanding, In-network recovery (LOOPS) can help in the cases of: 1) = sender has not used the time based loss detection in TCP, or not a TCP = sender. 2) Segment detects the loss and then recover it faster, fire of = TLP timer at the sender is reduced when RACK is in use.
[gf] Why? I think I am missing something:  QUIC uses = RACK-like recovery. Many TCP stacks are moving to do this. Why is this = still a cricial thing to address within the network?

In QUIC, = the PTO is based on an RTO type calculation. In RACK it used to be = 2*RTT, now I see an updated algorithm that makes 2*RTT a lower bound (or = 1 sec in the absence of RTT samples).
Either way, this is = multiple e2e RTTs - that=E2=80=99s potentially much, much longer than a = LOOPS retransmission.

Cheers,
Michael

= --Apple-Mail=_6730D12A-371A-40E6-B852-C96ABAD47639-- From nobody Thu Jul 9 03:32:38 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1968C3A0863 for ; Thu, 9 Jul 2020 03:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 4FYxfD39H3qV for ; Thu, 9 Jul 2020 03:32:28 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4A3A0880 for ; Thu, 9 Jul 2020 03:32:27 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2FADC1B001D6; Thu, 9 Jul 2020 11:32:20 +0100 (BST) To: Michael Welzl Cc: Liyizhou , Carsten Bormann , loops References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> From: Gorry Fairhurst Message-ID: Date: Thu, 9 Jul 2020 11:32:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------A22435D4137FAE2E8D98792D" Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 10:32:37 -0000 This is a multi-part message in MIME format. --------------A22435D4137FAE2E8D98792D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/07/2020 11:08, Michael Welzl wrote: > Hi, > > I’d like to answer one point below: > > >>> While this scenario  is in focus, can you explain section 3.1, this >>> seems a discussion of TLP. Is this an “issue” fixed by RACK or have >>> I missed something? >>> >>> [yz] Yes, it talks about negative impact of tail loss. TLP in RACK >>> tries to fix it. In my understanding, In-network recovery (LOOPS) >>> can help in the cases of: 1) sender has not used the time based loss >>> detection in TCP, or not a TCP sender. 2) Segment detects the loss >>> and then recover it faster, fire of TLP timer at the sender is >>> reduced when RACK is in use. >> [gf] Why? I think I am missing something:  QUIC uses RACK-like >> recovery. Many TCP stacks are moving to do this. Why is this still a >> cricial thing to address within the network? > > In QUIC, the PTO is based on an RTO type calculation. In RACK it used > to be 2*RTT, now I see an updated algorithm that makes 2*RTT a lower > bound (or 1 sec in the absence of RTT samples). > Either way, this is multiple e2e RTTs - that’s potentially much, much > longer than a LOOPS retransmission. > > Cheers, > Michael > Depending on how TLP works, I see this could be a gain. (In QUIC, PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay.) - For a bulk app. Isn't the gain only when the last segment(s) are lost, and such a transfer is already many RTTs, and probably includes some other losses with additional delay. So it saves one PTO-time in a large number of RTTs? - For short transactions (or bursts of activity within a flow), there can be a much bigger potential proportional benefit. It would be interesting to see how much of a gain this really is? Gorry --------------A22435D4137FAE2E8D98792D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 09/07/2020 11:08, Michael Welzl wrote:
Hi,

I’d like to answer one point below:


While this scenario  is in focus, can you explain section 3.1, this seems a discussion of TLP. Is this an “issue” fixed by RACK or have I missed something?

[yz] Yes, it talks about negative impact of tail loss. TLP in RACK tries to fix it. In my understanding, In-network recovery (LOOPS) can help in the cases of: 1) sender has not used the time based loss detection in TCP, or not a TCP sender. 2) Segment detects the loss and then recover it faster, fire of TLP timer at the sender is reduced when RACK is in use.
[gf] Why? I think I am missing something:  QUIC uses RACK-like recovery. Many TCP stacks are moving to do this. Why is this still a cricial thing to address within the network?

In QUIC, the PTO is based on an RTO type calculation. In RACK it used to be 2*RTT, now I see an updated algorithm that makes 2*RTT a lower bound (or 1 sec in the absence of RTT samples).
Either way, this is multiple e2e RTTs - that’s potentially much, much longer than a LOOPS retransmission.

Cheers,
Michael

Depending on how TLP works, I see this could be a gain. (In QUIC, PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay.)

- For a bulk app. Isn't the gain only when the last segment(s) are lost, and such a transfer is already many RTTs, and probably includes some other losses with additional delay. So it saves one PTO-time in a large number of RTTs?

- For short transactions (or bursts of activity within a flow), there can be a much bigger potential proportional benefit.

It would be interesting to see how much of a gain this really is?

Gorry

--------------A22435D4137FAE2E8D98792D-- From nobody Thu Jul 9 04:45:29 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1CE3A08C1 for ; Thu, 9 Jul 2020 04:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 jNvfUV5tbD3o for ; Thu, 9 Jul 2020 04:45:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1E9E53A0856 for ; Thu, 9 Jul 2020 04:45:24 -0700 (PDT) Received: from lhreml715-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F1159CDB99B95E8A2CA5 for ; Thu, 9 Jul 2020 12:45:21 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 9 Jul 2020 12:45:21 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 9 Jul 2020 19:45:18 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 9 Jul 2020 19:45:18 +0800 From: Liyizhou To: Gorry Fairhurst , loops Thread-Topic: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion? Thread-Index: AQHWVdd3tJCt0L/Tgkyi8192KbrF86j/HBew Date: Thu, 9 Jul 2020 11:45:18 +0000 Message-ID: <7dae586c9a0546d1a4be411b7b6391d7@huawei.com> References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <22cf10dc-c85d-255b-8131-6f336b639029@erg.abdn.ac.uk> In-Reply-To: <22cf10dc-c85d-255b-8131-6f336b639029@erg.abdn.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 11:45:27 -0000 SGkgR29ycnksDQoNCkJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBpbiB0aGUgbWFpbGluZyBsaXN0 LCB3ZSBzaG91bGQgaGF2ZSByZW1vdmVkIGFsbHVzaW9ucyB0byBiZWluZyBhYmxlIHRvIGRldGVj dCBub24tY29uZ2VzdGlvbiBsb3NzZXMgZnJvbSB0aGUgZHJhZnQuIFRoaXMgZ2l0aHViIGlzc3Vl IHdhcyBjbG9zZWQgYWJvdXQgc2FtZSB0aW1lIGFzIHRoZSBkcmFmdCB1cGxvYWRpbmcuIEhlbmNl IHRoZSBkcmFmdCBkaWQgbm90IGFic29yYiBhbGwgdGhlIGNvbmNsdXNpb25zLiBTb3JyeSBhYm91 dCB0aGF0Lg0KDQpDdXJyZW50IHNjb3BlIGZvY3VzZXMgb24gZHJvcC10by1tYXJrIGFwcHJvYWNo IHdpdGhvdXQgdHJ5aW5nIHRvIGRldGVjdCBub24tY29uZ2VzdGlvbiBsb3NzLg0KDQpXaWxsIHVw ZGF0ZSB0aGUgZHJhZnQgYnkgdGhpcyB3ZWVrIHRvIHJlZmxlY3QgdGhlIG1vc3QgcmVjZW50IGNv bnNlbnN1cyAodG9nZXRoZXIgd2l0aCB0aG9zZSBtZW50aW9uZWQgaW4geW91ciBwcmV2aW91cyBl bWFpbCkuIA0KDQpSZ2RzLA0KWWl6aG91DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMT09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBH b3JyeSBGYWlyaHVyc3QNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDksIDIwMjAgNTo1OCBQTQ0KVG86 IGxvb3BzIDxsb29wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTE9PUFNdIGRyYWZ0LWxpLXRz dndnLWxvb3BzLXByb2JsZW0tb3Bwb3J0dW5pdGllcy0wNSAtIEhvdyBkbyBlbmRwb2ludHMgdW5k ZXJzdGFuZCBjb25nZXN0aW9uPw0KDQpIaSwNCg0KSSBoYXZlIHF1ZXN0aW9ucyBhYm91dCBjb25n ZXRzaW9uIGNvbnRyb2wgd2lsbCBiZSBwZXJmb3JtZWQuIFRoZSBwcm9ibGVtIHN0YXRlbWVudCBz YXlzOg0KDQoNCuKAnExPT1BTIChMb2NhbCBPcHRpbWl6YXRpb25zIG9uIFBhdGggU2VnbWVudHMp IGlzIGEgbmV0d29yay1hc3Npc3RlZA0KIMKgwqAgcGVyZm9ybWFuY2UgZW5oYW5jZW1lbnQgb3Zl ciBwYXRoIHNlZ21lbnQgYW5kIGl0IGFpbXMgdG8gcHJvdmlkZQ0KIMKgwqAgbG9jYWwgaW4tbmV0 d29yayByZWNvdmVyeSB0byBhY2hpZXZlIGJldHRlciBkYXRhIGRlbGl2ZXJ5IGJ5IG1ha2luZw0K IMKgwqAgcGFja2V0IGxvc3MgcmVjb3ZlcnkgZmFzdGVyIGFuZCBieSBhdm9pZGluZyB0aGUgc2Vu ZGVycyBvdmVyLXJlZHVjaW5nDQogwqDCoCB0aGVpciBzZW5kaW5nIHJhdGUuwqAg4oCcDQoNCltn Zl0gLi4uIHdoaWNoIHNlZW1zIGludGVyZXN0aW5nLg0KDQpTZWN0aW9uIDMuMyBvdXRsaW5lcyBw cmVjaXNlbHkgdGhlIHByb2JsZW0gdGhhdA0K4oCcSW4gbG9uZy1oYXVsIGxpbmtzLCB3aGVuIHRo ZSBsb3NzIGlzIGNhdXNlZCBieSBub24tcGVyc2lzdGVudCBidXJzdA0KIMKgwqAgd2hpY2ggaXMg ZXh0cmVtZWx5IHNob3J0IGFuZCBwcmV0dHkgcmFuZG9tLCB0aGUgc2VuZGVyJ3MgcmVhY3Rpb24g b2YNCiDCoMKgIHJlZHVjaW5nIHNlbmRpbmcgcmF0ZSBpcyBub3QgYWJsZSB0byByZXNwb25kIGlu IHRpbWUgdG8gdGhlDQogwqDCoCBpbnN0YW50YW5lb3VzIHBhdGggc2l0dWF0aW9uIG9yIHRvIG1p dGlnYXRlIHN1Y2ggYnVyc3RzLsKgIE9uIHRoZQ0KIMKgwqAgY29udHJhcnksIHJlZHVjaW5nIHdp bmRvdyBzaXplIGF0IHRoZSBzZW5kZXIgdW5uZWNlc3NhcmlseSBvciB0b28NCiDCoMKgIGFnZ3Jl c3NpdmVseSBoYXJtcyB0aGUgdGhyb3VnaHB1dCBmb3IgYXBwbGljYXRpb24ncyBsb25nIGxhc3Rp bmcNCiDCoMKgIHRyYWZmaWMgbGlrZSBidWxrIGRhdGEgdHJhbnNmZXIu4oCdDQoNCltnZl0gLi4u IFdoaWNoIHNvdW5kcyBsaWtlIGl0IGFza3MgcXVlc3Rpb25zIHdoZXJlIEkgZGlkIG5vdCBmaW5k IGFuIA0KYW5zd2VyOiBIb3cgZG9lcyB0aGUgbmV0d29yayBzZWdtZW50IGRpZmZlcmVudGlhdGUg YmV0d2VlbiBkaWZmZXJlbnQgDQpwYXRob2xvZ2llcyB0aGF0IHJlc3VsdCBpbiBsb3NzPyBJIGNh biBpbWFnaW5lIHNvbWUgcmFuZG9tIHBoeXNpY2FsIA0KbGF5ZXIgbG9zcyB0aGF0IGlzbid0IGNv bmdlc3Rpb24uIEkgY2FuIGltYWdpbmUgc29tZSByYW5kb20gbG9zcyB0aGF0IGlzIA0KYSByZXN1 bHQgb2YgY29ycnVwdGlvbiBpbiBhIHNoYXJlZCBtZWRpYS4uLiB3aGljaCBtYXkgb3IgbWF5IG5v dCBiZSANCmxpbmstbGF5ZXIgY29uZ2VzdGlvbj8gSG93IGRvZXMgdGhlIG5ldHdvcmsgc2VnbWVu dCBrbm93Pw0KDQpTbywgb25lIHJlYXNvbiBmb3IgYXNraW5nIGlzIEkgc2F3IHRoZXNlIHR3byBz dGF0ZW1lbnRzLCBvbiBpbmZvcm1pbmcgDQp0aGUgZW5kLXRvLWVuZCB0cmFuc3BvcnQgcHJvdG9j b2wgYWJvdXQgY29uZ2VzdGlvbiBsb3NzIGV2ZW50cyB0aGF0IA0KZGlzdGluZ3Vpc2ggbG9zc2Vz Og0KDQoiRXhpc3RpbmcgdG9vbHMgc3VjaCBhcyBFQ04gd2lsbCBiZSB1c2VkLiINCg0K4oCcIEEg bW9yZSByZWNlbnQgZHJhZnQsDQogwqDCoCBbSS1ELmlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rp b24tZmVlZGJhY2tdLCBwcm9wb3NlcyB0byBhY3RpdmF0ZSBFQ04NCiDCoMKgIGZvciB0aGUgdHVu bmVsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgZW5kLXRvLWVuZCBwcm90b2NvbCBzaWduYWxz DQogwqDCoCB0aGUgdXNlIG9mIGFuIEVDTi1jYXBhYmxlIHRyYW5zcG9ydCAoRUNUKSwgd2hpY2gg cmVxdWlyZXMgbW9yZQ0KIMKgwqAgY29tcGxpY2F0ZWQgYWN0aW9uIGF0IHRoZSB0dW5uZWwgZWdy ZXNzLuKAnQ0KDQpbZ2ZdIEhvdyBkb2VzIHRoaXMgaGVscCwgcGxlYXNlIGV4cGxhaW4/DQoNCi4u LiBUaGUgZHJhZnQgbWVudGlvbmVkIGhhc24ndCBiZWVuIGNoYW5nZWQgc2luY2UgSmFuIDIwMTcs IGFuZCBoYXMgbm90IA0KeWV0IGNhcHR1cmVkIG11Y2ggZXhwZXJpZW5jZSBvciBjb21tZW50LCBz byBJIGFtIHF1aXRlIHVuZWFzeSBhYm91dCANCnByZWRpY3Rpbmcgd2hhdCB3aWxsIGZpbmFsbHkg aGFwcGVuIHdpdGggdGhhcnQgZHJhZnQuIFRoYXQgYXNpZGUsIEknZCANCmxpa2UgdG8gdW5kZXJz dGFuZCBob3cgRUNOIGhlbHBzIGluIHRoaXMgY2FzZSwgc2luY2UgdGhlIA0KY29uZ2VzdGlvbi1j b250cm9sIHJlYWN0aW9uIHNlZW1zIGEga2V5IHBhcnQgb2YgYW55IExPT1BTIG1ldGhvZC4NCg0K QmVzdCB3aXNoZXMsDQoNCkdvcnJ5DQoNCg0KLS0gDQpMT09QUyBtYWlsaW5nIGxpc3QNCkxPT1BT QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xvb3BzDQo= From nobody Thu Jul 9 05:17:45 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23923A0922 for ; Thu, 9 Jul 2020 05:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 dlkk-ue8a5BP for ; Thu, 9 Jul 2020 05:17:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651833A0921 for ; Thu, 9 Jul 2020 05:17:41 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B2Ztr30YYzyVJ; Thu, 9 Jul 2020 14:17:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <26214_1594112184_5F0438B8_26214_243_10_787AE7BB302AE849A7480A190F8B9330314F126C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 9 Jul 2020 14:17:39 +0200 X-Mao-Original-Outgoing-Id: 615989859.596962-2db6da0f594035deb8b7db2ddb6e0a7c Content-Transfer-Encoding: quoted-printable Message-Id: <4304D3D9-1BAB-4D23-84E7-D4E6BFDD73DA@tzi.org> References: <94A53546-8D02-419B-9EE5-98CF5E716E73@tzi.org> <26214_1594112184_5F0438B8_26214_243_10_787AE7BB302AE849A7480A190F8B9330314F126C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: loops X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [LOOPS] Remaining issues (Re: Charter github issue #1: security, management, operations) X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 12:17:45 -0000 So I have merged the PR #10. I also merged #9, which is closing issue #6. Issue #2 is still open. In the side meeting on 2020-05-26, we seemed to have consensus to cut = down the number of WGs/RGs we explicitly mention, and while I agree that = PANRG is a group to watch, I see little interaction with the minimum = viable protocol (MVP) that we are targeting for chartering now. So = I=E2=80=99m considering closing this as well now. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 9 05:26:10 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC303A096E for ; Thu, 9 Jul 2020 05:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 PBx62AsSWs7S for ; Thu, 9 Jul 2020 05:26:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D4D3A096D for ; Thu, 9 Jul 2020 05:26:05 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B2b4W5lWGzyTZ; Thu, 9 Jul 2020 14:26:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 9 Jul 2020 14:26:03 +0200 Cc: Michael Welzl , loops , Liyizhou X-Mao-Original-Outgoing-Id: 615990363.2160389-8d4e2ce9b427c1cfe671ca573d106794 Content-Transfer-Encoding: quoted-printable Message-Id: <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 12:26:09 -0000 On 2020-07-09, at 12:32, Gorry Fairhurst wrote: >=20 > - For short transactions (or bursts of activity within a flow), there = can be a much bigger potential proportional benefit.=20 Indeed. I think the recent discussions have arrived at the conclusion = that the minimum viable protocol (MVP) we are targeting now, will be = beneficial for ants and for transactional flows (flows that stop and = restart), less so for throughput-bound flows. Essentially we get the = benefits 2.1 to 2.4 listed in RFC 8087. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 9 05:35:59 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA583A099B for ; Thu, 9 Jul 2020 05:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 yeugNL8w8uxE for ; Thu, 9 Jul 2020 05:35:55 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 360783A099A for ; Thu, 9 Jul 2020 05:35:55 -0700 (PDT) Received: from [192.168.1.74] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 07CA01B001D6; Thu, 9 Jul 2020 13:35:52 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Gorry Fairhurst Mime-Version: 1.0 (1.0) Date: Thu, 9 Jul 2020 13:35:51 +0100 Message-Id: References: <7dae586c9a0546d1a4be411b7b6391d7@huawei.com> Cc: loops In-Reply-To: <7dae586c9a0546d1a4be411b7b6391d7@huawei.com> To: Liyizhou X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 12:35:57 -0000 Thanks - I look forward to reading a clean set of drafts. Gorrt > On 9 Jul 2020, at 12:45, Liyizhou wrote: >=20 > =EF=BB=BFHi Gorry, >=20 > Based on the discussions in the mailing list, we should have removed allus= ions to being able to detect non-congestion losses from the draft. This gith= ub issue was closed about same time as the draft uploading. Hence the draft d= id not absorb all the conclusions. Sorry about that. >=20 > Current scope focuses on drop-to-mark approach without trying to detect no= n-congestion loss. >=20 > Will update the draft by this week to reflect the most recent consensus (t= ogether with those mentioned in your previous email).=20 >=20 > Rgds, > Yizhou >=20 > -----Original Message----- > From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Thursday, July 9, 2020 5:58 PM > To: loops > Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How d= o endpoints understand congestion? >=20 > Hi, >=20 > I have questions about congetsion control will be performed. The problem s= tatement says: >=20 >=20 > =E2=80=9CLOOPS (Local Optimizations on Path Segments) is a network-assiste= d > performance enhancement over path segment and it aims to provide > local in-network recovery to achieve better data delivery by making > packet loss recovery faster and by avoiding the senders over-reducing > their sending rate. =E2=80=9C >=20 > [gf] ... which seems interesting. >=20 > Section 3.3 outlines precisely the problem that > =E2=80=9CIn long-haul links, when the loss is caused by non-persistent bur= st > which is extremely short and pretty random, the sender's reaction of > reducing sending rate is not able to respond in time to the > instantaneous path situation or to mitigate such bursts. On the > contrary, reducing window size at the sender unnecessarily or too > aggressively harms the throughput for application's long lasting > traffic like bulk data transfer.=E2=80=9D >=20 > [gf] ... Which sounds like it asks questions where I did not find an=20 > answer: How does the network segment differentiate between different=20 > pathologies that result in loss? I can imagine some random physical=20 > layer loss that isn't congestion. I can imagine some random loss that is=20= > a result of corruption in a shared media... which may or may not be=20 > link-layer congestion? How does the network segment know? >=20 > So, one reason for asking is I saw these two statements, on informing=20 > the end-to-end transport protocol about congestion loss events that=20 > distinguish losses: >=20 > "Existing tools such as ECN will be used." >=20 > =E2=80=9C A more recent draft, > [I-D.ietf-tsvwg-tunnel-congestion-feedback], proposes to activate ECN > for the tunnel regardless of whether the end-to-end protocol signals > the use of an ECN-capable transport (ECT), which requires more > complicated action at the tunnel egress.=E2=80=9D >=20 > [gf] How does this help, please explain? >=20 > ... The draft mentioned hasn't been changed since Jan 2017, and has not=20= > yet captured much experience or comment, so I am quite uneasy about=20 > predicting what will finally happen with thart draft. That aside, I'd=20 > like to understand how ECN helps in this case, since the=20 > congestion-control reaction seems a key part of any LOOPS method. >=20 > Best wishes, >=20 > Gorry >=20 >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Thu Jul 9 06:06:50 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AD63A09AC for ; Thu, 9 Jul 2020 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 bAZ-59kgLctN for ; Thu, 9 Jul 2020 06:06:47 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9073A09A4 for ; Thu, 9 Jul 2020 06:06:47 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4B2bzT5qD3zCrVL; Thu, 9 Jul 2020 15:06:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1594300005; bh=Kq9Wj85oohHHuwBlui74PNnf0gRMlrs/fI9SJOvLw1s=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=XW2sMDq377SXnR+DBVzI9XT12obD44xEh3A0I0ObdF4ixgvsDFBna/N9OUoHAbb9D T/RpdXP323rXI1dRTyxJHD877HX6YulNtRLk5hXyJTqMfgxDtBrO9CKAKjXgnVzhEP g0p4DNQXSddXBTF0UWreETUi8k7aHlXt3ku90NkHABPP+C3A6nZPIBslSdvRqpFPRQ so+2FKN0/0TRhTIaZDqYAF8kWuEdDF75Cmws/PnHAoAl1z7qVRSeH6rAvpZuDj+Zmc lZW3uNcDFGd9Su3+GISar22erO8zH3YT7K5Xzt42NB+0yuWJBFu3O4Y2Exx9e042Fc Tn7dX4+RbLTPg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4B2bzT5822zDq81; Thu, 9 Jul 2020 15:06:45 +0200 (CEST) From: To: Carsten Bormann , loops Thread-Topic: [LOOPS] Remaining issues (Re: Charter github issue #1: security, management, operations) Thread-Index: AQHWVer382SCD6DDeEC02dOhBQnxWaj/N3kg Date: Thu, 9 Jul 2020 13:06:44 +0000 Message-ID: <24930_1594300005_5F071665_24930_282_1_787AE7BB302AE849A7480A190F8B9330314F348A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <94A53546-8D02-419B-9EE5-98CF5E716E73@tzi.org> <26214_1594112184_5F0438B8_26214_243_10_787AE7BB302AE849A7480A190F8B9330314F126C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4304D3D9-1BAB-4D23-84E7-D4E6BFDD73DA@tzi.org> In-Reply-To: <4304D3D9-1BAB-4D23-84E7-D4E6BFDD73DA@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] Remaining issues (Re: Charter github issue #1: security, management, operations) X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 13:06:49 -0000 SGkgQ2Fyc3RlbiwgYWxsLA0KDQpJIGFncmVlIHdpdGggdGhpcyBhbmFseXNpcy4gDQoNCkNoZWVy cywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBMT09QUyBb bWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQ2Fyc3Rlbg0KPiBC b3JtYW5uDQo+IEVudm95w6nCoDogamV1ZGkgOSBqdWlsbGV0IDIwMjAgMTQ6MTgNCj4gw4DCoDog bG9vcHMgPGxvb3BzQGlldGYub3JnPg0KPiBPYmpldMKgOiBbTE9PUFNdIFJlbWFpbmluZyBpc3N1 ZXMgKFJlOiBDaGFydGVyIGdpdGh1YiBpc3N1ZSAjMToNCj4gc2VjdXJpdHksIG1hbmFnZW1lbnQs IG9wZXJhdGlvbnMpDQo+IA0KPiBTbyBJIGhhdmUgbWVyZ2VkIHRoZSBQUiAjMTAuDQo+IA0KPiBJ IGFsc28gbWVyZ2VkICM5LCB3aGljaCBpcyBjbG9zaW5nIGlzc3VlICM2Lg0KPiANCj4gSXNzdWUg IzIgaXMgc3RpbGwgb3Blbi4NCj4gSW4gdGhlIHNpZGUgbWVldGluZyBvbiAyMDIwLTA1LTI2LCB3 ZSBzZWVtZWQgdG8gaGF2ZSBjb25zZW5zdXMgdG8NCj4gY3V0IGRvd24gdGhlIG51bWJlciBvZiBX R3MvUkdzIHdlIGV4cGxpY2l0bHkgbWVudGlvbiwgYW5kIHdoaWxlIEkNCj4gYWdyZWUgdGhhdCBQ QU5SRyBpcyBhIGdyb3VwIHRvIHdhdGNoLCBJIHNlZSBsaXR0bGUgaW50ZXJhY3Rpb24NCj4gd2l0 aCB0aGUgbWluaW11bSB2aWFibGUgcHJvdG9jb2wgKE1WUCkgdGhhdCB3ZSBhcmUgdGFyZ2V0aW5n IGZvcg0KPiBjaGFydGVyaW5nIG5vdy4gIFNvIEnigJltIGNvbnNpZGVyaW5nIGNsb3NpbmcgdGhp cyBhcyB3ZWxsIG5vdy4NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IC0tDQo+IExPT1BT IG1haWxpbmcgbGlzdA0KPiBMT09QU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xvb3BzDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Jul 10 01:43:34 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091A03A0EF9 for ; Fri, 10 Jul 2020 01:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 TWYcKE4cXins for ; Fri, 10 Jul 2020 01:43:31 -0700 (PDT) Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (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 E58563A0EF8 for ; Fri, 10 Jul 2020 01:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1594370611; x=1625906611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yyBOKVBbE1PQMIEhoA0Y/aWM/w4a+Et+Ui4XY3ZQGfY=; b=dPAxkTjalYFMVxMKpuqeFAE8IAK+8ibt4UPN0alxxl2RM1LGoJDd2dtd hVHwmC9bsINZv3WWC5T8zl2fjaEb0pp2xQg1oipc55g76N05UaWrGexgA yIQSzZ/qvCZf9zuQ/TDcd7MNiBdLx9M6FOzSAvMDUN55n0+NrjC3WibZt 5/lBbItihFPpr++OlNI7yPcjBR0uafX8TkCDP1cdNZ2UYCogdS/Dlj/Y6 Hpgbq0VKtE7fz4n1zpTn8R8oG8YFZFCmvZuUlup87hWPq4VY6ZDrqoUaq UewlpfbqyHEVE4QGP1sAD5JjmBIYKNmsH84bYWIyfpQSQ3VKqEOsjCNg/ w==; Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES128-SHA256; 10 Jul 2020 10:43:28 +0200 IronPort-SDR: n6mB4Iza21j84LhSQsqrCz8DjAO1naSpeHEhs76UY+9JiKqmghTyNBD3pAwcM+7t59TVC3JVmb E4R/An7cdwVA== X-IronPort-AV: E=Sophos;i="5.69,256,1571695200"; d="scan'208";a="154367730" X-MGA-submission: =?us-ascii?q?MDHNQf7FUG2BDwXfNzJwgdylJOGGWpA1jy7OnP?= =?us-ascii?q?z3wJnw+5+FRTG97tA7Rby+9JhNp66Ol+XkB0PABIQxv9k9za5ARJu0HS?= =?us-ascii?q?w89fA8MkmkEN1d39b/Ze+EAWYZalG2D0tuXaBqkXWIHN7Gnh8+YwU1pv?= =?us-ascii?q?BvpKZmsiyONfYo6hGhqpejnw=3D=3D?= Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 10 Jul 2020 10:43:29 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 10:43:28 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 10 Jul 2020 10:43:28 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.21) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 10:43:30 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZdLYpQUlvAo+3m/+ukBZSwvmCM5QOp3TN2USz7URr3nRpXDOrNn8WIYpB54PCFZbgKwMMx+E+HtDgY62E97UEH7bJoXsDzTiWCe/5E8ciNakEa5hicCuO7ETWZY+fTvJVEdWweMf9ItsSPF3qzwZA//X1jmiVBCGPdbbVqGd2fm8OjKSbEHq3tG436AOVRWDvCy1p5VjjdynCQ5zmCzLufzfaXTGjpQl7rty37ZV6c/Y7zSwoAowU1DN2gnWarHYZuajsPh8PIYH1LB3Tvzzlwp4kcjyED7Kq4z0cCUKjTLTGX+U5nl/b+Sb+g2dLaLjABna+bhofj1MGF6HZf0Cag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yyBOKVBbE1PQMIEhoA0Y/aWM/w4a+Et+Ui4XY3ZQGfY=; b=BOJajutEPuAZAnM6mTRtLAxRWw3HtKYCcIgenbwm+5mTXmgYisBoOsBKoSLq73I7C3ZnwCZ0vCkj/ghGKReIIzfpQTiJQaw9e16l1QKi++eA4A7kt/E+3G+12ZR8s4vPlXBMYRCrwJkPksI1E2mXQHqAymce4uEHiunJpuhQZFrZN7kUlcSuKgd5o62tWeEGwlsT1E9Gepza2PYUxGopetta8hQ/Usz0BOhQk1s+yUE8s5VqaAH1bsIhBZFulwdUq5PVDezdnrP2AE33yMM6VXNEuMGDKlfcgZ3lvE+CSGBba6ubmvzmdN6R+UsCGsrtCEHSZp7LyNqhBdTT3bXzrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:a::11) by LEJPR01MB0555.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Fri, 10 Jul 2020 08:43:27 +0000 Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0]) by LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0%2]) with mapi id 15.20.3195.009; Fri, 10 Jul 2020 08:43:27 +0000 From: To: CC: Thread-Topic: New Version Notification for draft-amend-iccrg-multipath-reordering-00.txt Thread-Index: AQHWVVJgfgEAaAUn9E6F2PpxMEuL2akAgZ7A Date: Fri, 10 Jul 2020 08:43:27 +0000 Message-ID: References: <159423152847.21640.733211169724485576@ietfa.amsl.com> In-Reply-To: <159423152847.21640.733211169724485576@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telekom.de; x-originating-ip: [164.19.3.230] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7215d4e0-f484-494c-2d44-08d824ad50d1 x-ms-traffictypediagnostic: LEJPR01MB0555: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wv+9RMbSKjezZC9twxbdRjxXJW/PKVSyH7niE/YQ1A6aBpM5HyWa5MOPuvp35NrSGp9uQnANYOM/Hc5vPAmobiNmth9o08tvG1rbYD5P0Bq1kcZieMX2pmc9f3Gkt/ZlhrG3kf59uuHGrtfnUTK73s1xRinbBNv5xpsbh7vKeFsQB3qEea6YK7+AYCmlR97CrxY5F+NelORwXfcHY7wKYKYNquOD871sX1oQOktrbbSFoE3feRCdMJPn4QWqqLCthqqIUAj5kDUIFxS0EOYoLe4wn778dPM8MQd+q3yLdxCDlydyijf1vjxtPj20aLhFoaM52uUo4kFH+VhKOEYMZWMeeCsFqwE8u90qeInnVQY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(396003)(346002)(136003)(366004)(376002)(39860400002)(66556008)(186003)(64756008)(66446008)(107886003)(86362001)(66476007)(71200400001)(76116006)(15650500001)(7696005)(6916009)(33656002)(5660300002)(4326008)(83380400001)(26005)(8936002)(2906002)(53546011)(966005)(66574015)(9686003)(55016002)(316002)(66946007)(8676002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6ksF3cRvOKw7s/OjOf1WTRrsfmZ4U7oza/FLchOWpOzWsvJhDzHq+TJen5QioACfV28eGCszVnM1rL4ccnVNbg6ArFnYfB9iK74YnWyDRGYHE9mXPrcrg4inFFAs31lZvSbCK36G7gFeIS9zSQMdhxkqlZYeNpEqZGgTJBocrKnvwHlaVI5dlKXGdKsx/9Ys+kSO00rka5Q29zcUXzfruhH8mk4/MmCsOGaMrZ3P2Q2m/XbrbLVqCBvH97+jQYHH4WENAgnPn4bz48VI23R/XhdPi9C1NKXkQv+bd1+o0kd1ivA0Y7RzbpdfL+T3zokqVp4r7Gz39ZTAMIuKrJV77ibIOELAXG5OChbFp+tiB4kmFdrkq0zN6HDQu8TrP5ZtetQGbtg3PeTbTgu9wgCDokoUNXUplRWJQ96gY1TkaGZJ9Nv+aiDnbeXt19Mok925Xw/QdZ9rI/Ip+CggwTUUfbZz9jjCH+zKbDt0MzK4MYE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: 7215d4e0-f484-494c-2d44-08d824ad50d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 08:43:27.5793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BXUYLplL3QenNo3Lp9T0aMOfkkppfnegCDkZfGwVEps70c9GIPrPlQ8dTHh7+viyFpapB95u7xE/NT07pgDHBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0555 X-TM-SNTS-SMTP: 29A3ABE6E66D0349230F6E7465BEE9C62E23A89A6225A5AFC2699965DCED5A972000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: [LOOPS] FW: New Version Notification for draft-amend-iccrg-multipath-reordering-00.txt X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 08:43:33 -0000 RGVhciBhbGwsDQoNCkkgd2FudCB0byBhbm5vdW5jZSB0aGUgYXZhaWxhYmlsaXR5IG9mIGEgbmV3 IGRyYWZ0IGFkZHJlc3NpbmcgdGhlIGNoYWxsZW5nZSBvZiBwYWNrZXQgcmVvcmRlcmluZyBkdWUg dG8gbXVsdGlwYXRoLiBUaGlzIGRyYWZ0IGluY2x1ZGVzIGNvdW50ZXJtZWFzdXJlcyBsaWtlIHJl c2VxdWVuY2luZywgcmVjb3ZlcnkgYW5kIHJldHJhbm1pc3Npb24gdGVjaG5pcXVlcywgc3RpbGwg b24gaGVhZGxpbmUgbGV2ZWwuIFRoZSBkcmFmdCBpcyBwbGFjZWQgYXQgSUNDUkcuDQoNCkV2ZW4g aWYgQ2Fyc3RlbiBhbHJlYWR5IGluZm9ybWVkIG1lLCB0aGF0IG11bHRpcGF0aCBpcyBub3QgaW4g c2NvcGUgaW5pdGlhbHkgYXQgTE9PUFMsIEkgY291bGQgaW1hZ2luZSB0aGF0IHNvbWUgb2YgdGhl IHRlY2huaXF1ZXMgaW4gdGhlIGRyYWZ0IGFyZSBjb3ZlcmVkIGJ5IHlvdXIgcHJvcG9zZWQgY2hh cnRlciBodHRwczovL2dpdGh1Yi5jb20vbG9vcHMtd2cvY2hhcnRlci4NCg0KUGxlYXNlIGZlZWwg ZnJlZSB0byBnaXZlIG1lIGZlZWRiYWNrIGFuZC9vciBjb250cmlidXRlLg0KDQpCdHcuIGNvbmdl c3Rpb24gY29udHJvbCBpc3N1ZXMsIGFkcmVzc2VkIGJ5IHlvdXIgY2hhcnRlciwgSSBhc3N1bWUg dGhvc2UgdG8gYmUgbWFpbmx5IENDIGluIENDLCByaWdodD8gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJvbmF2ZW50dXJlLXF1aWMtYXRzc3Mtb3ZlcnZpZXctMDAgIGFuZCBlLmcu IFFVSUMgTUFTUVVFIGhhdmUgc2ltaWxhciBjaGFsbGVuZ2VzLg0KDQpCcg0KDQpNYXJrdXMNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gU2VudDogTWl0dHdvY2gsIDguIEp1 bGkgMjAyMCAyMDowNQ0KPiBUbzogdm9uIEh1Z28sIERpcmsgPERpcmsudm9uLUh1Z29AdGVsZWtv bS5kZT47IHZvbiBIdWdvLCBEaXJrIDxEaXJrLnZvbi0NCj4gSHVnb0B0ZWxla29tLmRlPjsgQW1l bmQsIE1hcmt1cyA8TWFya3VzLkFtZW5kQHRlbGVrb20uZGU+OyBBbWVuZCwNCj4gTWFya3VzIDxN YXJrdXMuQW1lbmRAdGVsZWtvbS5kZT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1hbWVuZC1pY2NyZy1tdWx0aXBhdGgtcmVvcmRlcmluZy0NCj4gMDAudHh0 DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFtZW5kLWljY3JnLW11bHRp cGF0aC1yZW9yZGVyaW5nLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IE1hcmt1cyBBbWVuZCBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+ IA0KPiBOYW1lOgkJZHJhZnQtYW1lbmQtaWNjcmctbXVsdGlwYXRoLXJlb3JkZXJpbmcNCj4gUmV2 aXNpb246CTAwDQo+IFRpdGxlOgkJTXVsdGlwYXRoIHNlcXVlbmNlIG1haW50ZW5hbmNlDQo+IERv Y3VtZW50IGRhdGU6CTIwMjAtMDctMDcNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4gUGFnZXM6CQkxMA0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWFtZW5kLWljY3JnLW11bHRpcGF0aC0NCj4gcmVvcmRlcmluZy0w MC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWFtZW5kLWljY3JnLW11bHRpcGF0aC0NCj4gcmVvcmRlcmluZy8NCj4gSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbWVuZC1pY2NyZy1tdWx0 aXBhdGgtcmVvcmRlcmluZy0NCj4gMDANCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYW1lbmQtaWNjcmctbXVsdGlwYXRoLQ0KPiBy ZW9yZGVyaW5nDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vz c2VzIHRoZSBpc3N1ZSBvZiBwYWNrZXQgcmUtb3JkZXJpbmcgd2hpY2ggb2NjdXJzDQo+ICAgIGFz IGEgc3BlY2lmaWMgcHJvYmxlbSBpbiBtdWx0aS1wYXRoIGNvbm5lY3Rpb25zIHdpdGhvdXQgcmVs aWFibGUNCj4gICAgdHJhbnNwb3J0IHByb3RvY29scyBzdWNoIGFzIFRDUC4gIFRoZSB0b3BpYyBp cyByZWxldmFudCBmb3IgZGV2aWNlcw0KPiAgICBjb25uZWN0ZWQgdmlhIG11bHRpcGxlIGFjY2Vz c2VzIHRlY2hub2xvZ2llcyB0b3dhcmRzIHRoZSBuZXR3b3JrIGFzDQo+ICAgIGlzIGZvcmVzZWVu IGUuZy4gd2l0aGluIEFjY2VzcyBUcmFmZmljIFNlbGVjdGlvbiwgU3dpdGNoaW5nLCBhbmQNCj4g ICAgU3BsaXR0aW5nIChBVFNTUykgc2VydmljZSBvZiAzcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hp cCBQcm9qZWN0DQo+ICAgICgzR1BQKSBlbmFibGluZyBmaXhlZCBtb2JpbGUgY29udmVyZ2VkIChG TUMpIHNjZW5hcmlvLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCg== From nobody Fri Jul 10 03:31:48 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C573A0879 for ; Fri, 10 Jul 2020 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 vaaO6zYroJDT for ; Fri, 10 Jul 2020 03:31:44 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4AE3A0874 for ; Fri, 10 Jul 2020 03:31:43 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B38V60XB6zydx; Fri, 10 Jul 2020 12:31:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Fri, 10 Jul 2020 12:31:41 +0200 Cc: loops , Dirk.von-Hugo@telekom.de X-Mao-Original-Outgoing-Id: 616069901.00719-ce4a0a5b643d2c0ef5cbad087a047c3c Content-Transfer-Encoding: quoted-printable Message-Id: <39973CA5-E075-43A7-9975-08409C76DEEE@tzi.org> References: <159423152847.21640.733211169724485576@ietfa.amsl.com> To: Markus.Amend@telekom.de X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] New Version Notification for draft-amend-iccrg-multipath-reordering-00.txt X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 10:31:46 -0000 Hi Markus, On 2020-07-10, at 10:43, = wrote: >=20 > Even if Carsten already informed me, that multipath is not in scope = initialy at LOOPS, I could imagine that some of the techniques in the = draft are covered by your proposed charter = https://github.com/loops-wg/charter. The resequencing part is not, as LOOPS does not resequence. In previous discussions, we have always considered resequencing as an = optional service that could be provided unilaterally at the egress (we = have different experiences with and thus different opinions on = resequencing). In many cases, the data that enable recovery (retransmission or = reconstruction) are all that is needed to run a (non-reliable, as needed = on the IP layer) resequencing process; this would use static expiration = (Section 5.3 in your draft) or adaptive expiration (Section 5.4). The = adaptation mechanisms in the latter would benefit from some measurement = information being available at the egress, but that is probably already = needed to control the formation of return channel information (ACKs = etc.) or for reconstruction (symbol numbers for FEC). This has always been implicit; I=E2=80=99m not sure we want to make = supplying measurement information for a resequencing process an explicit = objective. Section 6 (recover mechanisms) of course is the essence of LOOPS. We = are not discussing the multipath aspects for the LOOPS MVP we describe = in the charter, but LOOPS MVP could run either per-path or on the = aggregate in a multipath environment. I think that if a protocol for = this goes forward, that could be based on LOOPS even if that doesn=E2=80=99= t cover the multipath use case fully yet. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 17 00:57:19 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118473A14C1 for ; Fri, 17 Jul 2020 00:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 cvtvnSr_DMaD for ; Fri, 17 Jul 2020 00:57:16 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97A213A14BF for ; Fri, 17 Jul 2020 00:57:16 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B8DB11B00115; Fri, 17 Jul 2020 08:57:10 +0100 (BST) To: loops Cc: Carsten Bormann , Michael Welzl , Liyizhou References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> From: Gorry Fairhurst Message-ID: <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> Date: Fri, 17 Jul 2020 08:57:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 07:57:18 -0000 See below: On 09/07/2020 13:26, Carsten Bormann wrote: > On 2020-07-09, at 12:32, Gorry Fairhurst wrote: >> - For short transactions (or bursts of activity within a flow), there can be a much bigger potential proportional benefit. > Indeed. I think the recent discussions have arrived at the conclusion that the minimum viable protocol (MVP) we are targeting now, will be beneficial for ants and for transactional flows (flows that stop and restart), less so for throughput-bound flows. Essentially we get the benefits 2.1 to 2.4 listed in RFC 8087. > > Grüße, Carsten OK, so I think this means the plan would be to target chatty flows, but only for endpoints that have  enabled ECN? Am I correct in assuming that this is classic ECN, using ECT(0)? As I think I understand, a path increases the workload in response to loss by adding FEC that recovers the loss but hides the increase in rate from the endpoints, instead setting ECN-CE marks to notify of congestion. If the endpoint reacts, then the load stabilizes. Do I need to worry whether the endpoint's reaction to ECN-CE marks is something that the network would also need to monitor, to confirm that CE-marking is actually causing a congestion reaction? Gorry From nobody Fri Jul 17 01:27:00 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF533A155A for ; Fri, 17 Jul 2020 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 4iw1rcROvqjZ for ; Fri, 17 Jul 2020 01:26:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F7E3A1559 for ; Fri, 17 Jul 2020 01:26:54 -0700 (PDT) Received: from client-0175.vpn.uni-bremen.de (client-0175.vpn.uni-bremen.de [134.102.107.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B7PNn5n9jz17sr; Fri, 17 Jul 2020 10:26:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> Date: Fri, 17 Jul 2020 10:26:49 +0200 Cc: loops , Liyizhou , Michael Welzl X-Mao-Original-Outgoing-Id: 616667209.11756-3fd61760258dd2a8d20a5d86278346cd Content-Transfer-Encoding: quoted-printable Message-Id: <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 08:26:58 -0000 >=20 > OK, so I think this means the plan would be to target chatty flows, = but only for endpoints that have enabled ECN? Yes. (I don=E2=80=99t know if you group short flows under chatty.) > Am I correct in assuming that this is classic ECN, using ECT(0)? If there is another form of ECN, with defined rules how to convert = losses into marks, these could be added. But I don=E2=80=99t think = there is, at this point in time. > As I think I understand, a path increases the workload in response to = loss by adding FEC that recovers the loss but hides the increase in rate = from the endpoints, instead setting ECN-CE marks to notify of = congestion. If the endpoint reacts, then the load stabilizes. Do I need = to worry whether the endpoint's reaction to ECN-CE marks is something = that the network would also need to monitor, to confirm that CE-marking = is actually causing a congestion reaction? Do we do that without LOOPS? (We could add flow-specific circuit breakers, but that creates a lot of = processing.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 17 01:40:03 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBE3A1575 for ; Fri, 17 Jul 2020 01:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 mvkYKtPLunDX for ; Fri, 17 Jul 2020 01:40:00 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6623A1574 for ; Fri, 17 Jul 2020 01:40:00 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0D72F1B001AB; Fri, 17 Jul 2020 09:39:54 +0100 (BST) To: Carsten Bormann Cc: loops , Liyizhou , Michael Welzl References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> From: Gorry Fairhurst Message-ID: <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk> Date: Fri, 17 Jul 2020 09:39:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 08:40:02 -0000 See below. On 17/07/2020 09:26, Carsten Bormann wrote: >> OK, so I think this means the plan would be to target chatty flows, but only for endpoints that have enabled ECN? > Yes. (I don’t know if you group short flows under chatty.) OK. I see short flows too. > >> Am I correct in assuming that this is classic ECN, using ECT(0)? > If there is another form of ECN, with defined rules how to convert losses into marks, these could be added. But I don’t think there is, at this point in time. :-). I expect that targeting ECT(0) is at least the best first step. TSVWG is publishing L4S, and that might (soon) be on the roadmap for the way ECN is used. Still this relies on endpoints to enable ECT(0) processing that might or might not be a hurdle to deploying something else. Do people see LOOPS brings benefit  if the endpoints do not support ECN? >> As I think I understand, a path increases the workload in response to loss by adding FEC that recovers the loss but hides the increase in rate from the endpoints, instead setting ECN-CE marks to notify of congestion. If the endpoint reacts, then the load stabilizes. Do I need to worry whether the endpoint's reaction to ECN-CE marks is something that the network would also need to monitor, to confirm that CE-marking is actually causing a congestion reaction? > Do we do that without LOOPS? I think I am concerned enough to worry about this, unless I can see a lot more experience from ietf-tsvwg-tunnel-congestion-feedback. > > (We could add flow-specific circuit breakers, but that creates a lot of processing.) Indeed and a circuit-breaker wouldn't be easy to realise (or perhaps appropiate) for short/chatty flows, and that makes me wonder really how much need there is to experimentally investigate what is needed. > Grüße, Carsten Gorry From nobody Fri Jul 17 01:57:09 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931893A158D for ; Fri, 17 Jul 2020 01:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 wwPdsQKWrxLY for ; Fri, 17 Jul 2020 01:57:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF403A1589 for ; Fri, 17 Jul 2020 01:57:05 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B7Q3b6qq3zyhZ; Fri, 17 Jul 2020 10:56:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk> Date: Fri, 17 Jul 2020 10:56:58 +0200 Cc: Michael Welzl , loops , Liyizhou X-Mao-Original-Outgoing-Id: 616669018.167076-db2c486f8bde75d63a73e670365934e8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 08:57:09 -0000 >=20 > Still this relies on endpoints to enable ECT(0) processing that might = or might not be a hurdle to deploying something else. Do people see = LOOPS brings benefit if the endpoints do not support ECN? Not the MVP (minimum viable protocol) we are targeting now =E2=80=94 = doing a one-to-one drop-to-drop signaling doesn=E2=80=99t give you a lot = of recovery :-) Since the issue really is what traffic can be directed to the LOOPS = tunnel, it is somewhat trivial to provide benefit once we have better = segment-to-path congestion signaling. >>> As I think I understand, a path increases the workload in response = to loss by adding FEC that recovers the loss but hides the increase in = rate from the endpoints, instead setting ECN-CE marks to notify of = congestion. If the endpoint reacts, then the load stabilizes. Do I need = to worry whether the endpoint's reaction to ECN-CE marks is something = that the network would also need to monitor, to confirm that CE-marking = is actually causing a congestion reaction? >> Do we do that without LOOPS? > I think I am concerned enough to worry about this, unless I can see a = lot more experience from ietf-tsvwg-tunnel-congestion-feedback. How can we have any useful ECT traffic at all if we need to suspect that = doesn=E2=80=99t react to CE marks? I=E2=80=99m not sure I understand = what the existence of the LOOPS tunnel adds to that (assuming there is = some sane overhead limit, such as 20 % =E2=80=94 I=E2=80=99m sure 10000 = % wouldn=E2=80=99t be so great). >> (We could add flow-specific circuit breakers, but that creates a lot = of processing.) >=20 > Indeed and a circuit-breaker wouldn't be easy to realise (or perhaps = appropiate) for short/chatty flows, and that makes me wonder really how = much need there is to experimentally investigate what is needed. A single unruly flow won=E2=80=99t influence a high-mux aggregate. If there are many unruly flows, the aggregate circuit breaker will trip. Is there anything interesting in between? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 17 05:04:07 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A363A0ADE for ; Fri, 17 Jul 2020 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sRZ445xf0MQw for ; Fri, 17 Jul 2020 05:04:04 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 228E73A0AD9 for ; Fri, 17 Jul 2020 05:04:04 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id q4so12360646lji.2 for ; Fri, 17 Jul 2020 05:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BeIzytdatosGZnAPL05v4dXceG1Z3I4Am7u8LhvmU58=; b=YBDhKRERvk/85ltojv4Z0/rEmE8M4d6g/eKUGIbaXqget/lNGPMK6dbrp8mJvA6B0T nGlhXbY/H2mjeJ3gVYkiB3W5RJruSO6DX+nTp8J3VDDYAEONaAq5/+cDF/U4rYJoTo24 l+stdVVf5O4Ack8VgYsxYgvLMS1qAoojACO1xhoY2+KNFqDZtHB9C6OsYHPbvfMd3tVZ uG6ZiU5YhEjrr/A8khQh4aPbufkWyjYUkbyejjVssmsSQwFiPmKw3muuKfE+jJUJAQIP DfLtXV8iGgEoXPgtSmi3jRmLf6QKUij25Zg9qAfgkIySt1Ve/ew1U+xw1o47g9bXraNv +b0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BeIzytdatosGZnAPL05v4dXceG1Z3I4Am7u8LhvmU58=; b=MkuKQykLI/7JKraY5PyG1/n8N3XWaICYp48gdqhGhJW+npEcCOg0pBL3FADpbz25Yk E0+L1OTiOXzMfU83cwOH6cbwyUwOwJTG0ZiAocEAsIWpikk00r/197cTnt6SyWs6MmwB yIDLCQZYts/4wiqrIThyX8NnxcghcL9WaadwBj9jfUVl5ctGMDdq4LRkX8aUZ5akJZlz b+x4Ksvggnxx408Pv4YctdZIzkvFYl+tWu+JyYYJH7cRLSdWTYOixEgoH11JP5kIeQ8u Z92PRzULmoCJzyzf88QK/vcz5ZUXjrSIOjDH29A6nonmGeX8YE6ZN5PmcvYKwf9LXpc1 ahDw== X-Gm-Message-State: AOAM5317eZEymzo1if9Ly2BMNDdmQ/hnURYzPY6YUaVlgte/H6N5cvDj wBoz7NAWA6g75XQ8FIEXp4ZxzzT/ORbWjo8B5bE= X-Google-Smtp-Source: ABdhPJxgpDpZex4boROnK92PC9D+d5j8uqMugU85kQWf99cnMt+++g2h9CXovT2HRqCx1nsmqENsk5byHRrZ5nIap6o= X-Received: by 2002:a2e:9b42:: with SMTP id o2mr4148343ljj.102.1594987442154; Fri, 17 Jul 2020 05:04:02 -0700 (PDT) MIME-Version: 1.0 References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 17 Jul 2020 07:03:36 -0500 Message-ID: To: Carsten Bormann Cc: Gorry Fairhurst , Liyizhou , loops , Michael Welzl Content-Type: multipart/alternative; boundary="000000000000e934ea05aaa1f329" Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 12:04:06 -0000 --000000000000e934ea05aaa1f329 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Spencer, with no hat (not even a bandana, I'm indoors in Texas), On Fri, Jul 17, 2020 at 3:57 AM Carsten Bormann wrote: > > > > Still this relies on endpoints to enable ECT(0) processing that might o= r > might not be a hurdle to deploying something else. Do people see LOOPS > brings benefit if the endpoints do not support ECN? > > Not the MVP (minimum viable protocol) we are targeting now =E2=80=94 doin= g a > one-to-one drop-to-drop signaling doesn=E2=80=99t give you a lot of recov= ery :-) > > Since the issue really is what traffic can be directed to the LOOPS > tunnel, it is somewhat trivial to provide benefit once we have better > segment-to-path congestion signaling. > > >>> As I think I understand, a path increases the workload in response to > loss by adding FEC that recovers the loss but hides the increase in rate > from the endpoints, instead setting ECN-CE marks to notify of congestion. > If the endpoint reacts, then the load stabilizes. Do I need to worry > whether the endpoint's reaction to ECN-CE marks is something that the > network would also need to monitor, to confirm that CE-marking is actuall= y > causing a congestion reaction? > >> Do we do that without LOOPS? > > I think I am concerned enough to worry about this, unless I can see a > lot more experience from ietf-tsvwg-tunnel-congestion-feedback. > > How can we have any useful ECT traffic at all if we need to suspect that > doesn=E2=80=99t react to CE marks? I=E2=80=99m not sure I understand wha= t the existence of > the LOOPS tunnel adds to that (assuming there is some sane overhead limit= , > such as 20 % =E2=80=94 I=E2=80=99m sure 10000 % wouldn=E2=80=99t be so gr= eat). > > >> (We could add flow-specific circuit breakers, but that creates a lot o= f > processing.) > > > > Indeed and a circuit-breaker wouldn't be easy to realise (or perhaps > appropiate) for short/chatty flows, and that makes me wonder really how > much need there is to experimentally investigate what is needed. > > A single unruly flow won=E2=80=99t influence a high-mux aggregate. > If there are many unruly flows, the aggregate circuit breaker will trip. > Is there anything interesting in between? > Let me first say how much I appreciate these exchanges happening this week on the mailing list, and not during Session 1 of Friday during IETF 108 week :D. I'm thinking about "first, do no harm". - If a path has a large number of short flows that respond to CE, that's awesome. - If a path has a large number of short flows that don't respond to CE markings, but do respond to drops, the senders should slow down as much = as you can slow down an exchange with less than a dozen packers, when they = see drops. Is LOOPS making that situation better, or worse? - If a path has a large number of short flows that don't respond to CE markings or drops, I THINK an aggregate circuit breaker would cover that situation. Is LOOPS making that situation better, or worse? What am I missing? Best, Spencer, who was available to help co-chair LOOPS because he's not as smart as you guys :p --000000000000e934ea05aaa1f329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Spencer, with no hat (not even a bandana,= I'm indoors in Texas),

On Fri, Jul 17, 2020 at 3:57 AM Carsten Bormann = <cabo@tzi.org> wrote:
>
> Still this relies on endpoints to enable ECT(0) processing that might = or might not be a hurdle to deploying something else. Do people see LOOPS b= rings benefit=C2=A0 if the endpoints do not support ECN?

Not the MVP (minimum viable protocol) we are targeting now =E2=80=94 doing = a one-to-one drop-to-drop signaling doesn=E2=80=99t give you a lot of recov= ery :-)

Since the issue really is what traffic can be directed to the LOOPS tunnel,= it is somewhat trivial to provide benefit once we have better segment-to-p= ath congestion signaling.

>>> As I think I understand, a path increases the workload in resp= onse to loss by adding FEC that recovers the loss but hides the increase in= rate from the endpoints, instead setting ECN-CE marks to notify of congest= ion. If the endpoint reacts, then the load stabilizes. Do I need to worry w= hether the endpoint's reaction to ECN-CE marks is something that the ne= twork would also need to monitor, to confirm that CE-marking is actually ca= using a congestion reaction?
>> Do we do that without LOOPS?
> I think I am concerned enough to worry about this, unless I can see a = lot more experience from ietf-tsvwg-tunnel-congestion-feedback.

How can we have any useful ECT traffic at all if we need to suspect that do= esn=E2=80=99t react to CE marks?=C2=A0 I=E2=80=99m not sure I understand wh= at the existence of the LOOPS tunnel adds to that (assuming there is some s= ane overhead limit, such as 20 % =E2=80=94 I=E2=80=99m sure 10000 % wouldn= =E2=80=99t be so great).

>> (We could add flow-specific circuit breakers, but that creates a l= ot of processing.)
>
> Indeed and a circuit-breaker wouldn't be easy to realise (or perha= ps appropiate) for short/chatty flows, and that makes me wonder really how = much need there is to experimentally investigate what is needed.

A single unruly flow won=E2=80=99t influence a high-mux aggregate.
If there are many unruly flows, the aggregate circuit breaker will trip. Is there anything interesting in between?

Let me first say how much I appreciate these exchanges happening this we= ek on the mailing list, and not during Session 1 of Friday during IETF 108 = week :D.

I'm thinking about "first, do no= harm".=C2=A0
  • If a path has a large number of short= =C2=A0flows that respond to CE, that's awesome.
  • If a path has a= large number of short flows that don't respond to CE markings, but do = respond to drops, the=C2=A0senders should slow down as much as you can slow= down an exchange with less than a dozen packers,=C2=A0when they see drops.= Is LOOPS making that situation better, or worse?
  • If a path has a l= arge number of short flows that don't respond to CE markings or drops, = I THINK an aggregate circuit breaker would cover that situation. Is LOOPS m= aking that situation better, or worse?=C2=A0
What am I missin= g?

Best,

Spencer, w= ho was available to help co-chair LOOPS because he's not as smart as yo= u guys :p
--000000000000e934ea05aaa1f329-- From nobody Tue Jul 21 02:03:30 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7149C3A1704 for ; Tue, 21 Jul 2020 02:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 XSGG3xmHgJCW for ; Tue, 21 Jul 2020 02:03:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADF93A1706 for ; Tue, 21 Jul 2020 02:03:25 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B9t171TqGz17qj; Tue, 21 Jul 2020 11:03:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 21 Jul 2020 11:03:22 +0200 Cc: Gorry Fairhurst , Liyizhou , loops , Michael Welzl X-Mao-Original-Outgoing-Id: 617015002.446655-f3c0ddd3bc0fdbf819d43f29dda46291 Content-Transfer-Encoding: quoted-printable Message-Id: <9D5A00EA-55CC-4C78-B771-34C129301698@tzi.org> References: <19d1f8379e464b70a00c025371a15e31@huawei.com> <9777f17b-4da4-6632-0ec7-606c7b7c9f9f@erg.abdn.ac.uk> <0C024505-D07F-46CC-8293-6E9EC1CE520E@ifi.uio.no> <9EF400E0-8810-434F-A1CC-EAE13B006F7C@tzi.org> <6cee1b1f-93c8-d930-3e0b-a34f627521e3@erg.abdn.ac.uk> <54C340AB-C746-4D58-8B11-A6EF9EE15DFE@tzi.org> <1de7101e-2455-face-0978-4aba45169de7@erg.abdn.ac.uk> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 09:03:28 -0000 Hi Spencer, Interesting questions. > On 2020-07-17, at 14:03, Spencer Dawkins at IETF = wrote: >=20 > I'm thinking about "first, do no harm".=20 > =E2=80=A2 If a path has a large number of short flows that = respond to CE, that's awesome. Indeed. Let=E2=80=99s talk about short + transactional (=E2=80=9Cchatty=E2= =80=9D) flows, though. > =E2=80=A2 If a path has a large number of short flows that don't = respond to CE markings, but do respond to drops, the senders should slow = down as much as you can slow down an exchange with less than a dozen = packers, when they see drops. Is LOOPS making that situation better, or = worse? Until countermeasures such as circuit breakers hit, worse. Since LOOPS = is converting drops to marks, it is converting observed congestion = events into ignored congestion events for these flows. So where do you get those flows that don=E2=80=99t respond to CE = markings? And how did you avoid them breaking other CE-marking places = in the Internet already? I think the argument really boils down to = =E2=80=9Cwe can=E2=80=99t have LOOPS adding CE-marking places because = CE-marking is bad=E2=80=9D, and I=E2=80=99m not sure we have consensus = on the latter. I know about the case where a middle box somwhere on the path outside = the LOOPS segment removes ECE markings from TCP headers; this is about = the worst case I can think about (but it is already bad without LOOPS). For short flows, it may be worth to consider what =E2=80=9Crespond to = drops=E2=80=9D means. For a short flow, the drop can be (1) in the = establishment phase (where LOOPS cannot help TCP flows), essentially = acting as a flow-delayer or flow-preventer (in the presence of racing). = LOOPS is not changing that picture. Or it can be (2) in the IW10 phase, = and there LOOPS is likely to react to a drop by adding a packet or two = to the ones that already are flowing. Doesn=E2=80=99t help with any = congestion in the LOOPS-controlled path segment, but doesn=E2=80=99t = really hurt that much. > =E2=80=A2 If a path has a large number of short flows that don't = respond to CE markings or drops, I THINK an aggregate circuit breaker = would cover that situation. Is LOOPS making that situation better, or = worse?=20 LOOPS is introducing a circuit breaker where there might not have been = one before, so it is making the situation better. The question of course is how fast does it trip (i.e., what is the = damage until it does), and what exactly does it circuit-break. I would = have designed it to just stop expending packets on recovery (i.e., stop = LOOPS), but not to stop traffic at all. That would mean there would be = no benefit, but also no lasting damage. I think in the end we will need to limit any damage from misbehaving = endpoints (whether doing that on their own or due to some bad = interventions from middle boxes) by limiting the amount of repair that = is being done by LOOPS. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 26 16:14:34 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F23A1523 for ; Sun, 26 Jul 2020 16:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xD5QnwwFYPSd for ; Sun, 26 Jul 2020 16:14:30 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 381B53A151C for ; Sun, 26 Jul 2020 16:14:29 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id r19so15184537ljn.12 for ; Sun, 26 Jul 2020 16:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Tc0MzuuVJjRnfMtirB8lnmuhs1cqj5f02kawJVDRZAA=; b=PM/Jw44HEC14lUNPA+weKK7CLskzcjvHiicKbzeugJePtNMI326mIy1H5tjstqG5H/ W+Wg3BBKxVMXv4k7KOBjKerc7dJnkH6Uza60NjCc21wDpVkTsfQUk56rpsbONqRJ+F9F djytpWJQxvrX0AkU6HJwMz1LlCQHS0fMUiENUa5HmidJlCuHzTaUh+Kyvwedf/EohONQ kTULxqB5IGQneZQeS9H19GVKFNqF3gmQMLs9ewIP7LMmM7gMWaT+gYwm9Jt8VxHauQdx y6ugNNPiiFlGipTWmf8eBh5dixqiehDrEq8N6XatRF3094eLpY829C1ITYIijYJlrJxj Owmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tc0MzuuVJjRnfMtirB8lnmuhs1cqj5f02kawJVDRZAA=; b=Q9FJAB5Bau6+b/HPZM0uRs7gbvXp+Tl2tWh1uv0Wzo/n3coVGwQLwuwb3ptXfDP5MC 3aLuzudWkCWMDu1LQpiWNvMfAhgZIpWT6yA66bSSxbrBbEUDYioNGgW5cXxJlh8+O6zW 6GBtqSjVG/vhtFyQgSvW9aTSRFosRZRgIXMp9rTxOcUWqUXiawvDOM/+hspcWjDy58gX PKmt0WhGqLxhIPpO/bYA5CNHu492TiOS28/niLRsPTVGw+qZE4QusdrIUXDSEclv4vvQ VxUzI9OE2+x8BzfuSiQsLyx3gjNn27RQ0dzcq05U73Z0qHdeblG96PJnHDp/Lsub1jTJ 5cPQ== X-Gm-Message-State: AOAM5318RbPNqLYb1LMmMDhzahH8uIz7tjvD/f/dl5iJJbkHcU4n3fyH X0CIrx+A2GLtHPDg/qA7Q004pQj0Rubt5QkR9TbLmXZh X-Google-Smtp-Source: ABdhPJy8OdWPk7pLut4LgvSqq+JoQ5d89Ek5H2Zl7TtHAJQh19TGXKP+9WcsGJokgjC9z/O0CjVg2DCW/HgqStV+Jco= X-Received: by 2002:a2e:8043:: with SMTP id p3mr9249566ljg.469.1595805267960; Sun, 26 Jul 2020 16:14:27 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Sun, 26 Jul 2020 18:14:02 -0500 Message-ID: To: loops Content-Type: multipart/alternative; boundary="00000000000020a7b305ab605ef3" Archived-At: Subject: [LOOPS] LOOPS scheduled for Friday July 31, Session 1, materials uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 23:14:32 -0000 --00000000000020a7b305ab605ef3 Content-Type: text/plain; charset="UTF-8" Dear All, LOOPS will be having its WG-forming BOF this coming Friday during session 1. I've uploaded a single slide deck that we'll be using during the meeting. The most up-to-date set of pointers is at https://datatracker.ietf.org/meeting/agenda/ (scan down to LOOPS). Best, Spencer, for the chairs --00000000000020a7b305ab605ef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,=C2=A0

LOOPS will be having it= s WG-forming BOF this coming Friday during session 1. I've uploaded a s= ingle slide deck that we'll be using during the meeting.=C2=A0

The most up-to-date set of pointers is at=C2=A0https://datatracker.ietf.org/= meeting/agenda/=C2=A0(scan down to LOOPS).

Bes= t,

Spencer, for the chairs
--00000000000020a7b305ab605ef3-- From nobody Mon Jul 27 00:56:38 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2343A178D for ; Mon, 27 Jul 2020 00:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 d8mhXRlCA39s for ; Mon, 27 Jul 2020 00:56:30 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id D180E3A1775 for ; Mon, 27 Jul 2020 00:56:29 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 43E9D1B00127; Mon, 27 Jul 2020 08:56:11 +0100 (BST) To: Spencer Dawkins at IETF , loops References: From: Gorry Fairhurst Message-ID: Date: Mon, 27 Jul 2020 08:56:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C30F85C366E3159D1942231A" Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] LOOPS scheduled for Friday July 31, Session 1, materials uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 07:56:36 -0000 This is a multi-part message in MIME format. --------------C30F85C366E3159D1942231A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit There was some discussion on list about what was actually intended by the authors, and suggestions that the contents in the drafts would be updated. Is that still planned before the BOF, or is the BOF to be based on the published drafts in the tracker? Gorry On 27/07/2020 00:14, Spencer Dawkins at IETF wrote: > Dear All, > > LOOPS will be having its WG-forming BOF this coming Friday during > session 1. I've uploaded a single slide deck that we'll be using > during the meeting. > > The most up-to-date set of pointers is at > https://datatracker.ietf.org/meeting/agenda/ (scan down to LOOPS). > > Best, > > Spencer, for the chairs > --------------C30F85C366E3159D1942231A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

There was some discussion on list about what was actually intended by the authors, and suggestions that the contents in the drafts would be updated. Is that still planned before the BOF, or is the BOF to be based on the published drafts in the tracker?

Gorry

On 27/07/2020 00:14, Spencer Dawkins at IETF wrote:
Dear All, 

LOOPS will be having its WG-forming BOF this coming Friday during session 1. I've uploaded a single slide deck that we'll be using during the meeting. 

The most up-to-date set of pointers is at https://datatracker.ietf.org/meeting/agenda/ (scan down to LOOPS).

Best,

Spencer, for the chairs

--------------C30F85C366E3159D1942231A-- From nobody Mon Jul 27 01:01:53 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B93A1794 for ; Mon, 27 Jul 2020 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 cNL_Hy2IVu-R for ; Mon, 27 Jul 2020 01:01:47 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB343A1790 for ; Mon, 27 Jul 2020 01:01:47 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BFXMF3tnMz101s; Mon, 27 Jul 2020 10:01:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 27 Jul 2020 10:01:44 +0200 Cc: Spencer Dawkins at IETF , loops X-Mao-Original-Outgoing-Id: 617529704.903259-ab2c61c31a968d48694624f9c73c35e8 Content-Transfer-Encoding: quoted-printable Message-Id: <227549FB-B4A6-47BA-9AA1-4F73A189F0E1@tzi.org> References: To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] LOOPS scheduled for Friday July 31, Session 1, materials uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 08:01:50 -0000 On 2020-07-27, at 09:56, Gorry Fairhurst wrote: >=20 > There was some discussion on list about what was actually intended by = the authors, and suggestions that the contents in the drafts would be = updated. Is that still planned before the BOF, or is the BOF to be based = on the published drafts in the tracker? The SRv6 binding has not been updated, as this is not in the proposed = MVP. The Geneve binding didn=E2=80=99t seem to need much update, either; it = has been last updated 2020-06-12. draft-li-tsvwg-loops-problem-opportunities-06 and = draft-welzl-loops-gen-info-04 (LOOPS Generic Information Set) have both been updated on 2020-07-13, = the Internet Draft deadline, and should be in line with what we are = proposing. Of course, we could update things again before the BOF =E2=80=94 is = there anything specific you want to point our attention to? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 27 08:22:41 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DDB3A1721 for ; Mon, 27 Jul 2020 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 StMHTMJafrXX for ; Mon, 27 Jul 2020 08:22:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF41C3A0F15 for ; Mon, 27 Jul 2020 08:22:35 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D12291B002BC for ; Mon, 27 Jul 2020 16:21:37 +0100 (BST) From: Gorry Fairhurst To: loops Message-ID: <3b756bdc-12ed-5560-c336-4e0f3e341d1d@erg.abdn.ac.uk> Date: Mon, 27 Jul 2020 16:21:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 15:22:40 -0000 Thank you for taking the trouble to update draft-li-tsvwg-loops-problem-opportunities, the new text does help in many places, and I'm sorry not to have responded earlier to this new text.  I am still not clear yet what is antcipated from the transport congestion-control response. Please see comments below: (1) Moving figure 1 seems helpful to introduce the context. Thanlks. (2) In Section 6: I read section 6 as describing two recovery cases: One is about DupACK-based recovery. The other says it is about RACK recovery, I wonder if this is mainly the case where the dupACK, where I think this is about TLP (which uses RACKL) to short-cut the RTO by trying to recover after ~2RTTs? (3) I think the text suggests these might have different implications on LOOPS, which seems reasonable, although I have questions: “If LOOPS network does not buffer the out-of-order packets caused       by packet loss, TCP sender which uses a time based loss detection       like RACK [I-D.ietf-tcpm-rack] will perform well here.  It uses       the notion of time to replace the conventional DUPACK threshold       approach to detect losses.  Hence it prevents the TCP sender from       invoking fast retransmit too early. “ (4) In Section 4.1: “When a sender does not receive an ACK for a given segment within    a certain amount of time called retransmission timeout (RTO), it re-    sends the segment [RFC6298].  RTO can be as long as several seconds.” … “Even when    the lost packet is not an exact tail, it can possibly add another RTT    because there may not be enough packets in flight to trigger the fast    retransmit).” - I think this text argues simply for TLP? - How would the method imporve performance, if TLP were to be widely deployed, since it's been promoted for TCP and specified for QUIC? (5) Also, maybe I misunderstand, can’t RACK trigger retransmission earlier than timeout for a TLP - which the start of the ID said was an important use-case? “Local retransmission will not       interfere the sender's retransmission generally in this case.  If       time based loss detection is not supported at the sender, end to       end retransmission may be invoked as usual.  It consumes extra       bandwidth Because the lost packets (i.e. recovered packet) is       normally a very small percentage of the total packets.  Then extra       bandwidth cost is not significant.” - I don’t really understand this argument. Is this saying there will be few losses, and hence the additional capacity used by retransmission is small. If that was my correct interpretation, how does LOOPS know there are few losses? Does it measure this and rate-control it’s retransmissions to ensure this, or maybe some other method is used to avoid there being significant load from two levels of retransmission? (6) Is some sort of check needed anyway perhaps? Because LOOPS could potentially work over a path with L2 retransmissions (e.g. WiFi, and any loops retransmissions multiply the number of L2 retransmissions? - Can LOOPS be tunnelled over LOOPS in any cases? (7) I now think I might understand the scope of the proposed work is constrained only to cases where ECN has been deployed and is enabled end-to-end. In Section 5.2: “LOOPS can CE(Congestion Experienced) marks    its recovered packets as the loss signal to end-to-end. Converting a    packet loss signal to CE marking signal brings the benefits of    reducing Head-of-Line blocking and probability of RTO expiry    [RFC8087] without affecting TCP sender's loss based congestion    control behaviour while enjoying the faster local recovery. ECN    based indication is equivalent to a loss event at the TCP sender    [RFC3168].” … “ In this way, a requirement is set for applying LOOPS.” I still think this would benefit from being clearer at the start of the document, because only ECT (ECN-Capable Transport) flows should be directed to an LOOPS enabled path segment, as I think it says? Best wishes, Gorry From nobody Mon Jul 27 08:22:49 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB33A183C for ; Mon, 27 Jul 2020 08:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 UshdHisfz3BP for ; Mon, 27 Jul 2020 08:22:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE743A0F1E for ; Mon, 27 Jul 2020 08:22:33 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DC17D1B0025E for ; Mon, 27 Jul 2020 16:21:35 +0100 (BST) From: Gorry Fairhurst To: loops Message-ID: Date: Mon, 27 Jul 2020 16:21:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 15:22:44 -0000 Thank you for the scenarios update in draft-li-tsvwg-loops-problem-opportunities, I see you have updated the text relating to satellite network segments. I now have some more questions on scenarios based on the what is said in the most recent ID: (1) The text says: "By continuously measuring the    delay of path segments and use them as metrics for path selection,    when the number of overlay nodes is sufficiently large, there is a    high chance that a better path could be found    [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560].    [DOI_10.1145_3038912.3052560] further shows all cloud providers   experience random loss episodes and random loss accounts for more    than 35% of total loss." - I think this use case was presented in previuous meetings, and one of the questions was how to react appropiately to route changes and traffic engineering by the physical network operator. This doesn't come across to me in the latest text. (2) I will argue there is not a satellite-specific use case really, there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT.  “Enhanced error recovery at the satellite link layer    helps for the loss on the satellite link but doesn't help for the    terrestrial links.  Even when the terrestrial segments are short, any    loss must be recovered across the satellite link delay.” -  I think the argument is really that the end-to-end internet path using a satellite network segment can be long (large RTT), and therefore that loss experienced at any point outside the satellite network segment still suffers performance because of the larger RTT. - If that is the case, then I think a GEO satellite path is an **example** of such a path. is this a “long terrestrial” path? or a long Internet path? - “Faster recovery over such    long terrestrial segments is desirable.” (3) The previous revision mentioned the specific case where the “network is long-haul”, but I think this aspect was removed in the latest rev?. Maybe I don’t fully see - is it expected (or somehow known) that the delay for the LOOPS path segment is much less than the end-to-end path (in Section 1)? How does the LOOPS path segment know this? (4) I see you also mention in the latest rev adds a use case for a "fleet of drones" - I'm not quite sure what this is describing, maybe you could expand how this works, and add some text to the draft. Gorry From nobody Tue Jul 28 02:23:07 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDCF3A09A9 for ; Tue, 28 Jul 2020 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 p1s8YaVBpSx3 for ; Tue, 28 Jul 2020 02:23:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AD7643A09A5 for ; Tue, 28 Jul 2020 02:23:02 -0700 (PDT) Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6183047F5FE806662CA6 for ; Tue, 28 Jul 2020 10:22:59 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 10:22:58 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 17:22:55 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 28 Jul 2020 17:22:55 +0800 From: Liyizhou To: Gorry Fairhurst CC: loops Thread-Topic: [LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery Thread-Index: AdZkwEljFe9neiBoQWmvZQdjub40MQ== Date: Tue, 28 Jul 2020 09:22:55 +0000 Message-ID: <0e2fdf678d224426945bfb14dcf44242@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.74.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 09:23:06 -0000 SGkgR29ycnksDQoNClRoYW5rIHlvdSBmb3IgdGFraW5nIHRpbWUgdG8gcmVhZCB0aHJvdWdoIGl0 LiANCg0KUGxlYXNlIGZpbmQgdGhlIGlubGluZXMgd2l0aCBbeXpdLg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTE9PUFMgW21haWx0bzpsb29wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgR29ycnkgRmFpcmh1cnN0DQpTZW50OiBNb25kYXksIEp1bHkgMjcsIDIw MjAgMTE6MjIgUE0NClRvOiBsb29wcyA8bG9vcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTE9PUFNd IFRyYW5zcG9ydCByZWNvdmVyeSBhbmQgaW50ZXJhY3Rpb24gd2l0aCwgbGluaywgYW5kIExPT1BT IGxvc3MgcmVjb3ZlcnkNCg0KVGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRyb3VibGUgdG8gdXBk YXRlIGRyYWZ0LWxpLXRzdndnLWxvb3BzLXByb2JsZW0tb3Bwb3J0dW5pdGllcywgdGhlIG5ldyB0 ZXh0IGRvZXMgaGVscCBpbiBtYW55IHBsYWNlcywgYW5kIEknbSBzb3JyeSBub3QgdG8gaGF2ZSBy ZXNwb25kZWQgZWFybGllciB0byB0aGlzIG5ldyB0ZXh0LsKgIEkgYW0gc3RpbGwgbm90IGNsZWFy IHlldCB3aGF0IGlzIGFudGNpcGF0ZWQgZnJvbSB0aGUgdHJhbnNwb3J0IGNvbmdlc3Rpb24tY29u dHJvbCByZXNwb25zZS4gUGxlYXNlIHNlZSBjb21tZW50cyBiZWxvdzoNCg0KKDEpIE1vdmluZyBm aWd1cmUgMSBzZWVtcyBoZWxwZnVsIHRvIGludHJvZHVjZSB0aGUgY29udGV4dC4gVGhhbmxrcy4N Cg0KKDIpIEluIFNlY3Rpb24gNjogSSByZWFkIHNlY3Rpb24gNiBhcyBkZXNjcmliaW5nIHR3byBy ZWNvdmVyeSBjYXNlczogT25lIGlzIGFib3V0IER1cEFDSy1iYXNlZCByZWNvdmVyeS4gVGhlIG90 aGVyIHNheXMgaXQgaXMgYWJvdXQgUkFDSyByZWNvdmVyeSwgSSB3b25kZXIgaWYgdGhpcyBpcyBt YWlubHkgdGhlIGNhc2Ugd2hlcmUgdGhlIGR1cEFDSywgd2hlcmUgSSB0aGluayB0aGlzIGlzIGFi b3V0IFRMUCAod2hpY2ggdXNlcyBSQUNLTCkgdG8gc2hvcnQtY3V0IHRoZSBSVE8gYnkgdHJ5aW5n IHRvIHJlY292ZXIgYWZ0ZXIgfjJSVFRzPw0KDQpbeXpdIFNlY3Rpb24gNiBpbnRlbmRlZCB0byBl eHBsYWluIHdoZW4gZTJlIFJBQ0sgaXMgaW4gdXNlLCBlMmUgcmV0cmFuc21pc3Npb24gaXMgbGVz cyBsaWtlbHkgdG8gY29tcGV0ZSB3aXRoIGxvY2FsIHJldHJhbnNtaXNzaW9uLiANCg0KRmxvd3Mg YXJlIGFnZ3JlZ2F0ZWQgaW50byBMT09QUyBlbmFibGVkIHR1bm5lbCBzbyB0YWlsIHByb2Nlc3Np bmcgZm9yIGFnZ3JlZ2F0ZWQgdHJhZmZpYyBpcyByYXJlLiBUaGVuIExPT1BT4oCZIGxvc3MgZGV0 ZWN0aW9uIGFuZCByZWNvdmVyeSB1c3VhbGx5IHRha2VzIG9uZSBtb3JlIGxvY2FsX1NSVFQuIA0K DQpQVE8gPSAyKlNSVFQgIFtSQUNLXQ0KDQpBbiBBQ0sgZm9yIGxvY2FsbHkgcmV0cmFuc21pdHRl ZCBwYWNrZXQgdGFrZXMgKFNSVFQgKyBsb2NhbF9TUlRUKSB0byByZWFjaCBzZW5kZXIuDQpUaGUg cmVjb3Zlcnkgd2lsbCBiZSBmYXN0ZXIgdGhhbiBSQUNLLVRMUCBieSAoMipTUlRUIC0gbG9jYWxf U1JUVCApIGFuZCBhdCB0aGUgc2FtZSB0aW1lIHRoZSBzZW5kZXIgd29u4oCZdCBnZXQgUFRPIGV4 cGlyZWQuDQoNCkkgdGhpbmsgdGhlIGZvbGxvd2luZyB0d28gY29tbWVudHMgKDMpICYgKDQpIGFy ZSBhYm91dCBSQUNLLVRMUCB0b28uIA0KDQpCYXNpY2FsbHkgTE9PUFMgbGV2ZXJhZ2VzIHRoZSBm ZWF0dXJlcyB0aGF0IHRoZSBhZ2dyZWdhdGVkIGZsb3dzIGhhcyBubyAidGFpbHMgbG9zcyIgY29t cGFyZWQgd2l0aCBpbmRpdmlkdWFsIGZsb3cgYW5kIHRoZSBzaG9ydGVyIGRlbGF5IG92ZXIgdGhl IHNlZ21lbnQgdG8gcmVjb3ZlciB0YWlsIGxvc3Mgb2Ygc2luZ2xlIGZsb3cgZmFzdGVyLiBJdCB3 b3VsZCBtYWtlIHNlbmRlciB0cmlnZ2VyIFJBQ0stVExQIFBUTyBsZXNzLiANCg0KWy95el0NCg0K KDMpIEkgdGhpbmsgdGhlIHRleHQgc3VnZ2VzdHMgdGhlc2UgbWlnaHQgaGF2ZSBkaWZmZXJlbnQg aW1wbGljYXRpb25zIG9uIExPT1BTLCB3aGljaCBzZWVtcyByZWFzb25hYmxlLCBhbHRob3VnaCBJ IGhhdmUgcXVlc3Rpb25zOg0KDQrigJxJZiBMT09QUyBuZXR3b3JrIGRvZXMgbm90IGJ1ZmZlciB0 aGUgb3V0LW9mLW9yZGVyIHBhY2tldHMgY2F1c2VkDQogwqDCoMKgwqDCoCBieSBwYWNrZXQgbG9z cywgVENQIHNlbmRlciB3aGljaCB1c2VzIGEgdGltZSBiYXNlZCBsb3NzIGRldGVjdGlvbg0KIMKg wqDCoMKgwqAgbGlrZSBSQUNLIFtJLUQuaWV0Zi10Y3BtLXJhY2tdIHdpbGwgcGVyZm9ybSB3ZWxs IGhlcmUuwqAgSXQgdXNlcw0KIMKgwqDCoMKgwqAgdGhlIG5vdGlvbiBvZiB0aW1lIHRvIHJlcGxh Y2UgdGhlIGNvbnZlbnRpb25hbCBEVVBBQ0sgdGhyZXNob2xkDQogwqDCoMKgwqDCoCBhcHByb2Fj aCB0byBkZXRlY3QgbG9zc2VzLsKgIEhlbmNlIGl0IHByZXZlbnRzIHRoZSBUQ1Agc2VuZGVyIGZy b20NCiDCoMKgwqDCoMKgIGludm9raW5nIGZhc3QgcmV0cmFuc21pdCB0b28gZWFybHkuIOKAnA0K DQooNCkgSW4gU2VjdGlvbiA0LjE6DQoNCuKAnFdoZW4gYSBzZW5kZXIgZG9lcyBub3QgcmVjZWl2 ZSBhbiBBQ0sgZm9yIGEgZ2l2ZW4gc2VnbWVudCB3aXRoaW4NCiDCoMKgIGEgY2VydGFpbiBhbW91 bnQgb2YgdGltZSBjYWxsZWQgcmV0cmFuc21pc3Npb24gdGltZW91dCAoUlRPKSwgaXQgcmUtDQog wqDCoCBzZW5kcyB0aGUgc2VnbWVudCBbUkZDNjI5OF0uwqAgUlRPIGNhbiBiZSBhcyBsb25nIGFz IHNldmVyYWwgc2Vjb25kcy7igJ0NCuKApg0K4oCcRXZlbiB3aGVuDQogwqDCoCB0aGUgbG9zdCBw YWNrZXQgaXMgbm90IGFuIGV4YWN0IHRhaWwsIGl0IGNhbiBwb3NzaWJseSBhZGQgYW5vdGhlciBS VFQNCiDCoMKgIGJlY2F1c2UgdGhlcmUgbWF5IG5vdCBiZSBlbm91Z2ggcGFja2V0cyBpbiBmbGln aHQgdG8gdHJpZ2dlciB0aGUgZmFzdA0KIMKgwqAgcmV0cmFuc21pdCku4oCdDQoNCi0gSSB0aGlu ayB0aGlzIHRleHQgYXJndWVzIHNpbXBseSBmb3IgVExQPw0KDQotIEhvdyB3b3VsZCB0aGUgbWV0 aG9kIGltcG9ydmUgcGVyZm9ybWFuY2UsIGlmIFRMUCB3ZXJlIHRvIGJlIHdpZGVseSBkZXBsb3ll ZCwgc2luY2UgaXQncyBiZWVuIHByb21vdGVkIGZvciBUQ1AgYW5kIHNwZWNpZmllZCBmb3IgUVVJ Qz8NCg0KDQooNSkgQWxzbywgbWF5YmUgSSBtaXN1bmRlcnN0YW5kLCBjYW7igJl0IFJBQ0sgdHJp Z2dlciByZXRyYW5zbWlzc2lvbiBlYXJsaWVyIHRoYW4gdGltZW91dCBmb3IgYSBUTFAgLSB3aGlj aCB0aGUgc3RhcnQgb2YgdGhlIElEIHNhaWQgd2FzIGFuIGltcG9ydGFudCB1c2UtY2FzZT8NCg0K W3l6XSBTb3JyeSwgSSBkaWQgbm90IHF1aXRlIGdldCBpdC4gSSB0aGluayBUTFAgaXMgZm9yIHRh aWwgbG9zcyByZXRyYW5zbWlzc2lvbiB3aGlsZSBSQUNLIHRyaWdnZXIgcmV0cmFuc21pc3Npb24g aXMgZm9yIG5vbi10YWlsIGxvc3MgcmV0cmFuc21pc3Npb24uIE9uZSBjYW5ub3QgcmVwbGFjZSB0 aGUgb3RoZXI/IE9ubHkgUFRPIHdpbGwgZmlyZSBhdCB0aGUgc2VuZGVyIGlmIHRoZSBsb3N0IHBh Y2tldCBpcyBhIHRhaWw/DQoNCg0K4oCcTG9jYWwgcmV0cmFuc21pc3Npb24gd2lsbCBub3QNCiDC oMKgwqDCoMKgIGludGVyZmVyZSB0aGUgc2VuZGVyJ3MgcmV0cmFuc21pc3Npb24gZ2VuZXJhbGx5 IGluIHRoaXMgY2FzZS7CoCBJZg0KIMKgwqDCoMKgwqAgdGltZSBiYXNlZCBsb3NzIGRldGVjdGlv biBpcyBub3Qgc3VwcG9ydGVkIGF0IHRoZSBzZW5kZXIsIGVuZCB0bw0KIMKgwqDCoMKgwqAgZW5k IHJldHJhbnNtaXNzaW9uIG1heSBiZSBpbnZva2VkIGFzIHVzdWFsLsKgIEl0IGNvbnN1bWVzIGV4 dHJhDQogwqDCoMKgwqDCoCBiYW5kd2lkdGggQmVjYXVzZSB0aGUgbG9zdCBwYWNrZXRzIChpLmUu IHJlY292ZXJlZCBwYWNrZXQpIGlzDQogwqDCoMKgwqDCoCBub3JtYWxseSBhIHZlcnkgc21hbGwg cGVyY2VudGFnZSBvZiB0aGUgdG90YWwgcGFja2V0cy7CoCBUaGVuIGV4dHJhDQogwqDCoMKgwqDC oCBiYW5kd2lkdGggY29zdCBpcyBub3Qgc2lnbmlmaWNhbnQu4oCdDQotIEkgZG9u4oCZdCByZWFs bHkgdW5kZXJzdGFuZCB0aGlzIGFyZ3VtZW50LiBJcyB0aGlzIHNheWluZyB0aGVyZSB3aWxsIGJl IGZldyBsb3NzZXMsIGFuZCBoZW5jZSB0aGUgYWRkaXRpb25hbCBjYXBhY2l0eSB1c2VkIGJ5IHJl dHJhbnNtaXNzaW9uIGlzIHNtYWxsLiBJZiB0aGF0IHdhcyBteSBjb3JyZWN0IGludGVycHJldGF0 aW9uLCBob3cgZG9lcyBMT09QUyBrbm93IHRoZXJlIGFyZSBmZXcgbG9zc2VzPyBEb2VzIGl0IG1l YXN1cmUgdGhpcyBhbmQgcmF0ZS1jb250cm9sIGl04oCZcyByZXRyYW5zbWlzc2lvbnMgdG8gZW5z dXJlIHRoaXMsIG9yIG1heWJlIHNvbWUgb3RoZXIgbWV0aG9kIGlzIHVzZWQgdG8gYXZvaWQgdGhl cmUgYmVpbmcgc2lnbmlmaWNhbnQgbG9hZCBmcm9tIHR3byBsZXZlbHMgb2YgcmV0cmFuc21pc3Np b24/DQogIA0KW3l6XQ0KUkFDSyBoYXMgYWRhcHRpdmUgcmUtb3JkZXJpbmcgd2luZG93IGFsZ29y aXRobSB0byBvdmVyY29tZSBwYWNrZXQgcmUtb3JkZXJpbmcgY2F1c2VkIGJ5IHdpcmVsZXNzIGxp bmsgbGF5ZXIgcmV0cmFuc21pc3Npb24gb3IgbG9hZCBiYWxhbmNpbmcgKHNlY3Rpb24gMiBvZiBk cmFmdC1pZXRmLXRjcG0tcmFjay0wOSkuIFNvIGl0IHdvcmtzIHdpdGggTE9PUFMgYmV0dGVyIHRo YW4gdHJhZGl0aW9uYWwgZHVwYWNrIGJhc2VkIGxvc3MgZGV0ZWN0aW9uIGJ5IGludm9raW5nIGxl c3MgdW5uZWNlc3NhcnkgZTJlIHJldHJhbnNtaXNzaW9uLiBTbyB0aGUgY29tcGV0aXRpb24gb2Yg cmV0cmFuc21pc3Npb25zIGlzIG1pbmltdW0uDQpUaGUgdGV4dCBvZiAoMykgYWJvdmUgdHJpZWQg dG8gZWxhYm9yYXRlIG9uIHRoaXMuDQoNCkxPT1BTIGZvY3VzZXMgb24gdGhlIHNob3J0IGZsb3dz IG9yIHRyYW5zYWN0aW9uYWwgZmxvd3MuIElmIGEgbG9zcyByZWNvdmVyZWQgYnkgTE9PUFMgaXMg YSB0YWlsIGxvc3MgZm9yIGFuIGluZGl2aWR1YWwgZmxvdywgdGhlIGZsb3cgc2VuZGVyIHdvdWxk IG5vdCBzdGFydCB0byByZXRyYW5zbWl0IGluIG1vc3QgY2FzZXMgc2luY2UgaXRzIFJUTyAob3Ig UFRPKSBkb2VzIG5vdCBmaXJlLiBIZW5jZSBlMmUgcmV0cmFuc21pc3Npb24gZG9lcyBub3QgY29t cGV0ZSB3aXRoIGxvY2FsIHJldHJhbnNtaXNzaW9uIGluIHN1Y2ggY2FzZS4gVGhpcyBpcyB0aGUg bWFqb3JpdHkgb2YgTE9PUFMgcmVjb3ZlcnkgY2FzZSAoZWFybGllciBUTFAgZHJhZnQgZHJhZnQt ZHVra2lwYXRpLXRjcG0tdGNwLWxvc3MtcHJvYmUtMDEgc2FpZCA3MCUgJiA0NiUgYXJlIFJUTyBi YXNlZCByZXRyYW5zbWlzc2lvbnMgZm9yIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMpLiANCg0KRm9y IHRoZSByZXN0LCB0aGVyZSBtYXkgYmUgZTJlIGFuZCBsb2NhbCByZXRyYW5zbWlzc2lvbiBhdCB0 aGUgc2FtZSB0aW1lLg0KSXQgaXMgZXhwZWN0ZWQgdGhhdCBzb21lIHdheXMgdG8gZW5zdXJlIHRo ZSBsaW1pdGVkIGxvY2FsIHJldHJhbnNtaXNzaW9ucy4gRm9yIGluc3RhbmNlLCBtYWtlIHRoZSBs b2NhbCByZXRyYW5zbWlzc2lvbiBub24tcGVyc2lzdGVudCAoaS5lLiByZXRyYW5zbWl0IG9uY2Ug b25seSksIHNldCBhIHRocmVzaG9sZCBmb3IgYSByZXRyYW5zbWlzc2lvbiBwZXJjZW50YWdlLCBs aW1pdCB0aGUgYnVmZmVyIGF0IExPT1BTIGluZ3Jlc3MgdG8gaG9sZCBsb2NhbCBSVFQgZXF1aXZh bGVudCBvZiBwYWNrZXRzIGV0Yy4gDQpbL3l6XSAgICANCg0KDQooNikgSXMgc29tZSBzb3J0IG9m IGNoZWNrIG5lZWRlZCBhbnl3YXkgcGVyaGFwcz8gQmVjYXVzZSBMT09QUyBjb3VsZCBwb3RlbnRp YWxseSB3b3JrIG92ZXIgYSBwYXRoIHdpdGggTDIgcmV0cmFuc21pc3Npb25zIChlLmcuIFdpRmks IGFuZCBhbnkgbG9vcHMgcmV0cmFuc21pc3Npb25zIG11bHRpcGx5IHRoZSBudW1iZXIgb2YgTDIg cmV0cmFuc21pc3Npb25zPw0KLSBDYW4gTE9PUFMgYmUgdHVubmVsbGVkIG92ZXIgTE9PUFMgaW4g YW55IGNhc2VzPw0KDQpbeXpdIFNvdW5kcyBsaWtlIExPT1BTIGFuZCBMMiByZXRyYW5zbWlzc2lv biBjb3VsZCBiZSBjb21wbGVtZW50YXJ5LiBCdXQgY3Jvc3MgbGF5ZXIgaW5mb3JtYXRpb24gcGFz c2luZyBpcyBhbHdheXMgYSBwcm9ibGVtLiANCg0KKDcpIEkgbm93IHRoaW5rIEkgbWlnaHQgdW5k ZXJzdGFuZCB0aGUgc2NvcGUgb2YgdGhlIHByb3Bvc2VkIHdvcmsgaXMgY29uc3RyYWluZWQgb25s eSB0byBjYXNlcyB3aGVyZSBFQ04gaGFzIGJlZW4gZGVwbG95ZWQgYW5kIGlzIGVuYWJsZWQgZW5k LXRvLWVuZC4gSW4gU2VjdGlvbiA1LjI6DQoNCg0K4oCcTE9PUFMgY2FuIENFKENvbmdlc3Rpb24g RXhwZXJpZW5jZWQpIG1hcmtzDQogwqDCoCBpdHMgcmVjb3ZlcmVkIHBhY2tldHMgYXMgdGhlIGxv c3Mgc2lnbmFsIHRvIGVuZC10by1lbmQuIENvbnZlcnRpbmcgYQ0KIMKgwqAgcGFja2V0IGxvc3Mg c2lnbmFsIHRvIENFIG1hcmtpbmcgc2lnbmFsIGJyaW5ncyB0aGUgYmVuZWZpdHMgb2YNCiDCoMKg IHJlZHVjaW5nIEhlYWQtb2YtTGluZSBibG9ja2luZyBhbmQgcHJvYmFiaWxpdHkgb2YgUlRPIGV4 cGlyeQ0KIMKgwqAgW1JGQzgwODddIHdpdGhvdXQgYWZmZWN0aW5nIFRDUCBzZW5kZXIncyBsb3Nz IGJhc2VkIGNvbmdlc3Rpb24NCiDCoMKgIGNvbnRyb2wgYmVoYXZpb3VyIHdoaWxlIGVuam95aW5n IHRoZSBmYXN0ZXIgbG9jYWwgcmVjb3ZlcnkuIEVDTg0KIMKgwqAgYmFzZWQgaW5kaWNhdGlvbiBp cyBlcXVpdmFsZW50IHRvIGEgbG9zcyBldmVudCBhdCB0aGUgVENQIHNlbmRlcg0KIMKgwqAgW1JG QzMxNjhdLuKAnQ0K4oCmDQrigJwgSW4gdGhpcyB3YXksIGEgcmVxdWlyZW1lbnQgaXMgc2V0IGZv ciBhcHBseWluZyBMT09QUy7igJ0NCg0KSSBzdGlsbCB0aGluayB0aGlzIHdvdWxkIGJlbmVmaXQg ZnJvbSBiZWluZyBjbGVhcmVyIGF0IHRoZSBzdGFydCBvZiB0aGUgZG9jdW1lbnQsIGJlY2F1c2Ug b25seSBFQ1QgKEVDTi1DYXBhYmxlIFRyYW5zcG9ydCkgZmxvd3Mgc2hvdWxkIGJlIGRpcmVjdGVk IHRvIGFuIExPT1BTIGVuYWJsZWQgcGF0aCBzZWdtZW50LCBhcyBJIHRoaW5rIGl0IHNheXM/DQoN Clt5el0gWWVzLCB0aGF0J3MgdGhlIGN1cnJlbnQgc2NvcGUgc2F5aW5nLg0KDQpCZXN0IHdpc2hl cywNCg0KR29ycnkNCg0KLS0NCkxPT1BTIG1haWxpbmcgbGlzdA0KTE9PUFNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Tue Jul 28 03:24:54 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1CD3A0A9B for ; Tue, 28 Jul 2020 03:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 mloAi7pQV5zf for ; Tue, 28 Jul 2020 03:24:48 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC483A0A98 for ; Tue, 28 Jul 2020 03:24:48 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2F6721B00083; Tue, 28 Jul 2020 11:24:44 +0100 (BST) To: Liyizhou Cc: loops References: <0e2fdf678d224426945bfb14dcf44242@huawei.com> From: Gorry Fairhurst Message-ID: <86ed029a-2eb6-1118-5fca-fcbfacf1207c@erg.abdn.ac.uk> Date: Tue, 28 Jul 2020 11:24:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0e2fdf678d224426945bfb14dcf44242@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 10:24:53 -0000 Thanks for getting back, On 28/07/2020 10:22, Liyizhou wrote: > Hi Gorry, > > Thank you for taking time to read through it. > > Please find the inlines with [yz]. > > -----Original Message----- > From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Monday, July 27, 2020 11:22 PM > To: loops > Subject: [LOOPS] Transport recovery and interaction with, link, and LOOPS loss recovery > > Thank you for taking the trouble to update draft-li-tsvwg-loops-problem-opportunities, the new text does help in many places, and I'm sorry not to have responded earlier to this new text.  I am still not clear yet what is antcipated from the transport congestion-control response. Please see comments below: > > (1) Moving figure 1 seems helpful to introduce the context. Thanlks. > > (2) In Section 6: I read section 6 as describing two recovery cases: One is about DupACK-based recovery. The other says it is about RACK recovery, I wonder if this is mainly the case where the dupACK, where I think this is about TLP (which uses RACK) to short-cut the RTO by trying to recover after ~2RTTs? > > [yz] Section 6 intended to explain when e2e RACK is in use, e2e retransmission is less likely to compete with local retransmission. > Flows are aggregated into LOOPS enabled tunnel so tail processing for aggregated traffic is rare. > Then LOOPS’ loss detection and recovery usually takes one more local_SRTT. [gf] OK, so I think you're saying that LOOPS can aggregate flows and when the "short" flows are multiplexed with lots of other traffic, the recovery of tail loss within a specific flow can be completed more efficiently. However, I think this is only true if the "local_SRTT" as you call it is much less than the end-to-end path RTT of the specific flow. To me, this seems to also depend on how much traffic is aggregated, and I think that could be clearer in the text. When I thought of the satellite use-case, I saw the RTT benefits, I just seem quite unsure the aggregation would be sufficient on the terrestrial tail part of the path (e.g. local WiFi at the consumer). [/gf] > > PTO = 2*SRTT [RACK] > > An ACK for locally retransmitted packet takes (SRTT + local_SRTT) to reach sender. > The recovery will be faster than RACK-TLP by (2*SRTT - local_SRTT ) and at the same time the sender won’t get PTO expired. > > I think the following two comments (3) & (4) are about RACK-TLP too. > > Basically LOOPS leverages the features that the aggregated flows has no "tails loss" compared with individual flow and the shorter delay over the segment to recover tail loss of single flow faster. It would make sender trigger RACK-TLP PTO less. > > [/yz] [gf] So... I that would be helpful to see data about how much less. [/gf] > > (3) I think the text suggests these might have different implications on LOOPS, which seems reasonable, although I have questions: > > “If LOOPS network does not buffer the out-of-order packets caused >       by packet loss, TCP sender which uses a time based loss detection >       like RACK [I-D.ietf-tcpm-rack] will perform well here.  It uses >       the notion of time to replace the conventional DUPACK threshold >       approach to detect losses.  Hence it prevents the TCP sender from >       invoking fast retransmit too early. “ > > (4) In Section 4.1: > > “When a sender does not receive an ACK for a given segment within >    a certain amount of time called retransmission timeout (RTO), it re- >    sends the segment [RFC6298].  RTO can be as long as several seconds.” > … > “Even when >    the lost packet is not an exact tail, it can possibly add another RTT >    because there may not be enough packets in flight to trigger the fast >    retransmit).” > > - I think this text argues simply for TLP? > > - How would the method improve performance, if TLP were to be widely deployed, since it's been promoted for TCP and specified for QUIC? > > > (5) Also, maybe I misunderstand, can’t RACK trigger retransmission earlier than timeout for a TLP - which the start of the ID said was an important use-case? > > [yz] Sorry, I did not quite get it. I think TLP is for tail loss retransmission while RACK trigger retransmission is for non-tail loss retransmission. One cannot replace the other? Only PTO will fire at the sender if the lost packet is a tail? [gf] I found the ID text is a little confusing. [/gf] > > “Local retransmission will not >       interfere the sender's retransmission generally in this case.  If >       time based loss detection is not supported at the sender, end to >       end retransmission may be invoked as usual.  It consumes extra >       bandwidth Because the lost packets (i.e. recovered packet) is >       normally a very small percentage of the total packets.  Then extra >       bandwidth cost is not significant.” > - I don’t really understand this argument. Is this saying there will be few losses, and hence the additional capacity used by retransmission is small. If that was my correct interpretation, how does LOOPS know there are few losses? Does it measure this and rate-control it’s retransmissions to ensure this, or maybe some other method is used to avoid there being significant load from two levels of retransmission? > > [yz] > RACK has adaptive re-ordering window algorithm to overcome packet re-ordering caused by wireless link layer retransmission or load balancing (section 2 of draft-ietf-tcpm-rack-09). So it works with LOOPS better than traditional dupack based loss detection by invoking less unnecessary e2e retransmission. So the competition of retransmissions is minimum. > The text of (3) above tried to elaborate on this. > > LOOPS focuses on the short flows or transactional flows. If a loss recovered by LOOPS is a tail loss for an individual flow, the flow sender would not start to retransmit in most cases since its RTO (or PTO) does not fire. > Hence e2e retransmission does not compete with local retransmission in such case. This is the majority of LOOPS recovery case (earlier TLP draft draft-dukkipati-tcpm-tcp-loss-probe-01 said 70% & 46% are RTO based retransmissions for different applications). > > For the rest, there may be e2e and local retransmission at the same time. > It is expected that some ways to ensure the limited local retransmissions. For instance, make the local retransmission non-persistent (i.e. retransmit once only), set a threshold for a retransmission percentage, limit the buffer at LOOPS ingress to hold local RTT equivalent of packets etc. > [/yz] [gf] I think now you refer to the case without TLP? - With TLP, the sender would probe? So, I'm more interested about the data you can show us that the latest RACK spec has issues. [/gf] > > > (6) Is some sort of check needed anyway perhaps? Because LOOPS could potentially work over a path with L2 retransmissions (e.g. WiFi, and any loops retransmissions multiply the number of L2 retransmissions? > - Can LOOPS be tunnelled over LOOPS in any cases? > > [yz] Sounds like LOOPS and L2 retransmission could be complementary. But cross layer information passing is always a problem. [gf] Yes. For instance, this seems quite like what my WiFi link might be doing? and it chooses a certain number of retransmnissions, and LOOPS effectively does more retransmissions/FEC on top of that ... that could be a really good reason not to do LOOPS optimisation? [/gf] > (7) I now think I might understand the scope of the proposed work is constrained only to cases where ECN has been deployed and is enabled end-to-end. In Section 5.2: > > > “LOOPS can CE(Congestion Experienced) marks >    its recovered packets as the loss signal to end-to-end. Converting a >    packet loss signal to CE marking signal brings the benefits of >    reducing Head-of-Line blocking and probability of RTO expiry >    [RFC8087] without affecting TCP sender's loss based congestion >    control behaviour while enjoying the faster local recovery. ECN >    based indication is equivalent to a loss event at the TCP sender >    [RFC3168].” > … > “ In this way, a requirement is set for applying LOOPS.” > > I still think this would benefit from being clearer at the start of the document, because only ECT (ECN-Capable Transport) flows should be directed to an LOOPS enabled path segment, as I think it says? > > [yz] Yes, that's the current scope saying. > > Best wishes, > > Gorry > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops Best wishes, Gorry From nobody Tue Jul 28 11:10:38 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5F83A0AA6 for ; Tue, 28 Jul 2020 11:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pCVmeK0s-9Fr for ; Tue, 28 Jul 2020 11:10:34 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 62C313A0AA5 for ; Tue, 28 Jul 2020 11:10:34 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 140so11519121lfi.5 for ; Tue, 28 Jul 2020 11:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jq+2G8trI/WpSE01VcIHCJQZ+zp/lQVZ9b7Il+ODMz4=; b=uqhImoiS5fldqrex4m/p+oVEGv0jUQjjbdbFPk/pzDyImE/h4XMIs6DfIOCMlZeswo mg75GAjFD41fK+POiZlQDz67XGrdoQZp2D0yieP973fYHid64lYDJkobTCJSzqKWCmXU 2RANdgk2ufeUaHLeq0ZLrkDX7Mw5ioJQVgAqdsPBxLVmSpyDNHxDNSR4lSpVoDYiUXnd slPwBqj7v/bMxSgtSiEh3i6HNo/bc0No2XukIQK1LKqXmUv0E29ixwSbRGwXA+lf1XGc QtbAQoGCjzMIjAgoD6BZkqjAUGvDv6RLTQm6PkdpXls+G0KmPX4h94LWyjiXz00SyjR8 D3KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jq+2G8trI/WpSE01VcIHCJQZ+zp/lQVZ9b7Il+ODMz4=; b=txPxonsndt6gVeSxt6kYRdSZjezPA+0DEocuTxJAvort9d79kng6oFC5mNIUE8FjCE aO/veAqLKBSLI4zCpa8Y/orwa5RLsf43oBlolU373yh6LB54wl5Oi+d2E8Anxd5lvwzv CdsNQtNyctl88yT1EXAN0UEEMAZQ3P2ixmP9+BTFHFrtFOzScUDFkqMz712PC1PEi2Wp 0rZKwWCRPpVCNwuB2XMpKHrCtTksGAG8V7Or0/oH0lpgKYSY1Ly/d/9cb9WeW0/uYBy5 SJCTHLFOLB8CnBW2BJdRWuRwoHyjUny+aaMgDag8aio8F5ehO6n4cWKSdQiZ8h4rD0Ex iKZQ== X-Gm-Message-State: AOAM5324kKy8jJRzWwUZsZO2U+nWXFEhxx3zXZs3u1l9HX0bjmLh1+1L ycjMI47Hix8XfJCz0IxuGVm1tA+lkTyR72hRq2Ky6g== X-Google-Smtp-Source: ABdhPJxR0b1IfFPjStEeDqfgDql3URKSOtn4vZKA1k4Te1Shbk11qzPlOUBJVVP9m8oYxGuxt9+dhbEt++rZSRbF07s= X-Received: by 2002:a19:d14:: with SMTP id 20mr15067008lfn.27.1595959832578; Tue, 28 Jul 2020 11:10:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 28 Jul 2020 13:10:06 -0500 Message-ID: To: Gorry Fairhurst Cc: loops Content-Type: multipart/alternative; boundary="000000000000e5921c05ab845af6" Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 18:10:37 -0000 --000000000000e5921c05ab845af6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as an individual, On Mon, Jul 27, 2020 at 10:22 AM Gorry Fairhurst wrote: > Thank you for the scenarios update in > draft-li-tsvwg-loops-problem-opportunities, I see you have updated the > text relating to satellite network segments. I now have some more > questions on scenarios based on the what is said in the most recent ID: > > (1) The text says: > > "By continuously measuring the > delay of path segments and use them as metrics for path selection, > when the number of overlay nodes is sufficiently large, there is a > high chance that a better path could be found > [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560]. > [DOI_10.1145_3038912.3052560] further shows all cloud providers > experience random loss episodes and random loss accounts for more > than 35% of total loss." > > - I think this use case was presented in previuous meetings, and one of > the questions was how to react appropiately to route changes and traffic > engineering by the physical network operator. This doesn't come across > to me in the latest text. > > (2) I will argue there is not a satellite-specific use case really, > there is a use case for any reliable long-haul path (large RTT) that is > concatenated with another segment with a lossy segment with lower RTT. > I've probably been using "satellite" as a mental shorthand for "long haul/large RTT" without meaning to, for years (plus Gorry's mention of another path segment with shorter RTT and losses). I think that's an important thing to remember when we're talking about use cases - we need to focus on the problematic aspects of the path, rather than focusing on why a specific path has those problems, in order to identify the problems we're trying to solve. There are many more kinds of problematic paths than kinds of problems with paths :-) Thanks, Gorry, for the comment. Best, Spencer > =E2=80=9CEnhanced error recovery at the satellite link layer > helps for the loss on the satellite link but doesn't help for the > terrestrial links. Even when the terrestrial segments are short, any > loss must be recovered across the satellite link delay.=E2=80=9D > - I think the argument is really that the end-to-end internet path > using a satellite network segment can be long (large RTT), and therefore > that loss experienced at any point outside the satellite network segment > still suffers performance because of the larger RTT. > - If that is the case, then I think a GEO satellite path is an > **example** of such a path. > is this a =E2=80=9Clong terrestrial=E2=80=9D path? or a long Internet pat= h? > - =E2=80=9CFaster recovery over such > long terrestrial segments is desirable.=E2=80=9D > > (3) The previous revision mentioned the specific case where the =E2=80=9C= network > is long-haul=E2=80=9D, but I think this aspect was removed in the latest = rev?. > Maybe I don=E2=80=99t fully see - is it expected (or somehow known) that = the > delay for the LOOPS path segment is much less than the end-to-end path > (in Section 1)? How does the LOOPS path segment know this? > > (4) I see you also mention in the latest rev adds a use case for a > "fleet of drones" - I'm not quite sure what this is describing, maybe > you could expand how this works, and add some text to the draft. > > Gorry > > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000e5921c05ab845af6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an individual,=C2=A0
On Mon, J= ul 27, 2020 at 10:22 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
Thank you for the scenarios update in
draft-li-tsvwg-loops-problem-opportunities, I see you have updated the
text relating to satellite network segments. I now have some more
questions on scenarios based on the what is said in the most recent ID:

(1) The text says:

"By continuously measuring the
=C2=A0=C2=A0=C2=A0 delay of path segments and use them as metrics for path = selection,
=C2=A0=C2=A0=C2=A0 when the number of overlay nodes is sufficiently large, = there is a
=C2=A0=C2=A0=C2=A0 high chance that a better path could be found
=C2=A0=C2=A0=C2=A0 [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560= ].
=C2=A0=C2=A0=C2=A0 [DOI_10.1145_3038912.3052560] further shows all cloud pr= oviders
=C2=A0=C2=A0 experience random loss episodes and random loss accounts for m= ore
=C2=A0=C2=A0=C2=A0 than 35% of total loss."

- I think this use case was presented in previuous meetings, and one of the questions was how to react appropiately to route changes and traffic engineering by the physical network operator. This doesn't come across =
to me in the latest text.

(2) I will argue there is not a satellite-specific use case really,
there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT.
<= /blockquote>

I've probably been using "satellit= e" as a mental shorthand for "long haul/large RTT" without m= eaning to, for years (plus Gorry's mention of another path segment with= shorter RTT and losses). I think that's an important thing to remember= when we're talking about use cases - we need to focus on the problemat= ic aspects of the path, rather than focusing on why a specific path has tho= se problems, in order to identify the problems we're trying to solve.= =C2=A0

There are many more kinds of problematic pa= ths than kinds of problems with paths :-)

Than= ks, Gorry, for the comment.

Best,

Spencer
=C2=A0
=C2=A0 =E2=80=9CEnhanced error recovery at the satellite link= layer
=C2=A0=C2=A0=C2=A0 helps for the loss on the satellite link but doesn't= help for the
=C2=A0=C2=A0=C2=A0 terrestrial links.=C2=A0 Even when the terrestrial segme= nts are short, any
=C2=A0=C2=A0=C2=A0 loss must be recovered across the satellite link delay.= =E2=80=9D
-=C2=A0 I think the argument is really that the end-to-end internet path using a satellite network segment can be long (large RTT), and therefore that loss experienced at any point outside the satellite network segment still suffers performance because of the larger RTT.
- If that is the case, then I think a GEO satellite path is an
**example** of such a path.
is this a =E2=80=9Clong terrestrial=E2=80=9D path? or a long Internet path?=
- =E2=80=9CFaster recovery over such
=C2=A0=C2=A0=C2=A0 long terrestrial segments is desirable.=E2=80=9D

(3) The previous revision mentioned the specific case where the =E2=80=9Cne= twork
is long-haul=E2=80=9D, but I think this aspect was removed in the latest re= v?.
Maybe I don=E2=80=99t fully see - is it expected (or somehow known) that th= e
delay for the LOOPS path segment is much less than the end-to-end path
(in Section 1)? How does the LOOPS path segment know this?

(4) I see you also mention in the latest rev adds a use case for a
"fleet of drones" - I'm not quite sure what this is describin= g, maybe
you could expand how this works, and add some text to the draft.

Gorry


--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--000000000000e5921c05ab845af6-- From nobody Tue Jul 28 23:14:52 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CF73A10B4 for ; Tue, 28 Jul 2020 23:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 7YfaCM2mT5OC for ; Tue, 28 Jul 2020 23:14:43 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F0C3A104D for ; Tue, 28 Jul 2020 23:14:32 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4BGjtZ1jwyz12vb; Wed, 29 Jul 2020 08:14:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596003270; bh=4ZKsqZjRjmIVUlV/+PRuBU1oZnaeUyjX219yNRecw98=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Z15VoHYFSjeX7m06lPsCkWyk/veDWBIIZRlHFLv69G2Rdj474cOPQ56oFCs991Zfz c6oMKkFsNrDSvNLe7NSau3PcyH8W5XoS6VOQpes2eWhFq16jJ3hXg0kIddkpDJ1Y3c jk9E0Qdj1bLtDSBbHkyXOO5Mb2qRZ+ycEAVsJJVmII1CqvIhJDIDhvadbgMxgKm/uQ +qwQx8wc9sNH/qs2Kwaop/b7/gwfhPj/AYkwALIJJxx4VIPQdVp/rVNXn9E64Naj0O 1FTX6mWP1nFCR3R1zD2LNf1SxhsjxBeyVq3g7oaof5AkTtAmMkui1gq8z4fCHjAkBQ pudXXSYavk6Vw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4BGjtZ0vqZzyQ9; Wed, 29 Jul 2020 08:14:30 +0200 (CEST) From: To: Gorry Fairhurst , loops Thread-Topic: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. Thread-Index: AQHWZCnQ6fL3rTtNFU2Hd0GNbsYztqkeFBsQ Date: Wed, 29 Jul 2020 06:14:29 +0000 Message-ID: <13424_1596003270_5F2113C6_13424_401_1_787AE7BB302AE849A7480A190F8B9330315069E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 06:14:51 -0000 SGkgR29ycnksIA0KDQpJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgdGV4dDogDQoN CiAgIFNpbWlsYXIgaXNzdWVzIGFuZCBvcHRpbWl6YXRpb25zDQogICBtYXkgYmUgaGVscGZ1bCBp biBvdGhlciBkZXBsb3ltZW50cyBzdWNoIGFzIGVuaGFuY2luZyB0aGUgcmVsaWFiaWxpdHkNCiAg IG9mIGRhdGEgdHJhbnNmZXIgd2hlbiBhIGZsZWV0IG9mIGRyb25lcyBhcmUgdXNlZCBmb3Igc3Bl Y2lmaWMNCiAgIG1pc3Npb25zIChlLmcuLCBzaXRlIGluc3BlY3Rpb24sIGxpdmUgc3RyZWFtaW5n LCBhbmQgZW1lcmdlbmN5DQogICBzZXJ2aWNlKS4gIENhcHR1cmVkIGRhdGEgc2hvdWxkIGJlIHJl bGlhYmx5IHRyYW5zbWl0dGVkIHZpYSBwYXRocw0KICAgaW52b2x2aW5nIHJhZGlvIGNvbm5lY3Rp b25zLg0KDQpBY3R1YWxseSwgdGhpcyBpcyBhbiBvbGQgdGV4dC4gVGhlIG1haW4gcG9pbnQgd2Ug d2FudGVkIHRvIGNvbnZleSBoZXJlIGlzIHRoYXQgd2hlbiBhIHN3YXJtIG9mIGRyb25lcyBpcyBj b2xsYWJvcmF0aW5nIGZvciBleGFtcGxlIHRvIHByb3ZpZGUgY29ubmVjdGl2aXR5LCBtdWx0aXBs ZSBkcm9uZXMgKHNlZW4gYWQgYXMgZm9yd2FyZGVycykgd2lsbCBiZSBzb2xpY2l0ZWQgdGlsbCBw YWNrZXRzIGFyZSAoaG9wZWZ1bGx5KSBkZWxpdmVyZWQgdG8gYSBuZXR3b3JrIHdoZXJlIHRoZSBm bGVldCBvZiBkcm9uZXMgaXMgZ3JhZnRlZCAoY2FuIGJlIGEgM0dQUCBjb3JlIG5ldHdvcmspLiBU aGUgaWRlYSB3ZSBoYWQgaW4gbWluZCBpcyB0aGF0IExPT1BTIGNhbiBiZSBlbmFibGVkIGluIHN1 Y2ggbXV0bGktaG9wIHdpcmVsZXNzIG5ldHdvcmsgKGNvbXBvc2VkIG9mIGRyb25lcykgZm9yIHRo ZSBzYWtlIG9mIHBlcmZvcm1hbmNlIG9wdGltaXphdGlvbi4gDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBMT09QUyBbbWFpbHRvOmxvb3Bz LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgR29ycnkNCj4gRmFpcmh1cnN0DQo+IEVu dm95w6nCoDogbHVuZGkgMjcganVpbGxldCAyMDIwIDE3OjIyDQo+IMOAwqA6IGxvb3BzIDxsb29w c0BpZXRmLm9yZz4NCj4gT2JqZXTCoDogW0xPT1BTXSBkcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9i bGVtLW9wcG9ydHVuaXRpZXMgYW5kIHVzZS0NCj4gY2FzZXMuDQo+IA0KPiBUaGFuayB5b3UgZm9y IHRoZSBzY2VuYXJpb3MgdXBkYXRlIGluDQo+IGRyYWZ0LWxpLXRzdndnLWxvb3BzLXByb2JsZW0t b3Bwb3J0dW5pdGllcywgSSBzZWUgeW91IGhhdmUgdXBkYXRlZCB0aGUNCj4gdGV4dCByZWxhdGlu ZyB0byBzYXRlbGxpdGUgbmV0d29yayBzZWdtZW50cy4gSSBub3cgaGF2ZSBzb21lIG1vcmUNCj4g cXVlc3Rpb25zIG9uIHNjZW5hcmlvcyBiYXNlZCBvbiB0aGUgd2hhdCBpcyBzYWlkIGluIHRoZSBt b3N0IHJlY2VudA0KPiBJRDoNCj4gDQo+IA0KPiAoNCkgSSBzZWUgeW91IGFsc28gbWVudGlvbiBp biB0aGUgbGF0ZXN0IHJldiBhZGRzIGEgdXNlIGNhc2UgZm9yIGENCj4gImZsZWV0IG9mIGRyb25l cyIgLSBJJ20gbm90IHF1aXRlIHN1cmUgd2hhdCB0aGlzIGlzIGRlc2NyaWJpbmcsIG1heWJlDQo+ IHlvdSBjb3VsZCBleHBhbmQgaG93IHRoaXMgd29ya3MsIGFuZCBhZGQgc29tZSB0ZXh0IHRvIHRo ZSBkcmFmdC4NCj4gDQo+IEdvcnJ5DQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Jul 29 04:25:35 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3814B3A092F for ; Wed, 29 Jul 2020 04:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 VEU9xmQ4jEq3 for ; Wed, 29 Jul 2020 04:25:29 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7863E3A092D for ; Wed, 29 Jul 2020 04:25:29 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id AECEC1B0019B; Wed, 29 Jul 2020 12:25:07 +0100 (BST) To: mohamed.boucadair@orange.com, loops References: <13424_1596003270_5F2113C6_13424_401_1_787AE7BB302AE849A7480A190F8B9330315069E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Gorry Fairhurst Message-ID: <1fe93d0a-6765-1fa8-1627-1aea91e0b40d@erg.abdn.ac.uk> Date: Wed, 29 Jul 2020 12:25:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <13424_1596003270_5F2113C6_13424_401_1_787AE7BB302AE849A7480A190F8B9330315069E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 11:25:33 -0000 Hi med, On 29/07/2020 07:14, mohamed.boucadair@orange.com wrote: > Hi Gorry, > > I guess you are referring to this text: > > Similar issues and optimizations > may be helpful in other deployments such as enhancing the reliability > of data transfer when a fleet of drones are used for specific > missions (e.g., site inspection, live streaming, and emergency > service). Captured data should be reliably transmitted via paths > involving radio connections. > > Actually, this is an old text. The main point we wanted to convey here is that when a swarm of drones is collaborating for example to provide connectivity, multiple drones (seen ad as forwarders) will be solicited till packets are (hopefully) delivered to a network where the fleet of drones is grafted (can be a 3GPP core network). The idea we had in mind is that LOOPS can be enabled in such mutli-hop wireless network (composed of drones) for the sake of performance optimization. > > Cheers, > Med So this use case probably needs more text. I think you're saying drones are an example of a network with continuously changing paths. To me, mitigating the impacts of handover likely does expose some interesting constraints on the designs for LOOPS as well as on the performance.  I haven't though about what that means wrt to using ECN and path information. Gorry >> -----Message d'origine----- >> De : LOOPS [mailto:loops-bounces@ietf.org] De la part de Gorry >> Fairhurst >> Envoyé : lundi 27 juillet 2020 17:22 >> À : loops >> Objet : [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use- >> cases. >> >> Thank you for the scenarios update in >> draft-li-tsvwg-loops-problem-opportunities, I see you have updated the >> text relating to satellite network segments. I now have some more >> questions on scenarios based on the what is said in the most recent >> ID: >> >> >> (4) I see you also mention in the latest rev adds a use case for a >> "fleet of drones" - I'm not quite sure what this is describing, maybe >> you could expand how this works, and add some text to the draft. >> >> Gorry >> > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Wed Jul 29 14:52:12 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143AF3A053E for ; Wed, 29 Jul 2020 14:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 mKRjPiM7YkYj for ; Wed, 29 Jul 2020 14:52:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287783A0476 for ; Wed, 29 Jul 2020 14:52:03 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BH6hL2H2HzyWw; Wed, 29 Jul 2020 23:52:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 29 Jul 2020 23:52:01 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 617752321.53552-5fe5166d348586f8437c0f82b4cd3b75 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> References: To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:52:09 -0000 Hi Gorry, thank you for these comments. One of the shortcomings that this document has is that, in describing = scenarios, it does not always make perfectly clear which part is solved = by LOOPS and which parts need to be solved by other means so the = scenario works and LOOPS is effective. On 2020-07-27, at 17:21, Gorry Fairhurst wrote: >=20 > Thank you for the scenarios update in = draft-li-tsvwg-loops-problem-opportunities, I see you have updated the = text relating to satellite network segments. I now have some more = questions on scenarios based on the what is said in the most recent ID: >=20 > (1) The text says: >=20 > "By continuously measuring the > delay of path segments and use them as metrics for path selection, > when the number of overlay nodes is sufficiently large, there is a > high chance that a better path could be found > [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560]. > [DOI_10.1145_3038912.3052560] further shows all cloud providers > experience random loss episodes and random loss accounts for more > than 35% of total loss." >=20 > - I think this use case was presented in previuous meetings, and one = of the questions was how to react appropiately to route changes and = traffic engineering by the physical network operator. This doesn't come = across to me in the latest text. The document is not explicit about that, but path selection is not = something LOOPS would be doing. The SDN controller that sets up these = paths would add LOOPS support to those segments that need it (which is = what the last sentence is about: These segments exist!). LOOPS is = really just about loss recovery. Some of the measurements that LOOPS = carries out will be useful for the SDN controller to make path selection = decisions; we would expect a management interface will make these = measurements available to the SDN controller. > (2) I will argue there is not a satellite-specific use case really, = there is a use case for any reliable long-haul path (large RTT) that is = concatenated with another segment with a lossy segment with lower RTT. Yes! (For a definition of =E2=80=9Creliable=E2=80=9D.) > =E2=80=9CEnhanced error recovery at the satellite link layer > helps for the loss on the satellite link but doesn't help for the > terrestrial links. Even when the terrestrial segments are short, = any > loss must be recovered across the satellite link delay.=E2=80=9D > - I think the argument is really that the end-to-end internet path = using a satellite network segment can be long (large RTT), and therefore = that loss experienced at any point outside the satellite network segment = still suffers performance because of the larger RTT. > - If that is the case, then I think a GEO satellite path is an = **example** of such a path. > is this a =E2=80=9Clong terrestrial=E2=80=9D path? or a long Internet = path? > - =E2=80=9CFaster recovery over such > long terrestrial segments is desirable.=E2=80=9D A long Internet path (that is still not at the level of RTT a GEO sat = gives you.) > (3) The previous revision mentioned the specific case where the = =E2=80=9Cnetwork is long-haul=E2=80=9D, but I think this aspect was = removed in the latest rev?. Maybe I don=E2=80=99t fully see - is it = expected (or somehow known) that the delay for the LOOPS path segment is = much less than the end-to-end path (in Section 1)? That is the configuration where you get the most benefit. > How does the LOOPS path segment know this? It can=E2=80=99t. The aggregate that LOOPS is repairing may be mixed = out of quite different end-to-end paths. LOOPS does not have a way to = measure the RTT of those paths (*). A recommendation for the proper use = of LOOPS would be that it is not very useful to run LOOPS on a segment = that covers most of the span of the end-to-end path, but LOOPS cannot = know that this was done, and it is not going to dramatically break = traffic that has such a mix. If LOOPS does little good, due to its cost = (additional reverse packets, processing/memory, tunneling if that = wasn=E2=80=99t already in use) it is a pessimization; many optimizations = have regions of operation in which they don't. > (4) I see you also mention in the latest rev adds a use case for a = "fleet of drones" - I'm not quite sure what this is describing, maybe = you could expand how this works, and add some text to the draft. I think Med answered that =E2=80=94 I don=E2=80=99t think that is a use = case the operators interested in this have today :-) Gr=C3=BC=C3=9Fe, Carsten (*) Well, vendors could add some secret sauce to actually do this, for = certain cases. But it is not the LOOPS protocol that will do that for = them, and LOOPS does not depend on it. From nobody Thu Jul 30 01:25:10 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9CE3A0FA2 for ; Thu, 30 Jul 2020 01:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 P85o9ZGzuTym for ; Thu, 30 Jul 2020 01:25:04 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B65333A0FA3 for ; Thu, 30 Jul 2020 01:25:03 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 56FA61B001C2; Thu, 30 Jul 2020 09:24:45 +0100 (BST) To: Carsten Bormann Cc: loops References: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> From: Gorry Fairhurst Message-ID: Date: Thu, 30 Jul 2020 09:24:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 08:25:08 -0000 Hi Carston, On 29/07/2020 22:52, Carsten Bormann wrote: > Hi Gorry, > > thank you for these comments. > > One of the shortcomings that this document has is that, in describing scenarios, it does not always make perfectly clear which part is solved by LOOPS and which parts need to be solved by other means so the scenario works and LOOPS is effective. I think this is exactly my feeling, and to me this is important to understand any WG BoF. It helps to be able to separate specific applicability for general use and focussed on specific problems; and separate the proposed technology, from dependent technology and separable technologies. > On 2020-07-27, at 17:21, Gorry Fairhurst wrote: >> Thank you for the scenarios update in draft-li-tsvwg-loops-problem-opportunities, I see you have updated the text relating to satellite network segments. I now have some more questions on scenarios based on the what is said in the most recent ID: >> >> (1) The text says: >> >> "By continuously measuring the >> delay of path segments and use them as metrics for path selection, >> when the number of overlay nodes is sufficiently large, there is a >> high chance that a better path could be found >> [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560]. >> [DOI_10.1145_3038912.3052560] further shows all cloud providers >> experience random loss episodes and random loss accounts for more >> than 35% of total loss." >> >> - I think this use case was presented in previuous meetings, and one of the questions was how to react appropiately to route changes and traffic engineering by the physical network operator. This doesn't come across to me in the latest text. > The document is not explicit about that, but path selection is not something LOOPS would be doing. The SDN controller that sets up these paths would add LOOPS support to those segments that need it (which is what the last sentence is about: These segments exist!). See below [GF]. > LOOPS is really just about loss recovery. Some of the measurements that LOOPS carries out will be useful for the SDN controller to make path selection decisions; we would expect a management interface will make these measurements available to the SDN controller. > OK. >> (2) I will argue there is not a satellite-specific use case really, there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT. > Yes! > (For a definition of “reliable”.) OK. >> “Enhanced error recovery at the satellite link layer >> helps for the loss on the satellite link but doesn't help for the >> terrestrial links. Even when the terrestrial segments are short, any >> loss must be recovered across the satellite link delay.” >> - I think the argument is really that the end-to-end internet path using a satellite network segment can be long (large RTT), and therefore that loss experienced at any point outside the satellite network segment still suffers performance because of the larger RTT. >> - If that is the case, then I think a GEO satellite path is an **example** of such a path. >> is this a “long terrestrial” path? or a long Internet path? >> - “Faster recovery over such >> long terrestrial segments is desirable.” > A long Internet path (that is still not at the level of RTT a GEO sat gives you.) > >> (3) The previous revision mentioned the specific case where the “network is long-haul”, but I think this aspect was removed in the latest rev?. Maybe I don’t fully see - is it expected (or somehow known) that the delay for the LOOPS path segment is much less than the end-to-end path (in Section 1)? > That is the configuration where you get the most benefit. And the converse appears also the case where LOOPS has the potential for most negative interactions with end-to-end recovery? >> How does the LOOPS path segment know this? > It can’t. That's an issue. > The aggregate that LOOPS is repairing may be mixed out of quite different end-to-end paths. See (a). > LOOPS does not have a way to measure the RTT of those paths (*). A recommendation for the proper use of LOOPS would be that it is not very useful to run LOOPS on a segment that covers most of the span of the end-to-end path, but LOOPS cannot know that this was done, and it is not going to dramatically break traffic that has such a mix. If LOOPS does little good, due to its cost (additional reverse packets, processing/memory, tunneling if that wasn’t already in use) it is a pessimization; many optimizations have regions of operation in which they don't. I would like to understand the potential for harm... to. >> (4) I see you also mention in the latest rev adds a use case for a "fleet of drones" - I'm not quite sure what this is describing, maybe you could expand how this works, and add some text to the draft. > I think Med answered that — I don’t think that is a use case the operators interested in this have today :-) That thread was interesting, but it seemed to create additional issues - it might be worth deciding whether that is included in the next rev of the document. > Grüße, Carsten > > (*) Well, vendors could add some secret sauce to actually do this, for certain cases. But it is not the LOOPS protocol that will do that for them, and LOOPS does not depend on it. :-). [GF] I'm now trying to understand how the "SDN" controller can know which flows in the aggregates support ECN:  At what point can an aggregated tunnel egress assume that it is safe to translate a tunnel loss into a flow ECN CE-mark? Example: (Would only established ECN-capable flows added to the aggregate? ... Translating loss at the start of a flow into a CE-mark has a strange effect when the sender is probing for support, but a recipient doesn't report CE-marks?) Gorry From nobody Thu Jul 30 02:07:11 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4CB3A0FF5 for ; Thu, 30 Jul 2020 02:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 0DnYaLfhlbFl for ; Thu, 30 Jul 2020 02:07:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8607A3A0FF4 for ; Thu, 30 Jul 2020 02:06:31 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4BHPfZ0wZ4z22xq; Thu, 30 Jul 2020 11:06:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596099990; bh=lMKF/4/6k9twdx0QbRaT3ktOlDbmI0z3fCWY6R5FrA8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JEjJSCLM1y3kqDPE3ZPjRfNrwfnr9uPLzgwlX3ziMxMiajsw67yTnv6cszRyi+h0x mdeRjdOIDG5IpERgi7+E1jJ8YeIdtmHXSQpIJmlQ7x5JkfFf0qscOH7kZe+eWPe/5Z +TRaIhV+9JwCxeG66h/xLEoCLY9XCqgguo+xk+o0qybhpPfgIZDDrHSLn5KRrD0cPV 1PvB+nsoZHxuB6P8CbDdDVbRJIrbVCZKateHqklTMJebb+nZttyZX9OZB5k+E5Nx1V So8dmdUMYgsdZs7M3FBpvON/G/AGdhhOueVBgS/C9gwn4mU1oyKq3JgllNqsbxtPt8 tQhmXt82jzq6A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4BHPfV5VsBz8sYV; Thu, 30 Jul 2020 11:06:26 +0200 (CEST) From: To: Gorry Fairhurst , loops Thread-Topic: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. Thread-Index: AQHWZZrl6fL3rTtNFU2Hd0GNbsYztqkf1NTQ Date: Thu, 30 Jul 2020 09:06:26 +0000 Message-ID: <29019_1596099990_5F228D96_29019_250_1_787AE7BB302AE849A7480A190F8B933031508EC2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <13424_1596003270_5F2113C6_13424_401_1_787AE7BB302AE849A7480A190F8B9330315069E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1fe93d0a-6765-1fa8-1627-1aea91e0b40d@erg.abdn.ac.uk> In-Reply-To: <1fe93d0a-6765-1fa8-1627-1aea91e0b40d@erg.abdn.ac.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 09:07:08 -0000 SGkgR29ycnksIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEdvcnJ5IEZhaXJodXJzdCBbbWFpbHRv OmdvcnJ5QGVyZy5hYmRuLmFjLnVrXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI5IGp1aWxsZXQg MjAyMCAxMzoyNQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPjsgbG9vcHMNCj4gPGxvb3BzQGlldGYub3JnPg0KPiBPYmpldMKg OiBSZTogW0xPT1BTXSBkcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMg YW5kDQo+IHVzZS1jYXNlcy4NCj4gDQo+IEhpIG1lZCwNCj4gDQo+IE9uIDI5LzA3LzIwMjAgMDc6 MTQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gSGkgR29ycnksDQo+ ID4NCj4gPiBJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgdGV4dDoNCj4gPg0KPiA+ ICAgICBTaW1pbGFyIGlzc3VlcyBhbmQgb3B0aW1pemF0aW9ucw0KPiA+ICAgICBtYXkgYmUgaGVs cGZ1bCBpbiBvdGhlciBkZXBsb3ltZW50cyBzdWNoIGFzIGVuaGFuY2luZyB0aGUNCj4gcmVsaWFi aWxpdHkNCj4gPiAgICAgb2YgZGF0YSB0cmFuc2ZlciB3aGVuIGEgZmxlZXQgb2YgZHJvbmVzIGFy ZSB1c2VkIGZvciBzcGVjaWZpYw0KPiA+ICAgICBtaXNzaW9ucyAoZS5nLiwgc2l0ZSBpbnNwZWN0 aW9uLCBsaXZlIHN0cmVhbWluZywgYW5kIGVtZXJnZW5jeQ0KPiA+ICAgICBzZXJ2aWNlKS4gIENh cHR1cmVkIGRhdGEgc2hvdWxkIGJlIHJlbGlhYmx5IHRyYW5zbWl0dGVkIHZpYQ0KPiBwYXRocw0K PiA+ICAgICBpbnZvbHZpbmcgcmFkaW8gY29ubmVjdGlvbnMuDQo+ID4NCj4gPiBBY3R1YWxseSwg dGhpcyBpcyBhbiBvbGQgdGV4dC4gVGhlIG1haW4gcG9pbnQgd2Ugd2FudGVkIHRvIGNvbnZleQ0K PiBoZXJlIGlzIHRoYXQgd2hlbiBhIHN3YXJtIG9mIGRyb25lcyBpcyBjb2xsYWJvcmF0aW5nIGZv ciBleGFtcGxlIHRvDQo+IHByb3ZpZGUgY29ubmVjdGl2aXR5LCBtdWx0aXBsZSBkcm9uZXMgKHNl ZW4gYWQgYXMgZm9yd2FyZGVycykgd2lsbCBiZQ0KPiBzb2xpY2l0ZWQgdGlsbCBwYWNrZXRzIGFy ZSAoaG9wZWZ1bGx5KSBkZWxpdmVyZWQgdG8gYSBuZXR3b3JrIHdoZXJlDQo+IHRoZSBmbGVldCBv ZiBkcm9uZXMgaXMgZ3JhZnRlZCAoY2FuIGJlIGEgM0dQUCBjb3JlIG5ldHdvcmspLiBUaGUgaWRl YQ0KPiB3ZSBoYWQgaW4gbWluZCBpcyB0aGF0IExPT1BTIGNhbiBiZSBlbmFibGVkIGluIHN1Y2gg bXV0bGktaG9wIHdpcmVsZXNzDQo+IG5ldHdvcmsgKGNvbXBvc2VkIG9mIGRyb25lcykgZm9yIHRo ZSBzYWtlIG9mIHBlcmZvcm1hbmNlIG9wdGltaXphdGlvbi4NCj4gPg0KPiA+IENoZWVycywNCj4g PiBNZWQNCj4gDQo+IFNvIHRoaXMgdXNlIGNhc2UgcHJvYmFibHkgbmVlZHMgbW9yZSB0ZXh0LiBJ IHRoaW5rIHlvdSdyZSBzYXlpbmcNCj4gZHJvbmVzIGFyZSBhbiBleGFtcGxlIG9mIGEgbmV0d29y ayB3aXRoIGNvbnRpbnVvdXNseSBjaGFuZ2luZyBwYXRocy4NCg0KW01lZF0gWWVzLi4uYW5kIGEg cGFydGljdWxhcml0eSBvZiB0aGF0IGNhc2UgaXMgdGhhdCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhl IHN1Yi1wYXRocyBpcyBub3Qga25vd24gYmVmb3JlaGFuZCAoYmVjYXVzZSB0aGUgcGF0aHMgdGhl bXNlbHZlcyBhcmUgbm90IGtub3duIG5vciB0aGUgInBoeXNpY2FsIiBlbnZpcm9ubWVudCB3aGVy ZSB0aGVzZSBwYXRocyBhcmUgZXN0YWJsaXNoZWQuIA0KDQoNCj4gVG8gbWUsIG1pdGlnYXRpbmcg dGhlIGltcGFjdHMgb2YgaGFuZG92ZXIgbGlrZWx5IGRvZXMgZXhwb3NlIHNvbWUNCj4gaW50ZXJl c3RpbmcgY29uc3RyYWludHMgb24gdGhlIGRlc2lnbnMgZm9yIExPT1BTIGFzIHdlbGwgYXMgb24g dGhlDQo+IHBlcmZvcm1hbmNlLsKgDQoNCltNZWRdIEZ1bGx5IGFncmVlLiBBbGlnbmVkIHdpdGgg dGhlIHNjb3BlIHNldCBmb3IgdGhlIGluaXRpYWwgTE9PUFMgd29yaywgd2UgY2FuIHJlbW92ZSB0 aGF0IHBhcnQgb2YgdGhlIGRyYWZ0IGJ1dCBzZXQgaXQgYXMgYSBmdXR1cmUgcGVyc3BlY3RpdmUg aWYgTE9PUFMgcHJvdmVzIHRvIGJlIGJlbmVmaWNpYWwgZm9yICJzdGFibGUiIHRvcG9sb2dpZXMu ICAgDQoNCiBJIGhhdmVuJ3QgdGhvdWdoIGFib3V0IHdoYXQgdGhhdCBtZWFucyB3cnQgdG8gdXNp bmcgRUNODQo+IGFuZCBwYXRoIGluZm9ybWF0aW9uLg0KPiANCj4gR29ycnkNCj4gDQo+ID4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBMT09QUyBbbWFpbHRvOmxvb3Bz LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgR29ycnkNCj4gPj4gRmFpcmh1cnN0IEVu dm95w6nCoDogbHVuZGkgMjcganVpbGxldCAyMDIwIDE3OjIyIMOAwqA6IGxvb3BzDQo+ID4+IDxs b29wc0BpZXRmLm9yZz4gT2JqZXTCoDogW0xPT1BTXQ0KPiA+PiBkcmFmdC1saS10c3Z3Zy1sb29w cy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMgYW5kIHVzZS0gY2FzZXMuDQo+ID4+DQo+ID4+IFRoYW5r IHlvdSBmb3IgdGhlIHNjZW5hcmlvcyB1cGRhdGUgaW4NCj4gPj4gZHJhZnQtbGktdHN2d2ctbG9v cHMtcHJvYmxlbS1vcHBvcnR1bml0aWVzLCBJIHNlZSB5b3UgaGF2ZSB1cGRhdGVkDQo+ID4+IHRo ZSB0ZXh0IHJlbGF0aW5nIHRvIHNhdGVsbGl0ZSBuZXR3b3JrIHNlZ21lbnRzLiBJIG5vdyBoYXZl IHNvbWUNCj4gbW9yZQ0KPiA+PiBxdWVzdGlvbnMgb24gc2NlbmFyaW9zIGJhc2VkIG9uIHRoZSB3 aGF0IGlzIHNhaWQgaW4gdGhlIG1vc3QgcmVjZW50DQo+ID4+IElEOg0KPiA+Pg0KPiA+Pg0KPiA+ PiAoNCkgSSBzZWUgeW91IGFsc28gbWVudGlvbiBpbiB0aGUgbGF0ZXN0IHJldiBhZGRzIGEgdXNl IGNhc2UgZm9yIGENCj4gPj4gImZsZWV0IG9mIGRyb25lcyIgLSBJJ20gbm90IHF1aXRlIHN1cmUg d2hhdCB0aGlzIGlzIGRlc2NyaWJpbmcsDQo+IG1heWJlDQo+ID4+IHlvdSBjb3VsZCBleHBhbmQg aG93IHRoaXMgd29ya3MsIGFuZCBhZGQgc29tZSB0ZXh0IHRvIHRoZSBkcmFmdC4NCj4gPj4NCj4g Pj4gR29ycnkNCj4gPj4NCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IENlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucw0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jIHBhcyBldHJlDQo+IGRpZmZ1c2VzLA0KPiA+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4gPiBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aQ0KPiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMNCj4gZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+IGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+ID4NCj4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0KPiBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcg0KPiBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQNCj4gaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4g PiBUaGFuayB5b3UuDQo+ID4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Jul 30 06:50:57 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E233A115A for ; Thu, 30 Jul 2020 06:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=jCByQwP/; dkim=pass (2048-bit key) header.d=wizmail.org header.b=MD1YIo5t 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 ElvonPc2pULu for ; Thu, 30 Jul 2020 06:50:52 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 7C0823A114A for ; Thu, 30 Jul 2020 06:50:51 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :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:Autocrypt; bh=JcnY0y1mLJK/mSEsyqT2NZFLbswpwI07c1l4qRIIvVM=; b=jCByQwP/kQdbNUJiXu0Bdja2Gp lFJIcqij3OKNIQOtgX3V2cdws1a4+dLjbxVc3Nakj8R20trLFsg7enIZsVBA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject: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:Autocrypt; bh=JcnY0y1mLJK/mSEsyqT2NZFLbswpwI07c1l4qRIIvVM=; b=MD1YIo5tI5Nlg99EmHJ9DqNiU/ H+XkyiV0dtwokmqFUDLlvE8DXJMgcX6s9torG4HGpX9js47hmPTanGXequ+A3Co8PzcgBHIIZO+xW JRH/zRMOGW8DAC9NC22BnqDvH4QDsgVhH47GsSRzI9dP3K69HqNoaOyAocMEoXXltHLkV9GVdpA8g rDDP3OZdJ10gkwt0JkhPFBr2cp88PE0q3rHR0k1cCdIGTq5jHRsujo+G+rkW2X4xaj1ZjlQvKDEwt /2X+0BRSAb1JeAhwE9z+ebbpqWDvZzXlRoZ/s0mX6Tsx5bbG0pIcMMPIGhXYUP8GnXRQwYGBiAo0l nHg2Fd+w==; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.103) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1k18xN-00Gv2E-IB for loops@ietf.org (return-path ); Thu, 30 Jul 2020 13:50:49 +0000 To: loops@ietf.org References: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: Date: Thu, 30 Jul 2020 14:50:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 13:50:55 -0000 On 29/07/2020 22:52, Carsten Bormann wrote: >> (2) I will argue there is not a satellite-specific use case really, there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT. > > Yes! > (For a definition of “reliable”.) Seems you'd do well, for that scenario, to have a separate LOOPS-like reliability segment for the lower-RTT but lossy segment - to better respond given the segment RTT being lower than the full path RTT? But we're regressing to the 1950's era of separate link-reliability mechanisms, and a sequence of such links. Something the e2e principle discarded very successfully. Are we really better off, provably? -- Cheers, Jeremy From nobody Thu Jul 30 08:16:46 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07453A08FF for ; Thu, 30 Jul 2020 08:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 0qTqpACNtbP1 for ; Thu, 30 Jul 2020 08:16:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB923A091B for ; Thu, 30 Jul 2020 08:16:41 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BHYsg5xyfzyT6; Thu, 30 Jul 2020 17:16:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 30 Jul 2020 17:16:39 +0200 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 617814999.241396-87601213d0ba5be0e4db5dc2f890595f Content-Transfer-Encoding: quoted-printable Message-Id: <19B91FED-B5BC-41E0-8B7B-F3F164ACAF03@tzi.org> References: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> To: Jeremy Harris X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 15:16:45 -0000 Hi Jeremy, > On 2020-07-30, at 15:50, Jeremy Harris wrote: >=20 > On 29/07/2020 22:52, Carsten Bormann wrote: >>> (2) I will argue there is not a satellite-specific use case really, = there is a use case for any reliable long-haul path (large RTT) that is = concatenated with another segment with a lossy segment with lower RTT. >>=20 >> Yes! >> (For a definition of =E2=80=9Creliable=E2=80=9D.) >=20 > Seems you'd do well, for that scenario, to have a separate LOOPS-like > reliability segment for the lower-RTT but lossy segment - to better > respond given the segment RTT being lower than the full path RTT? Yes. > But we're regressing to the 1950's era of separate link-reliability > mechanisms, and a sequence of such links. Something the e2e principle > discarded very successfully. Are we really better off, provably? I do not think there is a conflict with the e2e argument here (*). LOOPS is not replacing TCP/QUIC/etc., it is assisting the e2e protocol. All links that do not have ridiculous signal/noise budgets have some = form of error recovery; that may just not very visible or well known = (e.g., Trellis Coding for Gigabit Ethernet). In theory, that would = always be working well and be enough so the rest can be done in the e2e = protocol. In practice, there is a difference between theory and = practice. Gr=C3=BC=C3=9Fe, Carsten (*) Please see Section 2.3 of = https://dl.acm.org/doi/10.1145/357401.357402 if you need an appeal to = the original reference. From nobody Thu Jul 30 08:33:08 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241E23A0A43 for ; Thu, 30 Jul 2020 08:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 ez94DwdWhJ9L for ; Thu, 30 Jul 2020 08:32:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA253A09A9 for ; Thu, 30 Jul 2020 08:32:53 -0700 (PDT) Received: from [172.16.42.101] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BHZDM5q3Gz1069; Thu, 30 Jul 2020 17:32:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 30 Jul 2020 17:32:51 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 617815971.182423-84413f625b668fd31ac4196527cb13cc Content-Transfer-Encoding: quoted-printable Message-Id: References: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 15:33:00 -0000 >>=20 >>> (3) The previous revision mentioned the specific case where the = =E2=80=9Cnetwork is long-haul=E2=80=9D, but I think this aspect was = removed in the latest rev?. Maybe I don=E2=80=99t fully see - is it = expected (or somehow known) that the delay for the LOOPS path segment is = much less than the end-to-end path (in Section 1)? >> That is the configuration where you get the most benefit. > And the converse appears also the case where LOOPS has the potential = for most negative interactions with end-to-end recovery? >>> How does the LOOPS path segment know this? >> It can=E2=80=99t. > That's an issue. >> The aggregate that LOOPS is repairing may be mixed out of quite = different end-to-end paths. > See (a). I=E2=80=99m lost. Where is (a)? >> LOOPS does not have a way to measure the RTT of those paths (*). A = recommendation for the proper use of LOOPS would be that it is not very = useful to run LOOPS on a segment that covers most of the span of the = end-to-end path, but LOOPS cannot know that this was done, and it is not = going to dramatically break traffic that has such a mix. If LOOPS does = little good, due to its cost (additional reverse packets, = processing/memory, tunneling if that wasn=E2=80=99t already in use) it = is a pessimization; many optimizations have regions of operation in = which they don't. > I would like to understand the potential for harm... to. Pessimization is =E2=80=9Charm=E2=80=9D. Not really a lot of harm. >>> (4) I see you also mention in the latest rev adds a use case for a = "fleet of drones" - I'm not quite sure what this is describing, maybe = you could expand how this works, and add some text to the draft. >> I think Med answered that =E2=80=94 I don=E2=80=99t think that is a = use case the operators interested in this have today :-) > That thread was interesting, but it seemed to create additional issues = - it might be worth deciding whether that is included in the next rev of = the document. >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) Well, vendors could add some secret sauce to actually do this, = for certain cases. But it is not the LOOPS protocol that will do that = for them, and LOOPS does not depend on it. >=20 > :-). >=20 > [GF] I'm now trying to understand how the "SDN" controller can know = which flows in the aggregates support ECN: At what point can an = aggregated tunnel egress assume that it is safe to translate a tunnel = loss into a flow ECN CE-mark? In the MVP, the tunnel ingress can only provide recovery to ECT-marked = packets. Any non-ECT traffic needs to be handled without LOOPS support (until we = go beyond the MVP, which in the current proposal requires rechartering). > Example: (Would only established ECN-capable flows added to the = aggregate? ... Translating loss at the start of a flow into a CE-mark = has a strange effect when the sender is probing for support, but a = recipient doesn't report CE-marks?) The tunnel that implements LOOPS segment might also move non-ECT = traffic, but LOOPS cannot help that in the MVP. The SDN controller = could be better off to configure the tunnel ends to direct ECT traffic = to the LOOPS segment, not so much non-ECT traffic (unless the tunneling = needs to happen anyway). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 31 00:33:12 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955003A0EBA for ; Fri, 31 Jul 2020 00:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 iFl5o6kCXhXy for ; Fri, 31 Jul 2020 00:33:08 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 519343A0EB9 for ; Fri, 31 Jul 2020 00:33:07 -0700 (PDT) Received: from [192.168.1.74] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 094A11B001C2; Fri, 31 Jul 2020 08:33:04 +0100 (BST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Gorry Fairhurst Mime-Version: 1.0 (1.0) Date: Fri, 31 Jul 2020 08:33:02 +0100 Message-Id: <64ED1BA0-F463-4C10-949C-38085ECAA0D3@erg.abdn.ac.uk> References: Cc: loops In-Reply-To: To: Carsten Bormann X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 07:33:11 -0000 See below. > On 30 Jul 2020, at 16:33, Carsten Bormann wrote: >=20 > =EF=BB=BF >>=20 >>>=20 >>>> (3) The previous revision mentioned the specific case where the =E2=80=9C= network is long-haul=E2=80=9D, but I think this aspect was removed in the la= test rev?. Maybe I don=E2=80=99t fully see - is it expected (or somehow know= n) that the delay for the LOOPS path segment is much less than the end-to-en= d path (in Section 1)? >>> That is the configuration where you get the most benefit. >> And the converse appears also the case where LOOPS has the potential for m= ost negative interactions with end-to-end recovery? >>>> How does the LOOPS path segment know this? >>> It can=E2=80=99t. >> That's an issue. >>> The aggregate that LOOPS is repairing may be mixed out of quite differen= t end-to-end paths. >> See (a). >=20 > I=E2=80=99m lost. Where is (a)? Ah sorry my mistake, I truncates my message to focus on talking about the sc= ope. >>> LOOPS does not have a way to measure the RTT of those paths (*). A reco= mmendation for the proper use of LOOPS would be that it is not very useful t= o run LOOPS on a segment that covers most of the span of the end-to-end path= , but LOOPS cannot know that this was done, and it is not going to dramatica= lly break traffic that has such a mix. If LOOPS does little good, due to it= s cost (additional reverse packets, processing/memory, tunneling if that was= n=E2=80=99t already in use) it is a pessimization; many optimizations have r= egions of operation in which they don't. >> I would like to understand the potential for harm... to. >=20 > Pessimization is =E2=80=9Charm=E2=80=9D. Not really a lot of harm. >=20 On the contrary. Pessimism is important in protecting infrastructure. Please= supply data and discuss operational practice. >>>> (4) I see you also mention in the latest rev adds a use case for a "fle= et of drones" - I'm not quite sure what this is describing, maybe you could e= xpand how this works, and add some text to the draft. >>> I think Med answered that =E2=80=94 I don=E2=80=99t think that is a use c= ase the operators interested in this have today :-) >> That thread was interesting, but it seemed to create additional issues - i= t might be worth deciding whether that is included in the next rev of the do= cument. >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> (*) Well, vendors could add some secret sauce to actually do this, for c= ertain cases. But it is not the LOOPS protocol that will do that for them, a= nd LOOPS does not depend on it. >>=20 >> :-). >>=20 >> [GF] I'm now trying to understand how the "SDN" controller can know which= flows in the aggregates support ECN: At what point can an aggregated tunne= l egress assume that it is safe to translate a tunnel loss into a flow ECN C= E-mark? >=20 > In the MVP, the tunnel ingress can only provide recovery to ECT-marked pac= kets. > Any non-ECT traffic needs to be handled without LOOPS support (until we go= beyond the MVP, which in the current proposal requires rechartering). >=20 >> Example: (Would only established ECN-capable flows added to the aggregate= ? ... Translating loss at the start of a flow into a CE-mark has a strange e= ffect when the sender is probing for support, but a recipient doesn't report= CE-marks?) >=20 > The tunnel that implements LOOPS segment might also move non-ECT traffic, b= ut LOOPS cannot help that in the MVP. The SDN controller could be better of= f to configure the tunnel ends to direct ECT traffic to the LOOPS segment, n= ot so much non-ECT traffic (unless the tunneling needs to happen anyway). >=20 > Gr=C3=BC=C3=9Fe, Carsten I=E2=80=99ve appreciated the discussion, and I wish this was more clear in t= he drafts.=20 To me, the scope and intention expressing in the problem statement is itsel= f problematic to understanding the proposed work, and the impact of this ser= vice. GOrry From nobody Fri Jul 31 01:14:09 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9193A1082 for ; Fri, 31 Jul 2020 01:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 OzBGhKk-Oivk for ; Fri, 31 Jul 2020 01:14:05 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05133A108D for ; Fri, 31 Jul 2020 01:14:04 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BJ0RZ1Q3KzyXh; Fri, 31 Jul 2020 10:14:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <64ED1BA0-F463-4C10-949C-38085ECAA0D3@erg.abdn.ac.uk> Date: Fri, 31 Jul 2020 10:14:01 +0200 Cc: loops X-Mao-Original-Outgoing-Id: 617876041.462587-1d7ced28f7c5b99da956e63e23bd6533 Content-Transfer-Encoding: quoted-printable Message-Id: <31BE3581-8456-447B-A98F-91A4EAC2350A@tzi.org> References: <64ED1BA0-F463-4C10-949C-38085ECAA0D3@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases. X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 08:14:08 -0000 Hi Gorry, >>>> If LOOPS does little good, due to its cost (additional reverse = packets, processing/memory, tunneling if that wasn=E2=80=99t already in = use) it is a pessimization; many optimizations have regions of operation = in which they don't. >>> I would like to understand the potential for harm... to. >>=20 >> Pessimization is =E2=80=9Charm=E2=80=9D. Not really a lot of harm. >>=20 > On the contrary. Pessimism is important in protecting infrastructure. = Please supply data and discuss operational practice. The tunneling overhead will be on the order of 40 to 60 bytes per = packet. I have made some proposals how to reduce the reverse overhead in early = May, we haven=E2=80=99t discussed this to the end, but we are talking = about single-digit percentage or less overheads here. So much for the = pessimization (inverse of optimization). Pessimism is also a necessary component of protocol development. By choosing reasonable upper bounds for LOOPS behavior (e.g., limiting = the retransmission time window to something not much more than a couple = RTTs, defining bounds for the FEC/retransmission overhead), we can limit = any harm from unforeseen interactions. > I=E2=80=99ve appreciated the discussion, and I wish this was more = clear in the drafts.=20 Certainly, more work is needed on the drafts, but that can be done in = the WG. > To me, the scope and intention expressing in the problem statement is = itself problematic to understanding the proposed work, and the impact of = this service. The document that we put most energy into is the charter, and that = should be what we discuss today. The I-Ds are background and = illustrations, and we certainly weren't perfect in thinning them in line = with the narrowing of the charter to the MVP. I still think the = background/illustration (proof of concept) provided by the I-Ds is = useful to evaluate the charter. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 31 03:21:43 2020 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427573A1223 for ; Fri, 31 Jul 2020 03:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HeipuUmPA2UP for ; Fri, 31 Jul 2020 03:21:36 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 8DC7E3A1224 for ; Fri, 31 Jul 2020 03:21:35 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id i19so16569303lfj.8 for ; Fri, 31 Jul 2020 03:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pZAyf6nd83ih44uNYAUr9RFuKGJD+2M+Ik/SUDGtkqU=; b=PpJ5pgmFA5ZVOTxHEdkPLQ7grNyip7EyL4YyCf72ijAJpnF1h89FY8LFMN5RmUPLqq k0z8YcctGcUpCalIOI2QFlQ9sSUeeytDyqq10Rlq0NnaituW/DaI+31Hx78yfFD2jeS+ u4LS0cUFAFdJiHMhb1iaNij35O4O0tJyynO+ONg+vmzdU+WXRgbNrmVNIE7sXVedt53y P2Cj1t2hHHeM9MBfucaJf5dDeyUFvsO6PqsQDKATUSep36o1o8dQR2Xri2AlWqLaL5YL 5z6dtR5kQYa1OcNqt7RUmNbos3pSpc5pVyKuO5LPVsPK0ahDu5ZlbQ1ttMBrJsmLQG6C gz9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pZAyf6nd83ih44uNYAUr9RFuKGJD+2M+Ik/SUDGtkqU=; b=UOHMi6gp6uHohedrJBBeJKxP/etzS3B+2jAHSfaRgtP6SAZnZVqANvnPMKUC2Tnuo9 F2UNUSGuYm8q5z4e/b4+aIA2PuPHRZ9HUx1CuT7cemkhPcSAdHdSy8ya7XPUzWtvJ+w2 PvL4uwm/3psV3XXtA5qlw0Y9HIppqcOAt1nonA7j4/5lhm/0Wkl2uyqXijfHFgUp8LLS Vl/oUkJ1jIeXbeQmYmjBuOjPypSFWq3BFg0xzl+VvHkcyqaWviKwLa/CmRmgXqLMkdEQ fTnHI4Gt6kkcH1vKI0lPmsd5n0ZHYkBRLCBQvqmr5l8F7e1PAbY1zttpsBRWS6te2mMg iN3w== X-Gm-Message-State: AOAM53269Lz6alKjedLUjcvK01OoeMd0K+kilzklFgBKyKq7CXE1c6sr fe7z6Fx8KueDF7GJudm0qd1w2lHcZ49hwn+8VNC2nqY/ X-Google-Smtp-Source: ABdhPJzDJDKV4KmcyldHmSUzB1/6g1wvEAjHFNpndwIUKydLABu6t4iqQjxh/mJQlQ1CrNCOHQSRLK+4faEQZheKfrA= X-Received: by 2002:ac2:5f48:: with SMTP id 8mr1637078lfz.157.1596190893256; Fri, 31 Jul 2020 03:21:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 31 Jul 2020 05:21:07 -0500 Message-ID: To: loops Content-Type: multipart/alternative; boundary="0000000000002fb4c305abba278d" Archived-At: Subject: Re: [LOOPS] LOOPS scheduled for Friday July 31, Session 1, materials uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 10:21:41 -0000 --0000000000002fb4c305abba278d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, On Sun, Jul 26, 2020 at 6:14 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear All, > > LOOPS will be having its WG-forming BOF this coming Friday during session > 1. I've uploaded a single slide deck that we'll be using during the > meeting. > > The most up-to-date set of pointers is at > https://datatracker.ietf.org/meeting/agenda/ (scan down to LOOPS). > I have uploaded a slightly revised slide deck from the proponents. Details from Carsten: New are slides 22 and 23, so we can spend less time on the rest=E2=80=A6 (And a slight change to what is now slide 32.) See you all in about 40 minutes. Best, Spencer > Best, > > Spencer, for the chairs > --0000000000002fb4c305abba278d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

On Sun, Jul 26, 2020 at 6:14 PM = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Dear All,= =C2=A0

LOOPS will be having its WG-forming BOF this comi= ng Friday during session 1. I've uploaded a single slide deck that we&#= 39;ll be using during the meeting.=C2=A0

The most = up-to-date set of pointers is at=C2=A0https://datatracker.ietf.org/meeting/= agenda/=C2=A0(scan down to LOOPS).

I have uploaded a slightly revised slide deck from the proponents. = Details from Carsten:

New ar= e slides 22 and 23, so we can spend less time on the rest=E2=80=A6
(And a slight change to what is now slid= e 32.)
=C2=A0
=
See you all in about 40=C2=A0minutes.=C2=A0

B= est,

Spencer


Best,=

Spencer, for the chairs
--0000000000002fb4c305abba278d--