Re: [alto] PANRG questions

Qin Wu <bill.wu@huawei.com> Fri, 26 November 2021 03:23 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8B3A077C for <alto@ietfa.amsl.com>; Thu, 25 Nov 2021 19:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 kuA9q8zcC-fU for <alto@ietfa.amsl.com>; Thu, 25 Nov 2021 19:23:43 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7303A0777 for <alto@ietf.org>; Thu, 25 Nov 2021 19:23:43 -0800 (PST)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J0g6x1xMLz67klM; Fri, 26 Nov 2021 11:23:05 +0800 (CST)
Received: from dggeml752-chm.china.huawei.com (10.1.199.151) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Fri, 26 Nov 2021 04:23:39 +0100
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml752-chm.china.huawei.com (10.1.199.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Fri, 26 Nov 2021 11:23:37 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.020; Fri, 26 Nov 2021 11:23:37 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Martin Duke <martin.h.duke@gmail.com>, IETF ALTO <alto@ietf.org>
Thread-Topic: [alto] PANRG questions
Thread-Index: Adfic15Lrhru5+X5S1OmC49A++7zWg==
Date: Fri, 26 Nov 2021 03:23:37 +0000
Message-ID: <a0b62da730d0427ca352cc7f9e251409@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_a0b62da730d0427ca352cc7f9e251409huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/jN86AiDoV9r4rLL3KVLz5PnYX_M>
Subject: Re: [alto] PANRG questions
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Nov 2021 03:23:48 -0000

Hi, Martin and All:
I believe PANRG questions paper focuses on cross layer cross domain path aware networking research and set guideline or requirements for future protocol in the future internet architecture. A few thoughts on PANRG questions:
1. This draft said "PCEP technologies or SD-WAN technologies are limited to a single administrative domain", I think there are many technologies which can be extended to multi-domain cases such as SFC technology, etc. PCEP technologies can be used in large, multi-domain networks, but this requires special computational components and cooperation between the elements in different domains, See RFC4655 for more details. Many computational components have been well developed in PCE WGs.
The ONUG Open SD-WAN Exchange (OSE) works on an open framework which allows for one vendor SD-WAN domain to communicate with another vendor SD-WAN domain. Therefore I am not sure "limited to a single administrative domain" is accurate.

2. I think the endpoints can be categorized into application endpoint, and network endpoint, network endpoint can be tunnel endpoint, or overlay endpoint.
Application endpoint works at transport layer or application layer while network endpoint works at network layer.
If the trend is from path-oblivious networking to path aware networking, should all network endpoints with path awareness or path oblivious are replaced with application endpoints with path awareness? Only communication between application endpoint are allowed? How it is different from peer to peer protocol (https://datatracker.ietf.org/wg/ppsp/about/)?

3. When we add more path control to application endpoint? What about two application endpoints compete for the same path control? What about one application endpoint takes all best path?
What about one application endpoint is an attacker? How does this change the current internet architecture?

4. When application endpoint has path control, does it mean more states need to be maintained at the host side, i.e., stateful?  Or it still needs to communicate with another party for all the path information, i.e., stateless?

5. Do panrg questions set requirements or guidelines for existing work in IETF or future technologies for next generation of internet architecture?
I can see draft-arkko-iab-path-signals-collaboration laid foundation for many privacy related work coming out recently in IETF such as oblivious HTTP.

6. When we say "Competing control inputs from path-aware endpoints and the routing control plane", I thought path aware endpoints can select the best peer in the destination while routing control plane
can help you in the network side select different network path with better SLA or select less congested path, I see this complimentary, One can be seen as hosted based solution, i.e., path aware endpoint while the other is network based solution, i.e., rely on routing control plane to select the path. They are complimentary. Similar example is Mobile IPv6 and Proxy Mobile IPv6, one is host based solution ,the other is network based solution,  Not necessarily one replacing another.
If the application endpoint works at transport layer or application layer, e.g., multiple TCP path selection, while the network endpoint have path control at the network layer
in the underlay network, e. g, multiple TE path selection. no competing, in my think. Even the network endpoint is the overlay endpoint, I feel path control or selection on the overlay will not have impact on the underlay network.

7. When we talk about "Need to resolve conflicts of intent between the network's operator and the path selection at an endpoint", if it is in the same layer, my impression is one is network policy while
the other is local policy at the endpoint or tunnel endpoint or overlay endpoint? When there are policy conflicts, one could override another.
8. Who will be the consumer of path aware networking in the future? personal consumer device in a home network who has 5G connection, Wifi connection, broadband fixed line connection to different ISPs?

-Qin (Speak as individual)
发件人: alto [mailto:alto-bounces@ietf.org] 代表 Martin Duke
发送时间: 2021年11月18日 8:30
收件人: IETF ALTO <alto@ietf.org>
主题: [alto] PANRG questions

Hello ALTO,

Please have a look at this paper in the PANRG about open research questions in path aware networking.

https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/

In some ways this document is orthogonal to ALTO, but in others (notably 2.1 and 2.2) ALTO has at least attempted to provide a complete answer.

As I've said before, a lot of proposals for future extensions to ALTO could usefully get vetted in PANRG while we complete the items in our current charter.

Thanks,
Martin