IETF Logo Mail Archive

Re: [LOOPS] draft-welzl-loops-gen-info: general direction

"Zhouxingwang (Joe)" <zhouxingwang@huawei.com> Mon, 17 June 2019 03:55 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 A76DE1200DB for <loops@ietfa.amsl.com>; Sun, 16 Jun 2019 20:55:51 -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 mj030MyANm6T for <loops@ietfa.amsl.com>; Sun, 16 Jun 2019 20:55:49 -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 0BD6312003F for <loops@ietf.org>; Sun, 16 Jun 2019 20:55:49 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C1CAA5C31E2E70A535D7 for <loops@ietf.org>; Mon, 17 Jun 2019 04:55:46 +0100 (IST)
Received: from dggeme706-chm.china.huawei.com (10.1.199.102) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Jun 2019 04:55:46 +0100
Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme706-chm.china.huawei.com (10.1.199.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 17 Jun 2019 11:55:43 +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; Mon, 17 Jun 2019 11:55:44 +0800
From: "Zhouxingwang (Joe)" <zhouxingwang@huawei.com>
To: "loops@ietf.org" <loops@ietf.org>
Thread-Topic: [LOOPS] draft-welzl-loops-gen-info: general direction
Thread-Index: AdUku2sVQG/Wp3UJR5aCILBBxKZ0tw==
Date: Mon, 17 Jun 2019 03:55:44 +0000
Message-ID: <fb8a0c07445044b9a1a0f688ead477fa@huawei.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/kABK_LodyCPsjk6y6sxbAYu9CqM>
Subject: Re: [LOOPS] draft-welzl-loops-gen-info: general direction
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: Mon, 17 Jun 2019 03:55:52 -0000

Hi,

— two modes for recover: retransmission mode, FEC mode

For this item, the ACK/NACK packets in retransmission mode mainly has two functions, one is for loss detection and another is for local measurement(local RTT, loss rate, throughput...) which is important for LOOPS to interact with End-to-End congestion control.
So a TCP-like delayed ACK mechanism is suitable (NACK does not apply this, it will be sent out immediately once packet loss), but unlike TCP LOOPS does not require critical ACK clocking for its sliding window, so LOOPS could use a *longer* delayed ACK mechanism by mimicking TCP.
For the overhead of ACK (packets and processing), if there is bidirectional traffic between LOOPS ingress and egress, then packets overhead is limited; for processing overhead, it may need more CPU resource.

Thanks
Joe

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: Wednesday, June 12, 2019 5:18 PM
To: loops@ietf.org
Subject: [LOOPS] draft-welzl-loops-gen-info: general direction

Is the general direction taken by

https://tools.ietf.org/html/draft-welzl-loops-gen-info

the one that should be pursued in the LOOPS activity?

Specifically:
— protocol is run between an ingress and an egress, apart from some form of controller for setup purposes no other nodes are involved.
— two modes for recover: retransmission mode, FEC mode — protocol operates on sparse forward information (for retransmission mode, pretty much a sequence number and an ACK request) and reverse information that can be piggybacked on a reverse tunnel or sent in separate messages — no “connection setup” between ingress and egress nodes — the protocol defines a generic information model; specific encodings are defined for specific encapsulation protocols such as GUE or Geneve

(The draft actually offers two slightly different approaches, one in the main body, one somewhat more innovative approach in Appendix B.  If you think that Appendix B could be used in a kind of deployment that you are interested in, we would like to hear from you.)

Grüße, Carsten

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

v2.23.0 | Report a Bug | By Email