Re: [EToSat] about LOOPS(Localized Optimization of Path Segments) and etosat

"Border, John" <John.Border@hughes.com> Thu, 07 February 2019 17:50 UTC

Return-Path: <prvs=094138ae04=john.border@hughes.com>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798C1292F1 for <etosat@ietfa.amsl.com>; Thu, 7 Feb 2019 09:50:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hughes.com header.b=jeLHhWkW; dkim=pass (1024-bit key) header.d=hughes.com header.b=lz3G09mg
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 wcaKWy5hnLvn for <etosat@ietfa.amsl.com>; Thu, 7 Feb 2019 09:50:12 -0800 (PST)
Received: from mx0b-00115402.pphosted.com (mx0b-00115402.pphosted.com [148.163.153.174]) (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 BF5A5129284 for <etosat@ietf.org>; Thu, 7 Feb 2019 09:50:11 -0800 (PST)
Received: from pps.filterd (m0118427.ppops.net [127.0.0.1]) by mx0b-00115402.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x17Hg2dQ009595; Thu, 7 Feb 2019 17:50:10 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=3152018; bh=HcIGE4uc+NotlAwmmIeQDzg/RVjwp7LUXvkUOmPG6O0=; b=jeLHhWkWIXXnH5zxzqjVhEFrUnOqrvrY1zxLz7KdUb9SXc3MRgIJpSOo4gY3pnGFDb9I zSfR7LdjUzJcLk3KrbT82HazUyQViII6YUVuMvjam35AYK0QZkMR2G5aZ0dT8MRy+egB YHyJxPpnYPdt9x+L6bxya4VMi4JLYFmh5qIkFkvcAW2YPCYyjAbYVHquI4fNJ7yuejVw Acrztvs6Xr5y5WBQqYMbTU9zLIzHnprGQ/LA0YKUDixBfMT4P0k92HZiukHo2QfDY8SA 6nmHeMO6I4AucWLzKHC9WKsKI19ZvSTiDfjp5aoG8TAJ4E0+WX+ghuARUED8ZwcHQw0d YQ==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) by mx0b-00115402.pphosted.com with ESMTP id 2qfp4kpanm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Feb 2019 17:50:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HcIGE4uc+NotlAwmmIeQDzg/RVjwp7LUXvkUOmPG6O0=; b=lz3G09mgXnOHiw712G3hA3pJdmAsgkM/84TB/Oh3u27Vti+RKq/MUY3v/oM/w8ONHkYmFGSACvGi0sH/MBXO8nX64jVQnp+hMLmdk/kWVcNCEXX9hji/fLF/2773JP8/dHezftA4/k/sHzEyDNN7CTjD+fN6HQXuuXvNVJgNs5c=
Received: from BL0PR11MB3394.namprd11.prod.outlook.com (10.167.240.87) by BL0PR11MB3044.namprd11.prod.outlook.com (20.177.204.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.17; Thu, 7 Feb 2019 17:50:08 +0000
Received: from BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::35fb:c251:97d8:f696]) by BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::35fb:c251:97d8:f696%4]) with mapi id 15.20.1601.016; Thu, 7 Feb 2019 17:50:08 +0000
From: "Border, John" <John.Border@hughes.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Marie-Jose Montpetit <marie@mjmontpetit.com>, "etosat@ietf.org" <etosat@ietf.org>
Thread-Topic: about LOOPS(Localized Optimization of Path Segments) and etosat
Thread-Index: AdSMdXYY0q4TKfupS9+Eq29qzaUgLgAMjSKQAAWPDGAAU/xn0AAco4+ABUIm+IAGtvzPgAApj53g
Date: Thu, 07 Feb 2019 17:50:08 +0000
Message-ID: <BL0PR11MB3394EABD752B8F15EF20D31A90680@BL0PR11MB3394.namprd11.prod.outlook.com>
References: <D408889639FC5E4FADB4E00A3E01FA8FA6D64374@nkgeml513-mbs.china.huawei.com> <BL0PR11MB33944EB404AA6A1E8DABBBD490A80@BL0PR11MB3394.namprd11.prod.outlook.com> <BL0PR11MB33940058189CAC345C51C2C090A80@BL0PR11MB3394.namprd11.prod.outlook.com> <D408889639FC5E4FADB4E00A3E01FA8FA6D64D4D@nkgeml513-mbs.china.huawei.com> <205ADE17-7C94-4AF5-B2F3-87613C6E41DE@tzi.org> <BL0PR11MB3394C0EE1249C918BC33448C908D0@BL0PR11MB3394.namprd11.prod.outlook.com> <1ABAA149-B3D7-4944-ACFB-CF8E3AA977E6@tzi.org>
In-Reply-To: <1ABAA149-B3D7-4944-ACFB-CF8E3AA977E6@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.85.223.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR11MB3044; 6:chJno9aMcM7n9fS2OXUCaiG0U3fIg93Mce4rw/I1/D1DKoZ1/AIkS1H3gU3TdfmzWKsIK40kR+MoCZxiYaMWIuZAf21gp8mwfeMjN5DzCVr2mCjHibAmbs0q2ouPGHCl4Zr7A677Lze2B9hGmEvjVTh3cZb/aRuZFTehQwejTJz9clZq4JPxTXS73y8O7ZQ0AmzqUmNLQeXEfWxTXHS/cCjBnNc9+zQ/hvj4EiQLgUwrzX/R6YQlU8UIXy2BE6NF72TvVXALYIY8/RREaesjcJ1/cFH6LD04zGvkXN3Ki2NMJscaOn1peKmeCDbxiJrQIlzZetMO+G9ryy1mvMHCX5Kdiv9Fz+8IQczuwsvwUXt4pxt+kiVoc605ETM7W+hm0apv+GyWIO8hGeHoD/ZYs8giNGR+yiujKAJNVx0lwFs+QPdMWPPbEyzEUkF+lzd5QoTElTudJI8daslOliWjiA==; 5:P7nswK7rfKgbf00hW/q2jMW+k2TFrBqPiyidxOSKl7PrlcAgHuqbXq9vkIH0HxgOFhrratuFN46hwsRxn2b0+TCNzBlMqR3YqEE/eWGbJ380iITxqVuJONwz0rygDyvVuFGztmuuoZTCtAysDhwS1DlnOlH10NPFKmela2P4SXtiShWEs/mEw5QeTKE449LvzUbEe02hvxJpvhnaxkLZ3w==; 7:NfsCNBG5lJ7cLzmCsg882dVoSbJt6byc733aYNvMtV1ecaZnfUvNLWbp1TM+s0S2Gima5UTLN0GIsJqTVIMasRbom6qSLaNCZPNLxu1RRErn0er+sQC3TfNmjruakPZPEdqnA/WvEG6ZElTOTIs6Vg==
x-ms-office365-filtering-correlation-id: afcae400-f738-48f6-ef6c-08d68d24b347
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BL0PR11MB3044;
x-ms-traffictypediagnostic: BL0PR11MB3044:
x-microsoft-antispam-prvs: <BL0PR11MB30444F274465576EFE75BE2E90680@BL0PR11MB3044.namprd11.prod.outlook.com>
x-forefront-prvs: 0941B96580
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(366004)(376002)(346002)(13464003)(199004)(189003)(486006)(478600001)(236005)(66066001)(11346002)(66574012)(9686003)(6306002)(97736004)(476003)(106356001)(446003)(54896002)(7696005)(7736002)(33656002)(229853002)(6116002)(790700001)(74316002)(256004)(3846002)(6436002)(99286004)(68736007)(72206003)(14444005)(53936002)(76176011)(25786009)(55016002)(6246003)(8676002)(14454004)(81166006)(93886005)(4326008)(86362001)(81156014)(2906002)(71200400001)(105586002)(26005)(6916009)(71190400001)(8936002)(186003)(316002)(53546011)(6506007)(54906003)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR11MB3044; H:BL0PR11MB3394.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: hughes.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LOnHbwzzXl90Vw+T1moHUYkrwKOkkz6zP4auLQYCYb7031vIx2fxmeBkrS0WGFhUKBaqNOuDkGuC5TXZAhow7lnLxfmjZsm1dLV21sgwe580zhZbdzuO9IVOLbc79/rMV/UazOjVaJ3oXUhZxKsjPbDJTF9wJm+GyPQyPxDEgrjhXj+AXszkov6dLX7BSkovenbcsp5CcmOox9aiP+bgIXUy4sKgXS7Fhre4uNSjCtIxZJ0GnINEwRSlfmTo3JiUAfySouPGOgd2CJzOcNcVUgqRJA6NDcnqsXRsX4k/DG9ACAdyvfQGx5yQ2Lb0d6nhf2BvbDW+JvgkKL3eV4annrw7uCYUsHfJtYS6qGFMSIetQQmhTAOn9d8QTJ5nTY25HaNRBe2KktIICkQKlyYWDhcb2mDFGdF11fXd2El/2Nw=
Content-Type: multipart/alternative; boundary="_000_BL0PR11MB3394EABD752B8F15EF20D31A90680BL0PR11MB3394namp_"
MIME-Version: 1.0
X-OriginatorOrg: hughes.com
X-MS-Exchange-CrossTenant-Network-Message-Id: afcae400-f738-48f6-ef6c-08d68d24b347
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 17:50:08.4117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e1f3187-4610-4ce2-bad1-b92f4ba36ab3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3044
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-07_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902070134
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/Dl366bil1vL2jJIsJh4smv1xehE>
Subject: Re: [EToSat] about LOOPS(Localized Optimization of Path Segments) and etosat
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 17:50:15 -0000


You wrote:


"Traditionally, satellite PEPs have treated the whole satellite section (uplink, downlink) as a single sub-path (hop) for optimization.  LOOPS would benefit from an active LOOPS node on the satellite.  Is that something that is on the table these days?"

Do you mean on the satellite itself?   There have been a few satellites built with processing capability on board (mostly for government/military use) but that is not currently happening for the high speed satellites being used for Internet over satellite.

Some of the elements of LOOPS already exist for satellite links but they need to be beefed up now because transport layer solutions are disappearing.  One area that concerns me a lot is loss recovery.  While the error rate on the satellite paths is generally very low most of the time, but gets higher during link condition fades (e.g. heavy rain).  Satellite technology has come a long way in using adaptive techniques to compensate for fade but there is always some residual error rate.  And, from the outside, the mitigation techniques will look like a reduction in link capacity which ties in to the other LOOPS aspects of dealing with congestion management.


John





-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
Sent: Wednesday, February 06, 2019 4:43 PM
To: etosat@ietf.org
Cc: Marie-Jose Montpetit <marie@mjmontpetit.com>; Border, John <John.Border@hughes.com>
Subject: Re: about LOOPS(Localized Optimization of Path Segments) and etosat



On Jan 3, 2019, at 18:48, Border, John <John.Border@hughes.com<mailto:John.Border@hughes.com>> wrote:

>

> Clearly LOOPS should not focus only on satellite.  But, I think LOOPS is directly relevant to ETOSAT.  Techniques like LOOPS are likely to be a key part of the solution to the performance over satellite problem.

>

> I will be sending out an email to ETOSAT in the next couple of days to try to kickstart discussion overall.



Here is my attempt at kickstarting:



Traditional approaches at enhancing end-to-end performance by deploying nodes on the way (performance enhancing proxies, PEPs) have employed heavy interactions with the end-to-end transport protocols, usually without their explicit consent.  With end-to-end encryption going under the transport (QUIC), this approach is no longer useful.  This is the underlying theme of the ETOSAT mailing list, but also an important motivator for the more general LOOPS approach.  (Please use the slides previously sent as a reference to node terminology.)



So what kind of performance enhancement can we do even without aggressively reaching into transport layers?



* Active queue management: AQM is certainly a good idea.  A potential benefit of LOOPS for AQM is that it can run measurements between sub-path ingress and sub-path egress nodes, as well as between overlay ingress and overlay egress.  So more data can be made available inside the system of LOOPS nodes, and this may help in active queue management.



* Loss recovery.  Packets can be recovered between sub-path ingress and sub-path egress nodes.  This can be based on local retransmissions and/or on adding and using FEC.  By cooperation of the sub-path ingress and egress nodes, the parameters for these (RTO, FEC rate, choice between retransmission and FEC) can be chosen wisely.  Overlay ingress and egress nodes can provide additional information, such as end-to-end RTT estimates, which might also help in choosing these parameters and avoiding continuing with sub-path retransmission when an end-to-end retransmission is likely to kick in.  The total load on the network decreases with replacing end-to-end by subpath retransmissions/FEC.  Tail-loss detection can benefit from mixing multiple end-to-end flows into one error-controlled subpath flow.



* Multipathing.  Again, both the overlay ingress/egress nodes and the sub-path ingress/egress nodes can help with detecting multiple paths and using them in the best possible way.



Challenges, and potential mitigations by employing advances in end-to-end transports, include:



* Reflecting congestion information up from the sub-paths to the end-to-end paths.  Sub-path ingress/egress nodes may employ additional congestion indicators such as sojourn time to sort loss events into congestion or non-congestion losses.



* Reordering may reduce end-to-end transport performance.  RACK may help us here, as may cwnd undo on spurious retransmission detection in current TCPs.  Or we could use resequencing in egress nodes, but this is generally not a favored approach.



* MTU.



Traditionally, satellite PEPs have treated the whole satellite section (uplink, downlink) as a single sub-path (hop) for optimization.  LOOPS would benefit from an active LOOPS node on the satellite.  Is that something that is on the table these days?



What we could design here includes:



* Sub-path “transport-layer style“ protocols, for retransmission and FEC.  This includes designing/selecting good FEC schemes for sub-path usage, as well as some basic encapsulation formats.

* Formats for making measurement information available between the nodes.

* Formats for making control information available between ingress and egress nodes.



Grüße, Carsten