[LOOPS] FW: New Version Notification for draft-li-tsvwg-loops-problem-opportunities-02.txt

"Zhouxingwang (Joe)" <zhouxingwang@huawei.com> Sat, 25 May 2019 03:24 UTC

Return-Path: <zhouxingwang@huawei.com>
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 3B60D120103 for <loops@ietfa.amsl.com>; Fri, 24 May 2019 20:24:27 -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, 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 hqNRujv7j153 for <loops@ietfa.amsl.com>; Fri, 24 May 2019 20:24:25 -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 F37A31200B9 for <loops@ietf.org>; Fri, 24 May 2019 20:24:24 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C5553EBCD78F78346F83 for <loops@ietf.org>; Sat, 25 May 2019 04:24:22 +0100 (IST)
Received: from dggeme705-chm.china.huawei.com (10.1.199.101) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 25 May 2019 04:24:21 +0100
Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme705-chm.china.huawei.com (10.1.199.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sat, 25 May 2019 11:24:19 +0800
Received: from dggeme758-chm.china.huawei.com ([10.6.80.69]) by dggeme758-chm.china.huawei.com ([10.6.80.69]) with mapi id 15.01.1591.008; Sat, 25 May 2019 11:24:20 +0800
From: "Zhouxingwang (Joe)" <zhouxingwang@huawei.com>
To: "loops@ietf.org" <loops@ietf.org>
Thread-Topic: New Version Notification for draft-li-tsvwg-loops-problem-opportunities-02.txt
Thread-Index: AQHVEqQ1/boDsRT19UGzi4wLVCBc0KZ7KgsA
Date: Sat, 25 May 2019 03:24:19 +0000
Message-ID: <d460fcb8fa034c079003f7686938bc16@huawei.com>
References: <155875245126.27330.17375151582007890344.idtracker@ietfa.amsl.com>
In-Reply-To: <155875245126.27330.17375151582007890344.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.27.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/ow_n31zew3N1ZwpCJBjKg5isDG4>
Subject: [LOOPS] FW: New Version Notification for draft-li-tsvwg-loops-problem-opportunities-02.txt
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 May 2019 03:24:27 -0000

Hi,

We uploaded a new version of LOOPS problems and opportunities draft. Please see the following info.

A new satellite communication case is added.
LOOPS is a potential way to solve the throughput degradation when unusual high loss rate in special conditions (e.g., fades due to heavy rain) happens and traditional TCP splitting is no  longer applicable for encrypted protocol like QUIC. 

Thanks,
Joe

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Saturday, May 25, 2019 10:48 AM
To: Zhouxingwang (Joe) <zhouxingwang@huawei.com>; Liyizhou <liyizhou@huawei.com>; Liyizhou <liyizhou@huawei.com>
Subject: New Version Notification for draft-li-tsvwg-loops-problem-opportunities-02.txt


A new version of I-D, draft-li-tsvwg-loops-problem-opportunities-02.txt
has been successfully submitted by Yizhou Li and posted to the IETF repository.

Name:		draft-li-tsvwg-loops-problem-opportunities
Revision:	02
Title:		LOOPS (Localized Optimizations of Path Segments) Problem Statement and Opportunities
Document date:	2019-05-24
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-li-tsvwg-loops-problem-opportunities-02.txt
Status:         https://datatracker.ietf.org/doc/draft-li-tsvwg-loops-problem-opportunities/
Htmlized:       https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-tsvwg-loops-problem-opportunities
Diff:           https://www.ietf.org/rfcdiff?url2=draft-li-tsvwg-loops-problem-opportunities-02

Abstract:
   In various network deployments, end to end paths are partitioned into
   multiple segments.  In some cloud based WAN connections, multiple
   overlay tunnels in series are used to achieve better path selection
   and lower latency.  In satellite communication, the end to end path
   is split into two terrestrial segments and a satellite segment.
   Packet losses can be caused both by random events or congestion in
   various deployments.

   Traditional end-to-end transport layers respond to packet loss slowly
   especially in long-haul networks: They either wait for some signal
   from the receiver to indicate a loss and then retransmit from the
   sender or rely on sender's timeout which is often quite long.  Non-
   congestion caused packet loss may make the TCP sender over-reduce the
   sending rate unnecessarily.  With end-to-end encryption moving under
   the transport (QUIC), traditional PEP (performance enhancing proxy)
   techniques such as TCP splitting are no longer applicable.

   LOOPS (Local Optimizations on Path Segments) aims to provide non end-
   to-end, locally based in-network recovery to achieve better data
   delivery by making packet loss recovery faster and by avoiding the
   senders over-reducing their sending rate.  In an overlay network
   scenario, LOOPS can be performed over the existing, or purposely
   created, overlay tunnel based path segments.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat