Re: [Apn] 回复:GoalsofneartermAPNwork

I think you’ve caught a valid point here, Andrew.

There seem to me to be a number of use cases that are similar, relatively simple to express, and with abstract solutions that are “add a few more bits to the packet header.”

“More DSCP bits” is certainly one use case. If this was the only example, and if we were certain that we needed mode DSCP bits and that we couldn’t overload any existing fields, we’d be talking about how to shim a few extra bits into the packet header.

Another use case is “provide an abstract flow identifier”. This is useful in the case that the 5-tuple is lost (for example, because of tunnelling – including, but not limited to, IP-in-IP and IPsec tunnels), but differentiated treatment of flows is desired. Here we might need a few bits/bytes into which to “hash” the 5-tuple and possibly some more packet information. The resulting hash can also be programmed southbound into the routers to tell them what specific actions to take. The result is not unlike the MPLS entropy label, and one could argue that the IPv6 Flowlabel could be used except that that field already has an established use. Again, if this use case is believable, then we’d be looking for a way to shim a few extra bits into the packet header. (Note that, as discussed in another thread, care is needed because statistical analysis of packets might give some indication of the meaning of the flows and the hash values.)

A further use case is “identify where packets entered the network”. The case here is about detecting hostile flows within the network and installing ACLs or similar filters at the network edges without having to install such rules at every edge. While the use of IP-in-IP across the network can achieve this, an alternative would be to “hash” the entry node + interface and shim that information into the packet. Yet again, we’d be talking about only a couple of bytes.

These previous cases are similar to the “problem” of performing decent network management in the presence of encrypted flows.

I think there are other similar use cases being discussed.

The common thread here is that a few extra bits of bytes need to be attached to the IP packet as it enters a network so that the network can apply behavioral and management rules to the traffic. The questions become:

*	Are the use cases valid (regardless of whether they can be solved by existing techniques)?
*	What information needs to be carried to address the requirements?
*	Are there existing fields or techniques that address the requirements?
*	If there are not existing fields or techniques, how can the additional information be carried?
*	Is it possible that further use cases might arise?
*	If there are multiple problems need to be solved, would it be wise to provide a generic (potentially extensible) mechanism?
*	What are the security, privacy, manageability, backward-compatibility issues that need to be addresses?

The challenges, I fear, are multiple:

*	The original discussion of this space lacked some clarity, and many people may need to flush their caches to get the latest picture.
*	The collection of smallish use cases are sufficiently diverse that each person will naturally not consider all use cases to be urgent.
*	As engineers, we jump toward solutions and so we keep falling into the “How will you encode this? How will you carry it in the packet?” discussion.
*	The proponents must not assert that privacy/security is not a problem, but must open the door for a proper threat analysis by the community. Conversely, those who have legitimate fears for privacy/security must not shut down the discussion, but must offer the threat analysis.

I thought that the discussion in RTGWG had led to the conclusion that it was important to establish the use cases and a “framework” that discussed the concepts that needed to be provided (along with the security and manageability discussions). That is, RTGWG recommended doing the initial work, but leaving the protocol/encoding/encapsulation work on one side until the early pieces had been cleaned up. But the IESG response to the proposed charter seemed (I am not an expert in this) to say that the IESG wanted more details of the proposed solution before they could understand whether a working group was appropriate. 

It would help, I think, if the proponents could get a clue which way to jump. Put some solution details on the table so that they can demonstrate how this would be done, or focus only on the use cases, requirements, and framework? Maybe, of course, the answer is “complete all of the Internet-Drafts and then be accused of asking for a rubber stamp” :-)

Cheers,

Adrian

From: Apn <apn-bounces@ietf.org> On Behalf Of Andrew Alston - IETF
Sent: 21 January 2023 10:48
To: yangfeng <yangfeng@chinamobile.com>; jmh <jmh@joelhalpern.com>; apn <apn@ietf.org>
Subject: 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 

Internal All Employees