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

[John C Klensin <[e-mail]>]

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"
<[e-mail]> wrote:

> Well said.  Thank you Christian.
> Joel
> 
> On 9/21/2020 2:54 AM, Christian Huitema wrote:
>> 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:
>>> 
>>> 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-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.
>>> 
>>> 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-fQP4LRpe6yj3lJBs
>>> aRxTVcWHA/
>>> 
>>> https://mailarchive.ietf.org/arch/msg/apn/MCVuBYa7jgtJsIDEpb
>>> GTZ0U8Bvg/
>>> 
>>> https://mailarchive.ietf.org/arch/msg/apn/c-fQP4LRpe6yj3lJBs
>>> aRxTVcWHA/
>>> 
>>> 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:* [e-mail]
>>> *Cc:* Pengshuping (Peng Shuping) <[e-mail]>
>>> *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:[e-mail]] *On Behalf Of
>>> *Lizhenbin *Sent:* Tuesday, August 18, 2020 7:22 PM
>>> *To:* [e-mail] <mailto:[e-mail]>
>>> *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
>>> 
>>> 
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss