Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

Liyizhou <liyizhou@huawei.com> Tue, 17 December 2019 04:14 UTC

Return-Path: <liyizhou@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 DC3061200B7 for <loops@ietfa.amsl.com>; Mon, 16 Dec 2019 20:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cYQqK6bI5oDa for <loops@ietfa.amsl.com>; Mon, 16 Dec 2019 20:14:55 -0800 (PST)
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 7294D1200A1 for <loops@ietf.org>; Mon, 16 Dec 2019 20:14:55 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 24FC03343B92A758EA79 for <loops@ietf.org>; Tue, 17 Dec 2019 04:14:51 +0000 (GMT)
Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Dec 2019 04:14:50 +0000
Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by nkgeml703-chm.china.huawei.com (10.98.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Dec 2019 12:14:48 +0800
Received: from nkgeml702-chm.china.huawei.com ([10.98.57.155]) by nkgeml702-chm.china.huawei.com ([10.98.57.155]) with mapi id 15.01.1713.004; Tue, 17 Dec 2019 12:14:48 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Carsten Bormann <cabo@tzi.org>, "loops@ietf.org" <loops@ietf.org>
CC: "nwcrg@irtf.org" <nwcrg@irtf.org>
Thread-Topic: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
Thread-Index: AQHVnQUHo6Htz/9XhECRT2892AN0AaeQaxwAgAADpQCAALIzAIAARfEAgCnjlICAAnmgwA==
Date: Tue, 17 Dec 2019 04:14:47 +0000
Message-ID: <4a45b97df9e54e0abb4f5c9a0e7ce4ff@huawei.com>
References: <AAF1E19E-37C1-4A9D-B92A-621054B06AF6@tzi.org> <c172b80c-04ee-9786-153f-9e1dda57fdd8@steinwurf.com> <3D026CEF-AF7D-4CDE-8A5B-8CE5DCF749D1@tzi.org> <163A8040-9B13-43AA-8917-F75D984B0EBF@tzi.org> <26708398-5DEB-478E-8CB8-D406A8B874FF@tzi.org> <7DC0B005-8BA2-4D80-8CDF-4E2AE7EA96F3@tzi.org>
In-Reply-To: <7DC0B005-8BA2-4D80-8CDF-4E2AE7EA96F3@tzi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.186.90]
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/04oSbzgu57XWlDkozqkNn6L6ifg>
Subject: Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
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: Tue, 17 Dec 2019 04:14:58 -0000

Hi Carsten and all,

Thanks for putting all these together. 

I would like to have a follow-up discussion regarding single retransmission vs. multiple retransmission.

There is a potential choice to design a single retransmission mode *only* mechanism. The reason we might want to do it is the design is easier comparing with a generic retransmission mechanism allowing both single or multiple retransmission by parameter configuration.

For example,  LOOPS egress can mark a lost packet directly as "received" after it feedbacks a few ACKs to indicate a lost packet. Ingress removes the packet from its cache after a single retransmission. Once the retransmitted packet reaches the egress, egress simply forwards it. Such a mechanism only works for single retransmission.  
In this way, egress has a simple logic to decide when to stop sending the indication about a "lost" packet.  And the ingress does not need a logic to control whether and when 2nd and later retransmissions should be performed.

In multiple retransmission, it has to be more carefully designed to sync up when the egress gives up asking for retransmission and  when the ingress can remove the packet from its cache since no more retransmission is required.  As LOOPS does not provide 100% reliability, normally egress side should be the one determines when to give up asking for retransmission. Then egress needs to know the local forward RTT if multiple retransmission is expected.

So single retransmission *only* can be worth considering. It is a design choice more than an implementation choice to me. 
If there is a simple and efficient way to unify both, I would be more than happy to learn.  

Thanks,
Yizhou

-----Original Message-----
From: nwcrg [mailto:nwcrg-bounces@irtf.org] On Behalf Of Carsten Bormann
Sent: Monday, December 16, 2019 4:22 AM
To: loops@ietf.org
Cc: nwcrg@irtf.org
Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

Thanks again everyone for the participation at the LOOPS side meeting and in our slot at the NWCRG meeting.

I have compiled more detailed notes, with links to/copies of the meeting materials, at

https://github.com/loops-wg/ietf106

Please do have a look at the notes, specifically [1] and [2], and send corrections and additions.  Also, there were a few items in the NWCRG discussion where there may be results that we already can point to; as Marie-Jose said, please send them to both mailing lists.

Grüße, Carsten

[1]: https://github.com/loops-wg/ietf106/blob/master/ietf106-loops-side-meeting.md
[2]: https://github.com/loops-wg/ietf106/blob/master/ietf106-nwcrg-loops.md

_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg