Re: [Apn] [IAB] IETF 111 reports: APN BOF

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi David,

Thank you for your interest and the information shared! BTW, how is Guildford and Surrey? Missing my time working there. ☺

In this following draft, the third case in the section 5 is about the mobile broadband scenario. From the Figure 3, you can find that the APN domain we focused is limited to the Mobile Transport Network. It seems that here you talked more about the mobile network/path between the UE and the GW if I understood it correctly.

https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-04

Another point to clarify is that the network edge in APN is owned and controlled by the transport network operator.

At this network edge node of the APN domain, the GTP-u is mapped to a transport network tunnel encapsulation. In your view, what fields in the GTP-u header could be used to construct the APN attribute to be used within the APN domain?

FYI, https://datatracker.ietf.org/wg/apn/documents/

Thank you!

Best regards,
Shuping



From: Apn [mailto:[e-mail]] On Behalf Of David Lake
Sent: Monday, August 2, 2021 9:59 PM
To: [e-mail]
Subject: Re: [Apn] [IAB] IETF 111 reports: APN BOF

Given the excellent summary, please excuse my hijacking it to make some additional points.

I would very-much have liked to have been able to make the call but it was on a Friday evening at 10pm which clashed with the First Night of the Proms here in London and after 18 months of musical drought as much as I love IETF, the music won…!

Comments <DL> in-line </DL> and I very-much look forward to the on-going work in this group.

David


On 2 Aug 2021, at 09:28, Jari Arkko <[e-mail]<mailto:[e-mail]>> wrote:

IAB members are expected to track and report on BOFs that they visit during the IETF week. Our reports are mostly made for the AD and the IAB and are just for information, but I like to send my reports to the BOF list as well in case it is useful. Of course, what is in this report is just an individual opinion. ADs, the group itself, etc. typically have different views.

Jari


Begin forwarded message:

From: Jari Arkko <[e-mail]<mailto:[e-mail]>>
Subject: [IAB] IETF 111 reports: APN BOF

The BOF was well run and there was enough information and plenty of time for (IMO, high quality) discussion. Thank you Adrian Farrell, Bob Hinden, and Dan Voyer for running the meeting and allowing the discussion to flow and and making sure everyone got to make their points, including prioritising new people’s comments from the mic. We should probably do that more often.

Martin Vigoureux, the AD, underlined the need for any standards work in this space to have sufficient diversity of participants and players. He also said the proposal may have started on the wrong foot, but they've changed the approach significantly. Lets give the BOF a fair shot. Similarly, Adrian noted that the effort should not be understood according to the name "application-aware", but rather according to the actual proposals as the evolving function may not match the name any more.

Zhenbin Li introduced APN. The basic idea is that packets will  be classified on the edge according to their 5-tuples and access ports, and a structured attribute attached to the packet as it is tunneled through the network. Application or user identity  based classification is not in scope. The benefit of APN is that you only do the 5-tuple mapping once, and the rest of the network can operate based on the APN attributes.

<DL> If this is the basic idea, then we need to be careful with the term ‘APN’ as it is already used in 4G/5G to accomplish almost exactly the same thing.  In 4G the TFT (Traffic Flow Template) is downloaded to the UE and it essentially ’steers’ the packet into an appropriate APN according to the 5-tuple.

The purpose of the APN is to match numerology (i.e. access parameters) with service level - the APN associated with packets carrying VoIP will be much more robust in terms of modulation scheme than the ‘best-efforts’ APN used for data. APN paths are usually mapped to MPLS queues and DSCP markings at the e/gNB.

Use is also made of RoHC to compress the IP header - air-time is money in 4G/5G so it is important that spectrum is used efficiently.  Personally, I think we would do well to start accounting for the cost of headers in wireline networks as well - every bit takes ££/$$$ to process and we need to minimise that as much as possible.

In 4G the TFT is controlled by the policy set by the PCRF - this is owned by the operator and lives only within the mobile domain.   In 5G, the AF connected to the Service Bus should be able to expose elements of policy to third parties.  It remains to be seen how this will play out.
</DL>


Gyan Mishra talked about why existing mechanisms are insufficient. DSCP markings do not have enough bits. IPv6 flow labels, SFC serviceIDs, SR binding SIDs, etc. are lacking according to the proponents, largely based on argument about them being used in special circumstances (?) Although to me it seemed that any design based on a new APN encapsulation protocol would also be used in the special circumstance of APN being deployed in that particular network. Three other short presentations were also given by Luis Contreras, Chongfeng Xie, and Shuping Peng.

The main points in discussion revolved around:

1/ Whether new technology and tunneling/encapsulation technology is needed, or if existing tools are sufficient.

<DL> More ’tunnelling’ concerns me.  There are points on the network where 10 or 11 headers will be applied to data-in-flight.   There are three (inner IP, GTP, outer IP) by default from every mobile device and this is already very inefficient for small-size payloads (e.g. mMTC applications).  I think we should be looking to ensure that the ratio of control-plane:data is always geared towards the part of the packet that carries the value, i.e. the data. </DL>



2/ Whether there are issues in distributing a very general information field, rather than a specific and limited information item.

<DL>  If it is too general, how is it any different from DSCP?

I’m aware that I wasn’t on the call but for me the problem we have not solved is how to ensure my application outcome across multiple domains and therefore the information that we carry must be sufficient for all actors in the delivery-chain to be able to a) validate that I have the right to request (and be supplied) a specific outcome and b) have enough information to be able to construct that outcome.

It is perfectly possible, within a single domain, to have a defined outcome today - VoLTE does this within a single operator where numerology at the RF layer and packet scheduling in the IP network are co-ordinated to permit/deny services based on resource availability.

The issue is that if there are MULTIPLE domains involved, there is no way of defining, requesting or policing an application outcome.

However there is another aspect we need to consider.

In a supply-chain with finite resources, if one actor is given a right to obtain delivery against an SLA, the flip-side is that others may not only have lower service, they may need to be denied service.

We don’t do this at-all today in the Internet (but we do do this on mobile networks, telephone networks and most other transport services, e.g. rail, gas, electricity).

I’m not sure this is fully in the scope of this group, but the data we carry also needs to reflect the entitlement of the application in the same way that if I turn-up with an off-peak ticket to travel into London before 10.00am I will be denied access or offered service based on paying an up-lift.

We talk about the ’network-edge’ being able to classify the traffic but under whose authority and where is that?  As a user, the ’network-edge’ really is my desire to have a particular application outcome - how do I express that to the infrastructure?  </DL>



I'd say there was fairly broadly shared opinion among the chat and mic line participants that these two are issues. We could discuss the details, there are interesting points to dwell into, and certainly no uniform agreement on all details. But maybe the high-level bit is that there are some concerns at least.

I suggested that maybe a more realistic approach at the IETF would be to write an informational document that explains how to use network edge classification to encode a tag with very few bits, and  how to transport that tag using existing IETF encapsulations. That might reduce both of the above concerns.

Martin declared the BOF a success in terms of being able to discuss the topic. But he said that there is undeniably a gap that needs to be filled between the proponents and the community. The objective is generally well understood, but there's a question mark why the objective cannot be achieved using existing tools.

<DL> I wonder if we need to abstract the problem to another layer?   We do seem to have various network-level tools we could use to provide an ‘APN’ like solution but they don’t appear to work between domains (domains being not just network domains but client and server-side applications and infrastructure).

Are we missing a common language here to describe user-desire?

We are possibly also missing an admission control side to match demand to supply.  </DL>


--
Apn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/apn