Subject: [arch-d] Questions for APN: Q#5

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 21 Sep 2020 02:19:11 +0000

Dear all,

#5. What are the valuable use cases/usage scenarios of APN?

Drafts have been posted on various use cases such as Game Accelerating, Edge computing, SD-WAN etc.

1)       https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01
2)     https://tools.ietf.org/html/draft-liu-apn-edge-usecase-00
3)     https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00
4)     https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase-00

Use cases have also been presented and discussed during the APN side meeting@IETF108. Please find the slides.
https://github.com/APN-Community/IETF108-Side-Meeting-APN

There have been some discussions on these use cases in the APN mailing list as well. Please find the archives.
https://mailarchive.ietf.org/arch/msg/apn/c-fQP4LRpe6yj3lJBsaRxTVcWHA/
https://mailarchive.ietf.org/arch/msg/apn/MCVuBYa7jgtJsIDEpbGTZ0U8Bvg/
https://mailarchive.ietf.org/arch/msg/apn/c-fQP4LRpe6yj3lJBsaRxTVcWHA/

More interesting use cases are waiting to be explored. Please let us know if you have any other use cases. Thank you!

Best regards,
Shuping

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: [email-masked]
Cc: Pengshuping (Peng Shuping) <[email-masked]>
Subject: Question List for APN

Hi Folks,
Thanks very much for your attention to APN work. After much preparation work, we summarized the key questions to be clarified for APN which also were always asked. In fact in the past discussion and the APN side meeting of IETF108, many of these questions were discussed and clarified. Here we propose these questions together for your convenience.

The questions to be clarified are as follows:
#1. Which layer is for APN to do the application-aware work?
#2. Does APN provide services within a limited-domain or Internet?
#3. Which area in IETF would the APN work fit better?
#4. What is the relationship between APN and other attempts in IETF’s history?
#5. What are the valuable use cases/usage scenarios of APN?
#6. Is the fine-granularity operations needed/desired in the network?
#7. Why not just use DSCP?
#8. Does APN violate network neutrality?
#9. Will APN raise security issues since application-aware information is carried in the APN packets?
#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?

Shuping Peng will send the detailed answers for these questions in the mailing list in the following one or two weeks. The questions and answers may be not only be sent in the APN mailing list, but also be copied to the architecture discussion mailing list and the network token mailing list for more cross-area feedback if necessary.

If you have any comments on these questions and answers, we can go on to discuss through the mailing list.

Best Regards,
Zhenbin (Robin)

From: Apn [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Apn] Welcome to APN Mailing List

Hi Folks,

Welcome to join the APN mailing list. We are glad to have more discussion through the mailing list as the follow-up of the IETF108 APN side meeting.
In the process of APN work, many historic work items such as SPUD, PLUS, etc. have been proposed. It has been tried to be clarified that APN focuses
on the network layer and limited domains. Concerns on the security and privacy issues also have been proposed many times about the work. It also
has been tried to be clarified that in the trustable limited domains the security and privacy issues can be under control. These are the reasons why APN
work is based in the RTG area instead of ART/TSV areas.

But because of too much historic work to be clarified and its proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF are involved, it is
necessary to have more discussion to clarify the scope and work items for APN. We wish the mailing list would be helpful to the work and promoting the
cross-area communication to understand each other better.

You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/>, especially the materials
From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN>. This link also gives you pointers to
some of the relevant Internet-Drafts.

Over the next few weeks we will try to guide discussion by introducing some questions for debate. But please also raise your own issues and concerns
and contribute to the exchanges on this list.

Look forwarding to have more fun discussion in the mailing list.

Best Regards,
Dan & Zhenbin

---

From: Christian Huitema <[email-masked]>
Date: Sun, 20 Sep 2020 23:54:17 -0700

Shuping,

I am reading your use cases, and my immediate reaction is that this
developments should not be addressed solely in the routing or IP layers.
You are proposing to enrich the network service proposed to transport
and applications, which amounts to creating new APIs. Such works affects
multiple layers, and should be coordinated between multiple layers.

I also see that the description of application requirements is very
thin. The drafts mention augmented reality and online games, and focus
largely on latency requirements for these applications. The latency has
two main components: delays in the wires, and queues in the routers. The
APN draft for example mentions players of games using servers on another
continent, and thus experiencing large latency. But that latency is
largely due to the distance. That distance is not going to be magically
reduced by smarter queue processing. The same is even more true for
video conferencing or telepresence applications. I live near Seattle. If
I want to talk to my mother in France, the bits have to be carried
across America and the across the Atlantic ocean. No amount of smart
routing will change that. Application developers are well aware of these
issues, and have designed their applications in consequence.

There is a lot of tension between Internet Architecture and the
"application aware" proposal. The Internet was built on a fundamental
decision to not be application aware. Instead, the routers carry packets
of bits, independently of which application uses these bits. That way,
new applications can constantly be invented, without requiring
modifications in the network or permissions from the network operators.
This has proven to be key for the development of the Internet. I don't
think that we want to change that. Even if we did I don't think that the
discussion should take place solely in some specialized routing working
groups.

-- Christian Huitema

On 9/20/2020 7:19 PM, Pengshuping (Peng Shuping) wrote:
> Drafts have been posted on various use cases such as Game
> Accelerating, Edge computing, SD-WAN etc.
>
> 1)      
> https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01
>
> More interesting use cases are waiting to be explored. Please let us
> know if you have any other use cases. Thank you!
>
>  
>
> Best regards,
>
> Shuping
>
>  
>
>  
>
>  
>
>  
>
> *From:*Lizhenbin
> *Sent:* Monday, September 14, 2020 10:35 PM
> *To:* [email-masked]
> *Cc:* Pengshuping (Peng Shuping) <[email-masked]>
> *Subject:* Question List for APN
>
>  
>
> Hi Folks,
>
> Thanks very much for your attention to APN work. After much
> preparation work, we summarized the key questions to be clarified for
> APN which also were always asked. In fact in the past discussion and
> the APN side meeting of IETF108, many of these questions were
> discussed and clarified. Here we propose these questions together for
> your convenience.
>
>  
>
> Shuping Peng will send the detailed answers for these questions in the
> mailing list in the following one or two weeks. The questions and
> answers may be not only be sent in the APN mailing list, but also be
> copied to the architecture discussion mailing list and the network
> token mailing list for more cross-area feedback if necessary.
>
>  
>
> *From:*Apn [mailto:[email-masked]] *On Behalf Of *Lizhenbin
> *Sent:* Tuesday, August 18, 2020 7:22 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Apn] Welcome to APN Mailing List
>
>  
>
> Hi Folks,
>
>  
>
> Welcome to join the APN mailing list. We are glad to have more
> discussion through the mailing list as the follow-up of the IETF108
> APN side meeting.
>
> In the process of APN work, many historic work items such as SPUD,
> PLUS, etc. have been proposed. It has been tried to be clarified that
> APN focuses
>
> on the network layer and limited domains. Concerns on the security and
> privacy issues also have been proposed many times about the work. It also
>
> has been tried to be clarified that in the trustable limited domains
> the security and privacy issues can be under control. These are the
> reasons why APN
>
> But because of too much historic work to be clarified and its
> proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF
> are involved, it is
>
> necessary to have more discussion to clarify the scope and work items
> for APN. We wish the mailing list would be helpful to the work and
> promoting the
>
> You can get yourself up to speed with our discussions so far by seeing
> the materials at <https://github.com/APN-Community/>, especially the
> materials
>
> From the virtual IETF 108  APN side meeting at
> <https://github.com/APN-Community/IETF108-Side-Meeting-APN>. This link
> also gives you pointers to
>
> Over the next few weeks we will try to guide discussion by introducing
> some questions for debate. But please also raise your own issues and
> concerns
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Sep 2020 09:45:29 -0400

Well said.  Thank you Christian.
Joel

On 9/21/2020 2:54 AM, Christian Huitema wrote:
>> 1)https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01
>>

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Sep 2020 11:31:10 -0400

Agreed.  And let me stress and expand on one of his points.  The
ARPANET and Internet were built on top of a small number of
basic design principles and goals.  One was to be completely
insensitive to the applications being run so that packets,
routing, and policies could be application-independent.  We've
pushed the boundaries of that principle in the past but, unless
I misunderstand your proposal, its effect would be to abandon it
entirely.  If so, I think the community needs a fairly
comprehensive explanation of why that is necessary and how to
control or mitigate the negative effects.

   john

--On Monday, September 21, 2020 09:45 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

>> I am reading your use cases, and my immediate reaction is
>> that this  developments should not be addressed solely in the
>> routing or IP layers.  You are proposing to enrich the
>> network service proposed to transport  and applications,
>> which amounts to creating new APIs. Such works affects 
>> I also see that the description of application requirements
>> is very  thin. The drafts mention augmented reality and
>> online games, and focus  largely on latency requirements for
>> these applications. The latency has  two main components:
>> delays in the wires, and queues in the routers. The  APN
>> draft for example mentions players of games using servers on
>> another  continent, and thus experiencing large latency. But
>> that latency is  largely due to the distance. That distance
>> is not going to be magically  reduced by smarter queue
>> processing. The same is even more true for  video
>> conferencing or telepresence applications. I live near
>> Seattle. If  I want to talk to my mother in France, the bits
>> have to be carried  across America and the across the
>> Atlantic ocean. No amount of smart  routing will change that.
>> Application developers are well aware of these  issues, and
>> have designed their applications in consequence.
>> 
>> There is a lot of tension between Internet Architecture and
>> the  "application aware" proposal. The Internet was built on
>> a fundamental  decision to not be application aware. Instead,
>> the routers carry packets  of bits, independently of which
>> application uses these bits. That way,  new applications can
>> constantly be invented, without requiring  modifications in
>> the network or permissions from the network operators.  This
>> has proven to be key for the development of the Internet. I
>> don't  think that we want to change that. Even if we did I
>> don't think that the  discussion should take place solely in
>> some specialized routing working  groups.
>> 
>> -- Christian Huitema
>> 
>> 
>>> # 5. What are the valuable use cases/usage scenarios of APN?
>>> 
>>> 3)
>>> https://tools.ietf.org/html/draft-zhang-apn-acceleration-use
>>> case-00
>>> 
>>> 4)
>>> https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase-00
>>> 
>>> Use cases have also been presented and discussed during the
>>> APN side  meeting@IETF108. Please find the slides.
>>> 
>>> There have been some discussions on these use cases in the
>>> APN mailing  list as well. Please find the archives.
>>> 
>>> More interesting use cases are waiting to be explored.
>>> Please let us  know if you have any other use cases. Thank
>>> you!
>>> 
>>> Best regards,
>>> 
>>> Shuping
>>> 
>>> *From:*Lizhenbin
>>> preparation work, we summarized the key questions to be
>>> clarified for  APN which also were always asked. In fact in
>>> the past discussion and  the APN side meeting of IETF108,
>>> many of these questions were  discussed and clarified. Here
>>> we propose these questions together for  your convenience.
>>> 
>>> # 1. Which layer is for APN to do the application-aware work?
>>> 
>>> # 2. Does APN provide services within a limited-domain or
>>> # Internet?
>>> 
>>> # 3. Which area in IETF would the APN work fit better?
>>> 
>>> # 4. What is the relationship between APN and other attempts
>>> # in IETF's 
>>> history?
>>> 
>>> # 5. What are the valuable use cases/usage scenarios of APN?
>>> 
>>> # 6. Is the fine-granularity operations needed/desired in
>>> # the network?
>>> 
>>> # 7. Why not just use DSCP?
>>> 
>>> # 8. Does APN violate network neutrality?
>>> 
>>> # 9. Will APN raise security issues since application-aware
>>> # information 
>>> is carried in the APN packets?
>>> 
>>> # 10. Will APN raise privacy issues since application-aware
>>> # information 
>>> is carried in the APN packets?
>>> 
>>> Shuping Peng will send the detailed answers for these
>>> questions in the  mailing list in the following one or two
>>> weeks. The questions and  answers may be not only be sent in
>>> the APN mailing list, but also be  copied to the
>>> architecture discussion mailing list and the network  token
>>> mailing list for more cross-area feedback if necessary.
>>> 
>>> If you have any comments on these questions and answers, we
>>> can go on  to discuss through the mailing list.
>>> 
>>> Best Regards,
>>> 
>>> Zhenbin (Robin)
>>> 
>>> *From:*Apn [mailto:[email-masked]] *On Behalf Of
>>> *Lizhenbin *Sent:* Tuesday, August 18, 2020 7:22 PM
>>> Welcome to join the APN mailing list. We are glad to have
>>> more  discussion through the mailing list as the follow-up
>>> of the IETF108  APN side meeting.
>>> 
>>> In the process of APN work, many historic work items such as
>>> SPUD,  PLUS, etc. have been proposed. It has been tried to
>>> be clarified that  APN focuses
>>> 
>>> on the network layer and limited domains. Concerns on the
>>> security and  privacy issues also have been proposed many
>>> times about the work. It also
>>> 
>>> has been tried to be clarified that in the trustable limited
>>> domains  the security and privacy issues can be under
>>> control. These are the  reasons why APN
>>> 
>>> But because of too much historic work to be clarified and
>>> its  proposing the cross-area discussion for which
>>> RTG/APP/TSV/INT/SEC/IRTF  are involved, it is
>>> 
>>> necessary to have more discussion to clarify the scope and
>>> work items  for APN. We wish the mailing list would be
>>> helpful to the work and  promoting the
>>> 
>>> You can get yourself up to speed with our discussions so far
>>> by seeing  the materials at
>>> <https://github.com/APN-Community/>, especially the 
>>> materials
>>> 
>>> <https://github.com/APN-Community/IETF108-Side-Meeting-APN>.
>>> This link  also gives you pointers to
>>> 
>>> Over the next few weeks we will try to guide discussion by
>>> introducing  some questions for debate. But please also
>>> raise your own issues and  concerns
>>>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 22 Sep 2020 01:36:26 +0000

Hi Christian,

Thank you for your comments! Please find my responses in line.
Hope they also address the concerns of John and Joel.

From: Christian Huitema [mailto:[email-masked]]
Sent: Monday, September 21, 2020 2:54 PM
To: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [arch-d] Questions for APN: Q#5

Shuping,

I am reading your use cases, and my immediate reaction is that this developments should not be addressed solely in the routing or IP layers. You are proposing to enrich the network service proposed to transport and applications, which amounts to creating new APIs. Such works affects multiple layers, and should be coordinated between multiple layers.

[Shuping] The APN work to be focused on in the RTG Area is within a controlled limited network domain. To be more specific, when the information indicating application’s requirements is carried within the IP data packet header, APN aims to figure out how the network services can be provisioned according to the carried information, including traffic steering into and along an explicit traffic engineered network path as well as traffic monitoring, etc.. As to where the information is added, it is out of the working scope of the APN in the RTG Area.

Please refer to the first slide in this link which I have presented in APN side meeting @IETF108. It shows a clear scope of the APN work to be conducted in the RTG Area.

https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf

The presentation at the RTG WG @IETF108 can also be found here.

https://github.com/APN-Community/IETF108-RTGWG-APN

I also see that the description of application requirements is very thin. The drafts mention augmented reality and online games, and focus largely on latency requirements for these applications. The latency has two main components: delays in the wires, and queues in the routers. The APN draft for example mentions players of games using servers on another continent, and thus experiencing large latency. But that latency is largely due to the distance. That distance is not going to be magically reduced by smarter queue processing. The same is even more true for video conferencing or telepresence applications. I live near Seattle. If I want to talk to my mother in France, the bits have to be carried across America and the across the Atlantic ocean. No amount of smart routing will change that. Application developers are well aware of these issues, and have designed their applications in consequence.

[Shuping] Between A and B there are usually multiple paths and these paths can possess various characteristics, including delay and reliability, etc. The proper paths can then be selected according to the applications’ requirements and the traffic can be steered into the selected network path/tunnel/policy to guarantee their SLA requirements. To accelerate the latency-sensitive applications such as gaming, acceleration tunnels are usually built, especially for the oversea case because you can see the improvement more clearly. Please find more information in this draft https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00. Operators are actually building such acceleration tunnels themselves.

There is a lot of tension between Internet Architecture and the "application aware" proposal. The Internet was built on a fundamental decision to not be application aware. Instead, the routers carry packets of bits, independently of which application uses these bits. That way, new applications can constantly be invented, without requiring modifications in the network or permissions from the network operators. This has proven to be key for the development of the Internet. I don't think that we want to change that. Even if we did I don't think that the discussion should take place solely in some specialized routing working groups.

[Shuping] Again APN is aimed to work within a controlled and limited operators’ network domain not for Internet. Within this domain, network operators can provide network services (e.g. traffic steering and monitoring) according to the “application knowledge” carried in the data packets. This knowledge has already been used by most, if not all, operators since the introduction of traffic engineering mechanisms back in 90’s. APN is to automate these mechanisms, which will involve the work on the data plane encapsulations (i.e. IPv6, MPLS, VxLAN, etc.) and routing protocols extensions in the routing working groups.

Best regards,

Shuping

-- Christian Huitema

Best regards,
Shuping

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]><mailto:[email-masked]>
Subject: Question List for APN

Hi Folks,

Best Regards,
Zhenbin (Robin)

Hi Folks,

Best Regards,
Dan & Zhenbin

[email-masked]<mailto:[email-masked]>