IETF Logo Mail Archive

Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

Liyizhou <liyizhou@huawei.com> Thu, 25 July 2019 19:31 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 740CA1201C6 for <loops@ietfa.amsl.com>; Thu, 25 Jul 2019 12:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rhw1_WwxYotO for <loops@ietfa.amsl.com>; Thu, 25 Jul 2019 12:31:36 -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 C7BFA1201C5 for <loops@ietf.org>; Thu, 25 Jul 2019 12:31:35 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3ABFA56DB3CD8B554E07; Thu, 25 Jul 2019 20:31:33 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 25 Jul 2019 20:31:32 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.207]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 03:31:28 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Carsten Bormann <cabo@tzi.org>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, Suresh Krishnan <suresh@kaloom.com>, loops <loops@ietf.org>
Thread-Topic: [LOOPS] BOF co-chairs thinking on LOOPS next steps
Thread-Index: AQHVQjQKypVGc4E2bk+lpeh9RRMAhKbZxi+AgAAKdACAAG+BgIAA620AgAADLwCAAADRgIAAiyEE
Date: Thu, 25 Jul 2019 19:31:27 +0000
Message-ID: <D408889639FC5E4FADB4E00A3E01FA8FC5F44C34@nkgeml513-mbs.china.huawei.com>
References: <CAKKJt-eRGJe+9PtEC7xgFz+HA0zsr_sR0NUgKRmJ-P5Q3XBg-A@mail.gmail.com> <CAPjWiCSbPioTHkYBpX73qxzO=H1sJDZpCMCKzBKoU4rZLLhwMQ@mail.gmail.com> <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org> <CAKKJt-c24RdPyZRoK-B6fXuN0xABUsU=p7Y6UFwAcENfjE3oOQ@mail.gmail.com> <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org>, <CAPjWiCTSyi8Gm6AaAV_YWMjO0JnTxB28V0=a28vTiWA-gzoirw@mail.gmail.com>
In-Reply-To: <CAPjWiCTSyi8Gm6AaAV_YWMjO0JnTxB28V0=a28vTiWA-gzoirw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D408889639FC5E4FADB4E00A3E01FA8FC5F44C34nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/SLyzBEGF-98KNlbIH4A5osxsUUY>
Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
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: Thu, 25 Jul 2019 19:31:39 -0000

As applications have not been killed by end to end retransmission, I believe they are ok with shorter retransmissions.
Certainly we need to design it in a right way. And it is part of the work LOOPS is trying to do.


Rgds,
Yizhou

发件人： Marie-Jose Montpetit<marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>
收件人： Spencer Dawkins at IETF<spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>;Carsten Bormann<cabo@tzi.org<mailto:cabo@tzi.org>>
抄送： Magnus Westerlund<magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>>;Mirja Kuehlewind<ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>;Suresh Krishnan<suresh@kaloom.com<mailto:suresh@kaloom.com>>;loops<loops@ietf.org<mailto:loops@ietf.org>>
主题： Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
时间： 2019-07-25 15:13:53

Which begs the question if the retransmission delay will kill the application.

mjm

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com<mailto:mariejose@mjmontpetit.com>
mariejo@mit.edu<mailto:mariejo@mit.edu>


On July 25, 2019 at 3:10:39 PM, Carsten Bormann (cabo@tzi.org<mailto:cabo@tzi.org>) wrote:

On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> wrote:
>
> […] If the LOOPS community can’t live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-)

Right. One other place where we can structure the milestones further is by starting with retransmission mode only and add FEC mode in a second step.

So this would give us a nice and small first deliverable (retransmission mode for node-to-node) that we can then recharter from. If we do this right, this doesn’t even need to increase the time up to when we deliver the whole protocol including both host-to-node and FEC.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email