Re: [Apn] Drafts vs. presentation

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Mon, 22 March 2021 09:29 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9DB3A0CF4 for <apn@ietfa.amsl.com>; Mon, 22 Mar 2021 02:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 Ig3lagti4CIn for <apn@ietfa.amsl.com>; Mon, 22 Mar 2021 02:29:47 -0700 (PDT)
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 C7BAA3A0CF2 for <apn@ietf.org>; Mon, 22 Mar 2021 02:29:46 -0700 (PDT)
Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F3pxS0D1Sz67y8N; Mon, 22 Mar 2021 17:25:00 +0800 (CST)
Received: from fraeml711-chm.china.huawei.com (10.206.15.60) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Mar 2021 10:29:41 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Mon, 22 Mar 2021 10:29:41 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.141]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0513.000; Mon, 22 Mar 2021 17:29:36 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Watson Ladd' <watsonbladd@gmail.com>, "apn@ietf.org" <apn@ietf.org>
Thread-Topic: [Apn] Drafts vs. presentation
Thread-Index: AQHXHVPWE9u9lrgCBkSKqGsH+7J4pKqMHDIAgAOdFQA=
Date: Mon, 22 Mar 2021 09:29:35 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE19A137D5@DGGEML532-MBX.china.huawei.com>
References: <CACsn0cnZqv+kDrg1jfDBsmxV+JAL03XQCFgc1_S7qa6bfoCd4g@mail.gmail.com> <08b801d71d6e$7c3dc530$74b94f90$@olddog.co.uk>
In-Reply-To: <08b801d71d6e$7c3dc530$74b94f90$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/I0shUwncrmGeVHLHPudlRzh-M-4>
Subject: Re: [Apn] Drafts vs. presentation
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2021 09:29:52 -0000

Hi Watson, Adrian, 

Thank you for your comments and feedback! Please find some responses in line below, starting with "Shuping". 

-----Original Message-----
From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Saturday, March 20, 2021 5:51 PM
To: 'Watson Ladd' <watsonbladd@gmail.com>; apn@ietf.org
Subject: Re: [Apn] Drafts vs. presentation

Hi Watson,

Some really good points here (thoughts in line) to which I would also add the observation that there was confusion in the meeting between the slides clear statements and what people believed they had read in the drafts (especially the framework). This covered:
- Is the application/user identified to the network by the APN ID?
- Who is responsible for placing the APN ID in the packets?
If the slides were right then I am much less worried by APN. Possibly some cleaning of words is needed in the drafts?

Shuping> Please refer to the slides we presented in this IETF as well as this draft https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-01 which contains the latest introduction of APN. Some existing drafts still include both host-side solution and network-side solution, but now we only focus on the network-side solution, which uses the network edge devices to tag the APN attribute rather than the applications. APN is not about identifying the particular user or application. APN is about efficiently enforcing policies within the network to a particular flow that can be differentiated with the existing fields in the packet header. 

> I must confess that the SAAG presentation on APN was at a time of day 
> when I am ordinarily asleep and my caffeine titre might not have been 
> as high as necessary. But what I recall in that presentation and the 
> framework draft seem to be at odds, and I have some rather basic 
> questions about this.
>
> Firstly, it sounded like the service indications need to be parsed at 
> very high rate, enabling cut-through.

I'd agree with this. I think APN is about making forwarding decisions and/or packet handling decisions at line rate.

> But the drafts have variable length TLVs with a wide variety of 
> options, which to me would be incompatible with this sort of processing.

I think there are two points here:
1. We should separate the framework and requirements from the proposed solutions.
Just because we don't like some of the details of the proposed solution is not a reason to throw out the concept.
This is a bit of a Catch-22 [1] for people introducing work to the IETF:
either they get accused of trying to have their idea rubber-stamped [2], or they are told that they haven't provided enough details of how the solution will work. Hopefully we can work out whether the function is desirable and then (if it is) work out a solution through the "normal" IETF discussion process.

Shuping> Well said, Adrian. Yes, we would like to explore the reasonable solutions together with the community. 

> It seems that the same option can carry user ids and application ids, 
> as well as very detailed information about desired service levels, 
> beyond what I think network operators could reasonably make use of.

This is the line of worry for me. If user ids and application ids *can* be carried, it is easy to make the argument that applications and users that are worried about privacy are not required to supply the information.
However, it seems to me that applications do not have a good history of caring about users' privacy, while users do not always have control over what an application puts in a packet.

Shuping> APN is not about identifying the particular user or application. The network does not need to know this kind of information which may infringe the privacy, and it will not be useful to the network either. The network will only need an opaque value or a bit string to enforce the policies. 

> Wouldn't it be simpler
> to have named classes and have a fixed 16 bit field to select this 
> class? or pad it out to whatever is needed for aligment beyond it. 65k 
> classes is enough for anybody.

This would, indeed, be simpler. But I think it gets complicated to get the relative gradations of different aspects of "quality". Consider that there might be five aspects of service delivery that the application wishes to request (throughput, delay, latency, jitter, and fud). Give each one a range of 0-100. Now you have a lot of classes. (In practice, of course, 100 might be reduced to 15, but 5 might increase to 20).

Perhaps, therefore, it is better to consider having a number of fields and let the network tell the application how to use those fields to indicate different things.

> Secondly the framework draft seems to want to be independent of the 
> underlying transport, be it MPLS, IP, etc. And I don't think that 
> really is necessary In my limited understanding, the sort of decision 
> an MPLS path element makes is extraordinarily limited: the network is 
> a stack machine: you pop the label, plop on a few labels, off it goes.

Not so, I fear.

MPLS supports ECMP. That involves hashing the label stack and beyond. The "entropy label" was introduced for implementations that can't see far enough into the packet to reach the payload 5-tuple.

MPLS also has three Traffic Class bits for providing varied per-hop behaviors.

Furthermore, some suggestions have been made for carrying additional forwarding guidance in the MPLS label stack. For example, a label can indicate a forwarding function to be applied to the next label in the stack.
(The most simple form of this is "pop-and-go" or VRF indicator).

> All the intelligence is at the entrance and exits, and there isn't 
> really a local view of what path is better for what policy: whole idea 
> of MPLS is to avoid that.
>
> I think the proponents of this need to state the goal, and have drafts 
> that achieve that goal, and communicate it clearly.

Couldn't agree more. I believe the framework draft does contain this goal, but it still needs clarification.

Shuping> Thank you for your suggestions! We will refine the draft accordingly.

> Otherwise I feel
> like I'm grappling with a rather protean set of drafts, one that 
> promises all things to all people in ways that don't move the 
> conversation forward.

"Protean" may be unfair. But more focus is clearly needed to help the readers understand what the proponents want.

Shuping> Agree. For now, please refer to this draft https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-01 and the slides presented in this IETF. Thank you! 

Best regards, 
Shuping 

 
> Astra mortemque praestare gradatim

Benefactores servant futurum

Best,
Adrian

[1] https://en.wikipedia.org/wiki/Catch-22
[2]
https://www.modernprint.co.uk/wp-content/uploads/2018/02/Traditional_rubber_
stamp_makers_in_Pembrokeshire.jpg

--
Apn mailing list
Apn@ietf.org
https://www.ietf.org/mailman/listinfo/apn