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

"Zhouxingwang (Joe)" <zhouxingwang@huawei.com> Thu, 19 December 2019 11:35 UTC

Return-Path: <zhouxingwang@huawei.com>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B031200B4 for <nwcrg@ietfa.amsl.com>; Thu, 19 Dec 2019 03:35:22 -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=unavailable 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 BgkJncCaB_bI for <nwcrg@ietfa.amsl.com>; Thu, 19 Dec 2019 03:35:20 -0800 (PST)
Received: from huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 07A401200B5 for <nwcrg@irtf.org>; Thu, 19 Dec 2019 03:35:20 -0800 (PST)
Received: from nkgeml411-hub.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 4CB3AB45476BDBD82538; Thu, 19 Dec 2019 19:35:13 +0800 (CST)
Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 19 Dec 2019 19:35:12 +0800
Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by nkgeml702-chm.china.huawei.com (10.98.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5; Thu, 19 Dec 2019 19:35:12 +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.1713.004; Thu, 19 Dec 2019 19:35:12 +0800
From: "Zhouxingwang (Joe)" <zhouxingwang@huawei.com>
To: Colin Perkins <csp@csperkins.org>, Liyizhou <liyizhou@huawei.com>
CC: Carsten Bormann <cabo@tzi.org>, "loops@ietf.org" <loops@ietf.org>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Thread-Topic: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
Thread-Index: AQHVtJCXFSjuUH7vWkSxcvxymuEBKae9rDOAgAOrADA=
Date: Thu, 19 Dec 2019 11:35:11 +0000
Message-ID: <98c3009ab0054054af3f71aba4d52d58@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> <4a45b97df9e54e0abb4f5c9a0e7ce4ff@huawei.com> <8451B22E-8D91-406E-852B-F21B79DEBEB6@csperkins.org>
In-Reply-To: <8451B22E-8D91-406E-852B-F21B79DEBEB6@csperkins.org>
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/nwcrg/FW9-HFednTd6urAZmHpfxoPR7sE>
Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 11:35:22 -0000

Hi,

Statically configuring a timeout (the period that the ingress will keep the packets in its buffer) is a little bit dangerous, because the local RTT may vary and is not known in advance. If the timeout value is shorter than the real local RTT, it will be bad for LOOPS. So setting an N (how many times a lost packet to be retransmitted, once per RTT) in the system is more preferred. 
To simplify the logic, I don’t think setting N at both ingress and egress side is a good idea, because it will make things complicated and N may be set inconsistently by mistake, so setting N and triggering/terminating the retransmission only at one side is better. 

Some thinking of this:
1) Set N and make decision at ingress only
    Pros: ingress knows RTT, it will perform N times retransmission and once per RTT well, and expires the packets after N*RTT from the buffer
    Cons: egress needs to know N and RTT, and still have a logic to stop asking for the lost packets 

2) Set N and make decision at egress only
    Pros: nearly no logic at ingress, egress keeps asking for lost packets by NACK, and after N*RTT (communicated by ingress) it will pretend it has got them and send ACK to ingress to let it clear the packets from retransmission buffer. Ingress just needs a big enough buffer to hold the packets waiting to be retransmitted, and once the buffer is full the new packet just replace the earliest one
    Cons: forward RTT needs to be communicated from ingress to egress

Thanks
Joe

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Colin Perkins
Sent: Tuesday, December 17, 2019 7:33 PM
To: Liyizhou <liyizhou@huawei.com>
Cc: Carsten Bormann <cabo@tzi.org>rg>; loops@ietf.org; nwcrg@irtf.org
Subject: Re: [LOOPS] [nwcrg] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

Hi,

Is not the ingress logic the same for single or multiple retransmissions? The ingress node will maintain a queue of packets that have been sent and can be retransmitted. Packets expire from the queue if an ACK for their sequence number is received, or after a certain amount of time. Packets are retransmitted if a retransmission request arrives before they expire. You need the timeout to expire packets in case ACKs are lost, so whether the ingress supports single or multiple retransmissions is just a case of configuring the timeout.

If you somehow communicate that timeout to the egress node, then it can make a local decision on whether to make one or more retransmission requests for a lost packet. This would give the egress flexibility to pick an appropriate retransmission request strategy without needing to standardise what that strategy is. LOOPS would define the mechanism and give guidance on choice of the ingress expiration timeout. 

Colin



> On 17 Dec 2019, at 04:14, Liyizhou <liyizhou@huawei.com> wrote:
> 
> 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
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops



-- 
Colin Perkins
https://csperkins.org/




-- 
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops