Re: [Apn] 回复:GoalsofneartermAPNwork

[Joel Halpern <[e-mail]>]

Adrian, I am trying to figure out what to make of your message.

I think I must be misreading it.

The message seems to say that there are a range of use cases being 
discussed, and a range of packet behavior adjustment that is desired.  
That does not seem to add up to a coherent BoF much less a clear working 
group charter.  Having a BoF without clear focus ha been demonstrated 
repeatedly to be ineffective for the IETF.

Yours,

Joel

On 1/21/2023 1:17 PM, Adrian Farrel wrote:
>
> 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 <[e-mail]> *On Behalf Of *Andrew Alston - IETF
> *Sent:* 21 January 2023 10:48
> *To:* yangfeng <[e-mail]>; jmh <[e-mail]>; 
> apn <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *yangfeng
> *Sent:* Saturday, January 21, 2023 5:36 AM
> *To:* jmh <[e-mail]>; apn <[e-mail]>
> *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 <[e-mail]>
>
> *发送时间：*2023-01-21 03:25:56
>
> *收件人：*apn <[e-mail]>
>
> *主**题：*[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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/apn
>
> Internal All Employees
>
>