Re: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May 2020, replacing IETF 107 side meetings)
Liyizhou <liyizhou@huawei.com> Wed, 06 May 2020 09:15 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 1AFCC3A053E for <loops@ietfa.amsl.com>; Wed, 6 May 2020 02:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 iF92folF98mq for <loops@ietfa.amsl.com>; Wed, 6 May 2020 02:15:29 -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 DD3D23A0538 for <loops@ietf.org>; Wed, 6 May 2020 02:15:28 -0700 (PDT)
Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8E95AAC094E633F99F4A for <loops@ietf.org>; Wed, 6 May 2020 10:15:27 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 6 May 2020 10:15:26 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 6 May 2020 17:15:24 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 6 May 2020 17:15:24 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Carsten Bormann <cabo@tzi.org>, "loops@ietf.org" <loops@ietf.org>
Thread-Topic: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May 2020, replacing IETF 107 side meetings)
Thread-Index: AQHWIymZ398IgfEpv0yNKnH5CNg2laiaYH1A
Date: Wed, 06 May 2020 09:15:24 +0000
Message-ID: <f51656fe9cd24a43acd0699b984df460@huawei.com>
References: <04EBF640-8E6C-41EB-A704-ECCE6FC0BA48@tzi.org> <5A6CF9A4-FCBB-435B-8EEF-9704F5BFD221@tzi.org>
In-Reply-To: <5A6CF9A4-FCBB-435B-8EEF-9704F5BFD221@tzi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.12.121]
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/YNpq_qw0fwedfl5_ysDfRuJ-D_s>
Subject: Re: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May 2020, replacing IETF 107 side meetings)
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: Wed, 06 May 2020 09:15:32 -0000
Hi Carsten, That is a pretty complete list. Thanks for putting them together. Please see inlines with [yz]. Yizhou -----Original Message----- From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Wednesday, May 6, 2020 6:07 AM To: loops@ietf.org Subject: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May 2020, replacing IETF 107 side meetings) On 2020-04-30, at 21:37, Carsten Bormann <cabo@tzi.org> wrote: > > (2) to look at about a dozen other WGs and RGs and agree what our technical relationship with them is going to be, e.g. "watch" (shared interests, but no specific exchange or mutual dependency envisioned now; could develop, though), "import" (specs that the other WG works on will be used by ours), and "export" (we could do some work that would benefit that other WG). This will then be useful as input for a charter discussion. I prepared a more detailed overview over related WGs and RGs at: https://github.com/loops-wg/charter/blob/master/wg-rg-relations.md This would be one of the agenda items of the LOOPS “design team meeting” in 41 hours, with a view of feeding back some (but not all) of the details into the charter. Please send comments to me or to the list (or make a pull request if that is your thing). I’m also copying the current text below in case commenting from the mail reader is easier for you. Grüße, Carsten ## Relationship to Other WGs and RGs This is an expanded version of the section of a similar name in the proposed charter. We'll develop this here and then make the needed changes to the charter. The objective here is to look at about a dozen other WGs and IRTF RGs and agree what our technical relationship with them is going to be. Note that the current version of this note does not address interaction with other SDOs yet. * To do: find out whether there we envision such interaction with other SDOs. ## Types of relationship * "watch": shared interests, but no specific exchange or mutual dependency envisioned now; could develop, though. * "import": specs that the other WG works on will be used by ours. * "export": we could do some work that would benefit that other WG. ## Working groups, Research Groups * Name: TCPM, TSVWG, QUIC * Work: Transport protocol innovations * Issue in other group: What new transport protocol mechanisms provide benefits that cannot be had with a classical transport * **Issue in LOOPS**: Develop the retransmission part of LOOPS (as well as possibly the reconstruction/FEC part) based on these innovations * Type: Watch, potentially Import * **Issue in LOOPS**: Are there new interactions between the LOOPS "transport" elements and the innovations in the upper layer transport protocols? * Type: Watch --- * Name: TCPM * Work: RACK * Issue in other group: (from draft-ietf-tcpm-rack-08:) ... develop a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to be an alternative to the DUPACK threshold approach [RFC6675] ... * **Issue in LOOPS**: Does LOOPS need to rely on a sequence-preserving path for efficient loss detection, or can we use some of the RACK work for more time-based loss detection? How do we translate the TCP features used by RACK into features that are available in LOOPS? * Type: Watch, potentially Import [yz] Sequence number based loss detection is easier for LOOPS segment. LOOPS ingress does not rely on ACK clocking, so egress may generate less ACKs if everything is ok. Time-based loss detection would require more precise RTT monitoring which need quite frequent ACKs. So time-based loss detection may put a requirement on frequency/number of ACK generations. When a LOOPS segment has a severe packet re-ordering which confuses with packet loss, time-based loss detection is good to be employed. There is another issue to be considered in LOOPS related to RACK. When interacting with RACK based end host sender, LOOPS egress has loose requirement to maintain the packet order when waiting for the lost packet to be recovered over the LOOPS segment. [/yz] --- * Name: MASQUE (WG to be, recent BOF 2020-03-24) * Work: Embedding proxied flows into QUIC and HTTP/3 * Issue in other group: "Congestion Control over Congestion Control in case of UDP or IP proxying", i.e., when the proxied flows are UDP or IP (~ VPN), the interaction between end-to-end transport protocol control loops (congestion control) and the control loops run by QUIC * **Issue in LOOPS**: Does LOOPS need to perform specific work to mitigate issues stemming from nested congestion control? Note that the LOOPS segment is typically, but not always, significantly shorter than the end-to-end path, which might be similar in a MASQUE situation. * Type: Watch [yz] Currently LOOPS ingress from my understanding does not intend to do sending rate adjustment. The control is at the end host sender. LOOPS tries to do the minimum set of work in participating in the congestion control, i.e. via CE-marking. If a full-function nested control loop (including sending rate adjustment at LOOPS ingress) in LOOPS is required, some active interaction between the end host and the LOOPS ingress node would be required. I do not think this is for the initial stage of LOOPS. We'd better start from the simple approach. I did not follow MASQUE very closely, but it seems working between the sender and the proxy. Potentially would give us some hints on advanced features to be considered at LOOPS later stage. [/yz] --- * Name: RMCAT * Work: Congestion control for media flows * **Issue in LOOPS**: Interactions between upper layer congestion control schemes in use for media and those in use on the LOOPS path segment * Type: Watch --- * Name: IPPM, TSVWG * Work: Formats and algorithms for measurement * **Issue in LOOPS**: What IPPM-defined formats and algorithms for measurement can we usefully import into the LOOPS measurement system * Type: potentially Import * To do: What came out of the draft-ietf-tsvwg-tunnel-congestion-feedback work? [yz] IPPM-defined ioam format intends to help network oam. It puts a lot of effort in its trace option (pre-allocated trace and incremental trace). It is quite obvious that trace option is not appropriate for LOOPS since LOOPS would work on tunnel endpoints. No intermediate node’s information is required. If ioam edge-to-edge mode is to be used, then ioam edges have to happen to be LOOPS segment ingress and egress. So I would not think ioam can be directly used for LOOPS segment. The most important information for LOOPS is timestamps in my understanding. We may re-use its format but put it in LOOPS header. That makes the design clearer. [/yz] --- * Name: NVO3, INTAREA, SPRING/6MAN * Work: Tunnel encapsulation formats * **Issue in LOOPS**: We need to follow the homes of tunneling protocols to which bindings are being defined, which depending on the choices of the WG may include NVO3 (Geneve), intarea (GUE), spring/6man (SRv6). * Type: Import * To do: There is no obvious home for GRE at this point, but GRE is another obvious choice for a tunneling protocol. [yz] Agreed that GRE is a choice here. [/yz] --- * Name: TSVWG * Work: Advanced ECN * Issue in other group: Agree on an approach for advanced ECN * **Issue in LOOPS**: LOOPS can benefit from ECN both in the end-to-end traffic and in the LOOPS segment. The protocol may need to anticipate the developments on advanced ECN and adjust its usage of both classic and advanced ECN. This may also influence how LOOPS makes use of RFC 6040 (Tunnelling of Explicit Congestion Notification). * Type: Watch --- * Name: DETNET, RAW * Work: DETNET data plane, RAW, PREOF * Issue in other group: Define a data plane (encapsulation) for replicating, eliminating duplicates, and potentially reordering traffic (PREOF). RAW extends this work to wireless networks. * **Issue in LOOPS**: Can we integrate some of this work for retransmission and reconstruction? * Type: Watch, potentially import * **Issue in LOOPS**: Potentially (long term): Can we make some of the LOOPS components available in a way that is useful for DETNET and RAW? * Type: Export [yz] DETNET looks having an assumption that an end-to-end retransmission in case of a packet loss would make the packet miss its cycle and become useless in industrial networking. A (shorter) segment based retransmission or FEC might be able to make the recovered packet keep up with the cycle? That's an interesting thought :) [/yz-end] --- * Name: NWCRG (IRTF) * Work: FEC formats and protocols * Issue in other group: Define forward error correction (FEC) formats that provide good robustness, low reconstruction latency, low implementation complexity, low CPU requirements, low overhead * **Issue in LOOPS**: How does the structure of these new formats and protocols influence the way LOOPS handles reconstruction? * To do: Watch the patent claim thickets in this space * Type: Watch, Import/Reference (specific schemes) --- * Name: MAPRG (IRTF), ICCRG (IRTF) * Work: Measurement, Congestion control * Issue in other group: Do leading edge work in this space * **Issue in LOOPS**: Benefit from that leading edge work * Type: Watch -- LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops
- [LOOPS] LOOPS meetings in May 2020, replacing IET… Carsten Bormann
- [LOOPS] Other WGs/RGs (Re: LOOPS meetings in May … Carsten Bormann
- Re: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in … Liyizhou
- Re: [LOOPS] Other WGs/RGs (Re: LOOPS meetings in … Carsten Bormann