Re: [Apn] Comments on APN Charter Discussions

[David Lake <[e-mail]>]

Hi Shuping

Thank you for the reply and explanation.

On this basis, I think we need to discuss with IAB/IESG/IRTF how a much wider-scoped project looking at the architecture of a solution that APN (and other IETF-family protocols) would support.

I do worry that as an industry we have forgotten that consumers pay and therefor expect a service to be delivered against a contract and although MPLS-TE is a great way of acting on contracts at a macro-level (I am very unclear what ‘slicing’ actually is because it seems to be a heavily overloaded term at the moment) we have no way of providing that at a micro level or under control of the most important actor in the entire system; the end user/consumer.

Maybe this is a discussion to have with the IAB leadership team in parallel to the APN WG?

David

From: Pengshuping (Peng Shuping) <pengshuping=[e-mail]>
Date: Wednesday, 12 October 2022 at 10:11
To: Lake, David (PG/R - Comp Sci & Elec Eng) <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Comments on APN Charter Discussions
Hi David,

I just realized that you may have a different understanding of the scope of the proposed WG, which has been narrowed down after so many rounds of discussions. This is probably because you may not be familiar with the history. My presentation@IETF113 may help, https://datatracker.ietf.org/meeting/113/materials/slides-113-rtgwg-4-apn-update-00.pdf.

As you can see from our suggested text to update the Charter, we tried to further clarify the scope in the Charter according to the comments we received:
“The Application-aware Networking (APN) Working Group will develop a framework (including key functional components and interfaces) to enable fine-granularity network service provisioning (traffic operations) within the network domain(s) that supports APN (i.e. APN domain). By APN domain we intend the operator infrastructure where APN is used from edge to edge (ingress to egress) and where the packet is encapsulated using an outer header incorporating the APN information. Typically, an APN domain is defined as a Network Operator controlled limited domain, in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to provide network services. APN aims to leverage the ability to apply policies to traffic flows entering into the infrastructure (APN domain). For example, at the headend (ingress) traffic is steered into a given path/policy, at a midpoint node the corresponding performance measurement data is collected, and at a service node a given function is executed.”

Regarding “the operator domains are simply transport bit-pipes”, please find my reply to Andrew’s email in the mailing list previously, “thanks to the years' hard work of the network engineers, the network capabilities have become very rich such as deterministic networking and network slicing which can provide more network functions than QoS. APN can further unleash these capabilities. The APN work does not interfere with TE (all flavors), or Slicing (whatever flavor is) or any other form of traffic engineering. It is a complement to all of these. The APN header containing these marking bits can be encapsulated in the existing encapsulations...”

Many thanks for your comments! Hope we can discuss more in the chartered WG soon. :)

Thank you!

Best Regards,
Shuping


From: David Lake [mailto:d.lake=[e-mail]]
Sent: Tuesday, October 11, 2022 7:49 PM
To: Pengshuping (Peng Shuping) <[e-mail]>; [e-mail]
Subject: Re: Comments on APN Charter Discussions

Shuping

I understand this, but what I fail to see is how this is any different from what can be accomplished by an operator already with MPLS TE.

The key new item for me would be for the application (i.e. the end-user) to be able to determine what QoE they wanted and have that instantiated across the infrastructure.  By definition, that would need to be across multiple domains.

My concern is that for the most-part, the operator domains are simply transport bit-pipes – what the user cares about is the experience they have.  If I as a consumer attribute value to a specific QoE then I see nothing wrong with being able to request that of the infrastructure and for multiple domains to be organised to deliver against that.  This is EXACTLY what happens in IMS and would seem to be a very good model of granular service control based on application need.  But it only works within one domain and only for the specific services that the operators determine.

HOW the packets are treated in order to carry the required meta-data is relevant but only interesting in the context of an overall system architecture which we don’t have.

I feel we would be MUCH better off to spend time on defining what we are trying to achieve (really this is the age-old ‘Layer 8’ issue and a return to some of the ideas of Active Networking, IMS and AMS as discussed in SG16 many years ago).

I’m slightly concerned about terms such as ‘good’ performance – these are totally subjective!  The user/application will know and value what is required and what we need is a method of a) declaring that to the infrastructure and b) having every element in the delivery chain act according to the requirement.  Yes, that MAY be through packet-marking by APN but it may be by some other process (think how SS7 achieved this VERY successfully with parallel control and data planes, for example).

Plus we need to remember that a chain is only as strong as its weakest link – if one domain in the delivery chain is unable to support the requirement, it doesn’t matter HOW good the other domains are; the service will not be delivered according to the user/application requirements (which to my mind should indicate a breach of contract and recompense).   And our service delivery chains are both complex and fragile (last mile, interconnects, caches, client stack, server stacks, DNS, etc.).

David

From: Pengshuping (Peng Shuping) <pengshuping=[e-mail]<mailto:pengshuping=[e-mail]>>
Date: Tuesday, 11 October 2022 at 04:52
To: Lake, David (PG/R - Comp Sci & Elec Eng) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments on APN Charter Discussions

Dear David,



Many thanks for your comments and constructive suggestions on improving the Charter!



APN works for multiple domains of the same operator. APN is a domain-based solution. When the packets go out to other domains, these domains can also use APN to provide fine-granularity network services if they also support APN. In terms of the users' QoE, indeed if all the network domains which the packets go through support APN, then the performance would benefit from APN. Otherwise, at least the performance of the multiple domains of the single operator will be good.



Thank you!



Best Regards,

Shuping


From: Apn [mailto:[e-mail]] On Behalf Of David Lake
Sent: Thursday, October 6, 2022 9:47 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Apn] Comments on APN Charter Discussions

Andrew asked for some comments and feedback on the ballot responses – here goes…

Several objections talk of the issue with the scope of the work and indeed the draft charter mentions this:  “APN info carried in packets is applicable only within a limited trusted domain, such as a network operator-controlled domain”

I have an issue with this point.  First, the experience of accessing a service is dependent on a number of factors across multiple domains and to limit the operation of APN to a single domain to my mind is to limit its usefulness.

The next point in the draft charter mentions that ‘… APN info MUST NOT rely on the knowledge of specific applications.’   This needs clarification.  Whilst APN need not have detailed knowledge of the application requirements, it is vital that the application needs be expressed to the infrastructure in such a way that a delivery contract can be constructed and enforced between consumer and producer.  This is also where I have an issue with a single domain approach – if I as a consumer require a service with X outcome then I must be able to construct both an overall contract to deliver that requirement and then break down the individual actors involved in delivering their part of the contract.

Coupled with this (and I know this is often anathema to IETF folk) we need a settlement system that rewards those actors who deliver against the contract and penalises those who don’t.  We also need to be able to apportion compensation in the supply chain – in other words, as well as an engineering construct we need an economic construct to deliver against a desired outcome.  This exists in a limited manner today within specific domains (think IMS in a single operator domain) but we need to extend that so that when I request a service with a specific treatment requirement that is costed and delivered across the entire substrate.

My concern at the moment is that APN is only useful if consumer and producer are within the same operator domain and increasingly this is not the case (in fact, the only service I think I now consume from my operator is the very rare VoLTE calls I still make – everything else is OTT across multiple domains).  In a past life, I was involved in Enterprise IP Telephony where codec bit-rates were counted and calls not-allowed if the networking infrastructure didn’t have enough capacity at given data profiles (Google ‘Call Admission Control’) – this was deep application-awareness to ensure that voice call quality was maintained but it only worked because the system had knowledge and control of all aspects of the infrastructure.   We need to work out how to expand this more broadly because our only industry-wide solution to-date is to vastly over-provision (and that is economically undesirable especially where the primary access method is hugely expensive RF).

APN may be helpful in that it could provide a declarative method to express application desire but without an over-arching framework which understands the organisation of the elements in the chain to deliver against that desire, I don’t see how it is useful.   I think we need to take a top-down architectural approach to service delivery and settlement from which specific protocols will emerge.  It seems that APN is looking to discuss the details of the protocol, not the architectural basis of the overall solution.

And that’s my biggest concern.  Is this an IETF job at all?  It would seem to me that we need to be looking at an holistic approach to service supply-chains, not lower-level protocols (at the moment – these will come later).

Should APN be an IRTF group?  A wider IAB study?  An ETSI ISG?  ITU study group?  Personally, I think we’d do well to get some economists who understand supply-chain economics in the Internet involved in this as well…

(I have one further comment on the name – APN is already in use in 3GPP in the context of network selection and there could be a degree of confusion).

David

David Lake

Tel: [phone]
[Text  Description automatically generated with low confidence]
5G & 6G Innovation Centres
Institute for Communication Systems (ICS)
University of Surrey
Guildford
GU2 7XH