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

John C Klensin <john-ietf@jck.com> Mon, 21 September 2020 15:31 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904083A0813; Mon, 21 Sep 2020 08:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMGqZcgdLDbH; Mon, 21 Sep 2020 08:31:25 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2463A0812; Mon, 21 Sep 2020 08:31:25 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kKNmf-000L6I-0j; Mon, 21 Sep 2020 11:31:17 -0400
Date: Mon, 21 Sep 2020 11:31:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Christian Huitema <huitema@huitema.net>, "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, apn@ietf.org
cc: network-tokens@ietf.org, architecture-discuss@iab.org
Message-ID: <C710EB21B832EE8148DC5D17@PSB>
In-Reply-To: <373e0e0a-a57a-ff28-6b71-42064bea1500@joelhalpern.com>
References: <4278D47A901B3041A737953BAA078ADE193E1DFF@DGGEML532-MBX.china.huawei.com> <d8db4777-b156-cf96-b367-7a9db613c2ff@huitema.net> <373e0e0a-a57a-ff28-6b71-42064bea1500@joelhalpern.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/EFe2cbqzZ5ydc6q39xRM1QzHp50>
Subject: Re: [Apn] [arch-d] Questions for APN: Q#5
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 15:31:28 -0000

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"
<jmh@joelhalpern.com> 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:* apn@ietf.org
>>> *Cc:* Pengshuping (Peng Shuping) <pengshuping@huawei.com>
>>> *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:apn-bounces@ietf.org] *On Behalf Of
>>> *Lizhenbin *Sent:* Tuesday, August 18, 2020 7:22 PM
>>> *To:* apn@ietf.org <mailto:apn@ietf.org>
>>> *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
>>> Architecture-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss