Re: [Apn] 回复:GoalsofneartermAPNwork

Feng, again – asking with no hats on,

How exactly does this differ from DSCP – (or extended dscp with more bits.)

When I read what you wrote below – to me – this reads exactly like more in depth dscp, and maybe I’m reading this wrong so I’m open to hearing otherwise.

But (putting hat back on) – I see this as much of the problem with getting broad based support and adequately defining a charter.  There seems to be a lot of confusion about what exactly is being attempted here.  A simplistic reading of what is below, points to something like more dscp bits, yet, at the same time, we here talk of the need for something else for reasons that don’t seem to be clearly defined.  To built a broad based community support for this work, I think there needs to be more clarity around what is actually being attempted – because that forms the basis of creating a framework, which in turn leads to solutions.

There were very large fears raised about the privacy and security aspects at the original BOF, and assurances were given at RTGWG that things like the ability to identify an application direct etc wouldn’t be there.  That got us some movement, but its lead to another question, if you remove that, is what you are left with nothing more than more DSCP bits (or something along those lines), and its lead to a question of, remove the application identification parts (which create significant security and privacy issues which the last BOF and what I believe was indicated in RTGWG clearly show are not tenable) – what’s left?

If indeed we are saying – this is purely an expanded form of DSCP or something similar – then – that needs to be crystal clear and spelled out as such, but there seems to be different messages about this.

Andrew

From: Apn <apn-bounces@ietf.org> On Behalf Of yangfeng
Sent: Saturday, January 21, 2023 5:36 AM
To: jmh <jmh@joelhalpern.com>; apn <apn@ietf.org>
Subject: [Apn] 回复:GoalsofneartermAPNwork

Hi Joel，

Chasing good QoE is quite nature.  As described in my previous email, we are currently distinguishing services by source IP address at our network edge devices. However, the source addresses are discrete, we hope there is a way to transform the address from discrete space into a linear space , which will make it be easier for classification, so that the services and policies along the tunnel can be combined in a simple way. Eventually that can improve our efficiency and reduce costs. The tagged information is not associated with any user or application. It is a group of users that have the same requirements on the network, and they will have the matched treatments on the various nodes along the tunnel.

Br
Feng

-------原始邮件-------
发件人：Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>
发送时间：2023-01-21 03:25:56
收件人：apn <apn@ietf.org<mailto:apn@ietf.org>>
主题：[Apn] Goals of near term APN work

I have re-read the email discussions and the most recent draft of the
charter.
I am quite confused by the charter.  Aw far as I can tell, it assumes
that we need a new IP header field, that the field will carry a range of
information that will help a range of network behaviors, and that we do
not have the ability to address these needs currently.  It then says
that the WG will develop a framework for such a field.
Is developing and defining a new (variable length?) header field to
address some ill-defined broad range of needs really the goal?
Yours,
Joel
--
Apn mailing list
Apn@ietf.org<mailto:Apn@ietf.org>
https://www.ietf.org/mailman/listinfo/apn<https://www.ietf.org/mailman/listinfo/apn>

Internal All Employees