RE: Application-Aware Networking (APN) focused interim

Hi Michael, 

Thank you for your insights shared and comments although these comments seem to be for the presentations in the last IETF and the old versions of the drafts. Thanks to the feedback we received from the presentations last time, we have further updated the drafts and narrowed down the scope. 

The main changes we have made to the drafts are as follows:
1. We have removed the application-side solution, only keep the network-side solution. This should have solved your concerns. Basically we are only focusing on the network. 
2. The APN attribute is acquired based on the existing information in the packet header such as 5-tuple and QinQ (S-VLAN and C-VLAN) at the edge devices of the APN domain, added to the data packets along with the tunnel encapsulation. 
3. When the packets leave the APN domain, the attribute will be removed together with the tunnel encapsulation header.
4. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, for example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. 

The latest version of the drafts:
https://datatracker.ietf.org/doc/html/draft-li-apn-framework-03 
https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-03
https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-02 
https://datatracker.ietf.org/doc/html/draft-peng-apn-security-privacy-consideration-01 

Best regards, 
Shuping 

> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Michael
> Richardson
> Sent: Friday, May 28, 2021 12:34 AM
> To: rtgwg@ietf.org
> Subject: Re: Application-Aware Networking (APN) focused interim
> 
> On 2021-05-06 6:37 p.m., Jeff Tantsura wrote:
> > Dear RTGWG,
> >
> > We have scheduled Application-Aware Networking (APN) focused interim
> > (agenda to be published), June 3rd, 2021, 7:00AM PST
> 
> Hi, I'm glad that we are having this meeting.
> I saw the APN presentations (in recording) at the SECDISPATCH and SAAG, I
> think it was.
> 
> I've been through the documents, and I think that they get lost in the weeds.
> What is confusing people, particularly security people, is that we simply
> don't have a model as to how any of this is supposed to work.
> As someone who has mostly ignored "5G", but who survived the "revolution"
> that was ATM, then diffserv/diffedge, then the MPLS revolution, I feel
> justified in ignoring the huge oversell that is 5G.
> 
> Let me explain why all these things failed to increase operator incomes.
> (Did they reduce complexity for some entities? Sure. Did it offer new ways of
> provisioning networks that weren't available before? Sometimes)
> 
> Lack of financial model.  Inherit with this is a TRUST MODEL that includes
> senders, receivers, requestors and responders.
> (Senders transmit data. Requestors ask for data to be sent) In my
> relationship with, for instance, Netflix, I'm:
>    a) the receiver of the data
>    b) the requestor of the data
> Netflix is:
>    c) the sender of the data
>    d) the responder to my request
> 
> For the operator to get more revenue from me, I have to have a way to give
> them more money, or a way for me to indicate to the sender of the data that
> I requested, a way to give the operator money for new services.  (Netflix
> never pays for the traffic in the end, because I pay them.  This is far more
> obvious if this is e2e game traffic, or webrtc pandemic conference traffic)
> 
> Most of the security questions about whether the *application* or the
> *kernel* (of the smartphone), or the Home/LTE/5G router or the 5G tower,
> etc. is doing some signaling into some 5G thingy... (I'll call it a "VC"
> in ATM speak, because really, it shows why this is a 25+ year failure)
> 
> It has all failed due to layer-9 issues.
> 
> I still can't ask, (during pandemic) for my carrier or ISP to prioritize traffic
> that *I* care about for an extra fee.  Anything that involves the ISP or
> carrier "guessing" is a fail thanks to
>    1) invasion or privacy
>    2) Net Neutrality
>    3) QUIC <-- largely a response to failures of (1) and (2)
> 
> Diffserv's "diffedge" (never published as an RFC, alas) got closest to being
> real.  Windows2000 had an API apparently.  Specifically, it had a way for
> an application to ask the kernel for additional services.  That failed in the
> market, because really it had no place to connect to an "operator" ...
> 
> Fundamentally, this goes back to the fact that we continue to design
> networks which are either anonymous or stateful.  The end-to-end principal
> says keep the state out of the core, and this keeps winning each time we add
> a zero to core network speed (now with Gbps at the end).  Meanwhile, the
> telco/mobile space keeps adding more and more state that has to be
> connected to some identity. (IMEI/SIM/etc.)
> 
> We need a situation in the middle where the network actually says who it is
> to the end-systems, and indicates, via authenticated communication
> between "middle box"en and end system that the middle box exists, and
> what services it can offer... "for you my friend? special deal!"
> 
> Said middle boxes are in quote, because they aren't NATs, and they don't
> throttle or firewall traffic, but they can be taught to remark in various
> directions.
> 
> diffedge did this with RSVP, but back in 1998, the secure communication on
> top of that that is required to establish trust sufficient to enable exchange of
> currency was just too much for people.
> 
> I'm writing this now, a week ahead of the virtual interim in the hope that the
> proponents will go back to their slides and refocus their effort into
> explaining to the security and routing people what your goals are.
> 
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg