Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc

Luca Muscariello <muscariello@ieee.org> Tue, 21 April 2020 14:50 UTC

Return-Path: <muscariello@ieee.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6533F3A0D92 for <icnrg@ietfa.amsl.com>; Tue, 21 Apr 2020 07:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
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 XydPtfbG4Wog for <icnrg@ietfa.amsl.com>; Tue, 21 Apr 2020 07:50:22 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3373A0851 for <icnrg@irtf.org>; Tue, 21 Apr 2020 07:50:10 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id x25so3889818wmc.0 for <icnrg@irtf.org>; Tue, 21 Apr 2020 07:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ji5E5GwbHZFF7UNIj92tv71dvg9yz6yJMXFSoKH6Dlg=; b=OhNdRAQ3S3qS3mI1R0EaffUB/yCeLr6/bDjZ4JKHz0o5jaqlBAtpH5V060BbTP+9ZL Ug27+P9esR3zhQ/V/m954NeCI+SAeD9tcWKd3EOCLCElNWEjeev40xog0WMUuQNrKblB eELb/sUmEx4sNQh5TUkjtkuPxIfEubfoch9T4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ji5E5GwbHZFF7UNIj92tv71dvg9yz6yJMXFSoKH6Dlg=; b=MF5f6Id2GeK6pKlHcf9EDJ3jTYKYmOo8xs2Q/xo5t9JtmT9irxGigvUF1DyeWDD1sD tLoXaJGza9MA0ZQyyWt63XUHcekcIG91Jy4JCPdNAwwjpKJ/3o97temaYHx61zhA6R2N CpAMSWPpM5DOSPEfgwWsEatnAF3qg4/0jZ8JONCLymMal4sGBZhBlBONqZ8SY8nxDgg7 BBsIPJ3KotJluCTqp7bk3UtXC2hZ253NeadeDos2ax0sbhhA9c+OmvWPDh+n1NFf7/Qf FEdBcuy8K6la9pdJ+S6wsb6sX4aIQj4dGOYykON1OHroveWleXqx6HK+ztW3KkCCIuqY pmWg==
X-Gm-Message-State: AGi0PuYwOigqEsV8UmuLqKRrhSv37BgvrWMrPeZ+adoNb9BW5qd4IKE3 fNerPx+Exf2TMJrRkggQvRy39aujcBV635WAfETUVDAJcrRLYw==
X-Google-Smtp-Source: APiQypKDGKZ+DLpt1xVOIKtB1cUrVr9gbMgdT5F6OcfxaiZzmr5hh622M/MXViwvHiT/uoFhmnNI81h3PFmsOOOOS4Q=
X-Received: by 2002:a1c:5683:: with SMTP id k125mr5103278wmb.17.1587480110635; Tue, 21 Apr 2020 07:41:50 -0700 (PDT)
MIME-Version: 1.0
References: <93E56749-73D1-4E34-81BB-B7F66DA30F7A@orandom.net> <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com> <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com> <CAH8sseQ5Zn1T8DH2YzZaRqc-3cVf3M47aveWOPvjg1Rov6Sq2A@mail.gmail.com> <0A3AFADD-B47E-45BA-A08A-94971C861C34@cablelabs.com> <CAH8sseS4NEi3RE360NUcxhUrbVW_vnDZGbRFv1L3U1WKivx68g@mail.gmail.com> <D2C9AF4E-9E25-48FD-9E0D-9214D397DEA2@dkutscher.net> <CAH8sseSXU1MsoahzCT+9g8Tc9nY-3oH+JTsafYqp4k3BDhrHrg@mail.gmail.com> <65AE7F1B-D307-478B-9B86-E36E863C0918@dkutscher.net> <CAH8sseT0HhzixQ+ofnpF+p+bhOV13z6Uj-tpVuzni_jgJPd9Cg@mail.gmail.com> <28EA075D-75B4-4046-88C4-1CA28458EDE3@dkutscher.net>
In-Reply-To: <28EA075D-75B4-4046-88C4-1CA28458EDE3@dkutscher.net>
From: Luca Muscariello <muscariello@ieee.org>
Date: Tue, 21 Apr 2020 16:41:39 +0200
Message-ID: <CAH8sseQv7evCHgCVQ3aBLnDotnVQ5suGjbip-yBRYmAMjB8Z9w@mail.gmail.com>
To: Dirk Kutscher <ietf@dkutscher.net>
Cc: Greg White <g.white@cablelabs.com>, ICNRG <icnrg@irtf.org>, "David R. Oran" <daveoran@orandom.net>
Content-Type: multipart/alternative; boundary="0000000000001546e605a3ce049e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/1qWGNqwlokZBPJC99RKn0J-MYRQ>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 14:50:40 -0000

On Tue, Apr 21, 2020 at 4:28 PM Dirk Kutscher <ietf@dkutscher.net> wrote:

> Hi Luca,
>
> > I fail to understand the definition of review in this list.
> > I made technical comments and got not a single technical answer.
> >
> > What's the point of having open reviews?
> > We can shutdown the discussion right away if this is what it is.
> >
> > I'm not interested in fake reviews to let documents go through w/o
> > an open technical debate.
>
> Not sure, I follow.
>
> Nobody has discouraged the technical review. I am hoping that the
> discussion continues. I was trying to explain the nature of this
> document in my view: documenting an experimental approach (which may not
> be the most desirable approach for all scenarios). I did not object to
> your other technical comments.
>

So let us focus on technical details.
So far I got none.

Let's avoid getting text published that may generate mockery from
people working on the 3GPP EPC.



>
> It's great to get the technical review. Unfortunately, in many groups,
> not just ICNRG, we don't have enough of it before we last-call things.
>

do not last call something that has no consensus yet.



>
> > this is the abstract:
> >
> > This document describes a protocol that enables tunneling of Internet
> >    Protocol traffic over a Content Centric Network (CCNx) or a Named
> >    Data Network (NDN).  The target use case for such a protocol is to
> >    provide an IP mobility plane for mobile networks that might
> > otherwise
> >    use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP)
> >    used by the Evolved Packet Core in LTE networks (LTE-EPC).  By
> >    leveraging the elegant, built-in support for mobility provided by
> >    CCNx or NDN, this protocol achieves performance on par with
> > LTE-EPC,
> >    equivalent efficiency, and substantially lower implementation and
> >    protocol complexity [Shannigrahi].  Furthermore, the use of
> > CCNx/NDN
> >    for this purpose paves the way for the deployment of ICN native
> >    applications on the mobile network.
> >
> > For me the above text is wrong with a marketing tone.
>
>
> Yes, I get it. This should be discussed.
>

The document should be cleaned up from this kind of text.
Who's going to buy into this?



>
> Cheers,
> Dirk
>
>
>
> >
> >
> > On Tue, Apr 21, 2020 at 3:26 PM Dirk Kutscher <ietf@dkutscher.net>
> > wrote:
> >
> >> Hi Luca,
> >>
> >>> The IPoC paper compares to GTP and concludes that it is no worse.
> >>> It makes a lot of sense to compare to GTP and I am not surprised
> >>> the authors made that comparison in the first place.
> >>
> >> Sure, it's helpful to explain how it compares to the GTP approach.
> >>
> >>> If a transition mechanism should be used it has to bring advantages
> >>> to
> >>> create incentives to switch to another solution.
> >>>
> >>> if, like you say Dirk, it is just about enabling applications to use
> >>> ICN, the mechanism has to let the application use ICN. Otherwise,
> >>> what's
> >>> for?
> >>>
> >>> For instance:
> >>>
> >>>
> >>> NDNizing Existing Applications: Research Issues and Experiences
> >>
> >> There are different ways to support applications, from adapting them
> >> to
> >> ICN (perhaps ideal) or just running them unmodified (this is what
> >> IPOC
> >> could enable).
> >>
> >>> The above work shows that to get benefits you have to work a lot
> >>> more on the namespace, otherwise if you just tie locators to names,
> >>> like in IPoC, you get something that is isomorphic to GTP.
> >>
> >> Clearly, more invasive changes would leverage ICN better. IPOC is
> >> just
> >> for those that you cannot change, i.e., it's transparent to the
> >> applications.
> >>
> >>> In IPoC there are no rewards and no incentives. But it takes
> >>> implicitly the risk of having CCNx in the stack of the client
> >>> and in the access/backhaul network. Who's gonna take that
> >>> risk and why?
> >>
> >> I think we all agree that there are better ways. Optimistically
> >> speaking, this would only be used for a short period of time -- until
> >> all relevant apps have been ICNified. :-)
> >>
> >> As a general comment: in a Research Group, we don't have to converge
> >> on
> >> one (possibly optimal) protocol. Instead, we can publish competing
> >> experimental specifications -- enabling more experiments which could
> >> inform later standards work (for example).
> >>
> >> Cheers,
> >> Dirk
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> In that sense, it would not have to show improvements over existing
> >>>> tunneling tech at all -- it just has to be good enough (and work
> >>>> correctly, of course).
> >>>>
> >>>
> >>>
> >>>
> >>>>
> >>>> It is clearly experimental and needs more testing (which may
> >>>> exhibit
> >>>> problems) -- that's why it's not proposed as a standard.
> >>>>
> >>>
> >>> It cannot be proposed as standard from the IRTF.
> >>>
> >>>
> >>>
> >>>>
> >>>> Cheers,
> >>>> Dirk
> >>>>
> >>>>
> >>>>>
> >>>>> On Tue, Apr 21, 2020 at 6:05 AM Greg White <g.white@cablelabs.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Luca,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Clearly you have a vested interest in hICN.  But, just as there
> >>>>>> are
> >>>>>> multiple technologies to enable the transition from IPv4 to IPv6,
> >>>>>> there is
> >>>>>> value in having multiple transition technologies for ICN.  IPoC
> >>>>>> fills
> >>>>>> a
> >>>>>> different niche from hICN, and it seems you’ve failed to
> >>>>>> understand
> >>>>>> that.
> >>>>>> Whereas hICN is a way to run limited ICN applications over a
> >>>>>> modified
> >>>>>> IPv6
> >>>>>> network, IPoC is a way to run **unmodified** IPv4/IPv6
> >>>>>> applications
> >>>>>> over
> >>>>>> a pure CCNx network.  Both approaches have their own
> >>>>>> applicability,
> >>>>>> and
> >>>>>> their own tradeoffs.  In the context of a mobile network, hICN
> >>>>>> does
> >>>>>> not
> >>>>>> provide a mobility solution for IP traffic, and thus requires the
> >>>>>> operator
> >>>>>> to deploy and maintain two parallel forwarding planes. On the
> >>>>>> other
> >>>>>> hand,
> >>>>>> IPoC allows the operator to eliminate IP routing and legacy
> >>>>>> mobility
> >>>>>> mechanisms from the mobile core and support all services over
> >>>>>> CCNx.
> >>>>>> Yes,
> >>>>>> IPoC assumes a bigger first step (deployment of CCNx), but it
> >>>>>> makes
> >>>>>> taking
> >>>>>> that step easier, and once taken, native CCNx applications can be
> >>>>>> deployed
> >>>>>> getting the advantages of the full CCNx architecture.
> >>>>>> Additionally,
> >>>>>> other
> >>>>>> transition technologies (like HTTP->CCN proxies) can be deployed
> >>>>>> to
> >>>>>> enable
> >>>>>> certain applications to get more of the CCNx-native benefits.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -Greg
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> *From: *Luca Muscariello <muscariello@ieee.org>
> >>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM
> >>>>>> *To: *Greg White <g.white@CableLabs.com>
> >>>>>> *Cc: *"Dave Oran (oran)" <daveoran@orandom.net>, ICNRG
> >>>>>> <icnrg@irtf.org>
> >>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi Greg,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> comments in line.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Apr 16, 2020 at 12:50 AM Greg White
> >>>>>> <g.white@cablelabs.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Luca,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thanks for the review and for the questions and comments.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On your first question, the IPoC naming convention and CCNx
> >>>>>> routing
> >>>>>> mechanism ensure that the IPoC client remains in communication
> >>>>>> with
> >>>>>> the
> >>>>>> IPoC gateway that provides reachability to the client’s
> >>>>>> assigned
> >>>>>> IP
> >>>>>> address
> >>>>>> by other devices on the IP network.  If the IPoC gateway becomes
> >>>>>> unreachable due to a network attachment change (e.g. if the
> >>>>>> client
> >>>>>> leaves
> >>>>>> the current IPoC network and joins another), it would need to
> >>>>>> establish
> >>>>>> communication with a new IPoC gateway in the new network, using
> >>>>>> the
> >>>>>> mechanism described in Section 8.  It would thus be in a
> >>>>>> different
> >>>>>> subnet,
> >>>>>> with a different IP address.   It would also be possible for a
> >>>>>> client
> >>>>>> to
> >>>>>> periodically run the Section 8 mechanism in order to determine
> >>>>>> whether it
> >>>>>> was connected to the topologically nearest gateway.  If it finds
> >>>>>> a
> >>>>>> nearer
> >>>>>> gateway (and thus gets a new IP address) it could begin
> >>>>>> transitioning
> >>>>>> new
> >>>>>> IP connections to the new IP address, while allowing existing
> >>>>>> connections
> >>>>>> that used the previous IP address to complete.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The IPoC GW is very similar to what we do in enterprise networks
> >>>>>> with
> >>>>>> LISP
> >>>>>> to optimize Wi-Fi mobility management and more. Even if this
> >>>>>> happens
> >>>>>> from
> >>>>>> the AP to the switch it does not change much.
> >>>>>>
> >>>>>> Similarly from the eNB to the SGW using GTP tunneling. IPoC does
> >>>>>> not
> >>>>>> provide any advantage w.r.t. LISP or GTP which both rely on IP
> >>>>>> only.
> >>>>>> I'd
> >>>>>> say that in this case I only see the disadvantages of IPoC as it
> >>>>>> makes the
> >>>>>> assumption that CCNx is the backhaul.
> >>>>>>
> >>>>>> The fact that IPoC binds IP addresses to the CCNx namespace
> >>>>>> destroys
> >>>>>> all
> >>>>>> good features of CCNx which is used with hands and legs tied.
> >>>>>>
> >>>>>> In summary: No many-to-many communications, weak security
> >>>>>> properties,
> >>>>>> inferior mobility wrt the state of the art and also no incentives
> >>>>>> to
> >>>>>> move
> >>>>>> from the current solutions to this one.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Correct me if I am misunderstanding, but questions 2 & 4 seem to
> >>>>>> be
> >>>>>> essentially the same question, i.e.:  is it expected that
> >>>>>> Interests
> >>>>>> and
> >>>>>> Content Objects are all signed, and if so, what are the
> >>>>>> performance
> >>>>>> implications?
> >>>>>>
> >>>>>> As you noted, section 14 mentions signing of Interests and
> >>>>>> Content
> >>>>>> Objects, and implies that it is optional.  It is in fact
> >>>>>> optional.
> >>>>>> As
> >>>>>> section 14 discusses, the protocol is intended for use within a
> >>>>>> managed,
> >>>>>> CCNx-based, mobile core network where endpoint authentication and
> >>>>>> authorization is managed via existing means. Interest and CO
> >>>>>> signing
> >>>>>> would
> >>>>>> certainly add computational complexity perhaps on the order of
> >>>>>> the
> >>>>>> complexity associated with encrypted tunnels in IP, so the
> >>>>>> benefits
> >>>>>> of
> >>>>>> doing so would need to be weighed against the scalability
> >>>>>> impacts.
> >>>>>> I’ll
> >>>>>> add an explicit mention in Section 4 that signing is optional.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Q2 and Q4 are distinct questions related to the usage of signed
> >>>>>> interest
> >>>>>> systematically, i.e. 100% of the interests.
> >>>>>>
> >>>>>> Q2: This is about the fact that interests are signed because they
> >>>>>> carry
> >>>>>> payload. So local flow balance is gone and this has performance
> >>>>>> implications in terms of congestion management, loss recovery AND
> >>>>>> mobility.
> >>>>>> All gone. This is what Q2 is about. Sorry for being so compact,
> >>>>>> but
> >>>>>> I'm
> >>>>>> assuming some terminology is well understood in this list.
> >>>>>>
> >>>>>> Also what are the security implications of signing every
> >>>>>> Interest?
> >>>>>> It
> >>>>>> looks very similar to an IPSEC GW with all the certificate
> >>>>>> business.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Q4: This is about the computation cost. In the hICN project we're
> >>>>>> spending
> >>>>>> a lot of time to bring performance of a single transfer beyond
> >>>>>> 10Gbps. All
> >>>>>> forms of optimizations are required: manifests, hash computation
> >>>>>> offloading, software/hardware tricks and many more. This is not a
> >>>>>> negligible point. In practice one would be tempted to disable
> >>>>>> signatures.
> >>>>>> This is worse.
> >>>>>>
> >>>>>> The security implication of using non authenticated end-points
> >>>>>> are
> >>>>>> very
> >>>>>> well known even in a managed network. Managed networks carry
> >>>>>> customer'
> >>>>>> traffic and security is MUST, not an option.
> >>>>>>
> >>>>>> Current solid deployments of LISP in enterprise networks make use
> >>>>>> of
> >>>>>> authentication, GTP tunnels too in the EPC backhaul. Tunnel
> >>>>>> confidentiality
> >>>>>> may be an option but authentication is not.
> >>>>>>
> >>>>>> It is an option in EPC for 4G but for 5G UPC confidentiality is
> >>>>>> mandatory..
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On question 3, there are two implementations that have been made
> >>>>>> available.  One was built on the PARC Metis libraries,
> >>>>>> experimental
> >>>>>> results
> >>>>>> using this implementation were shared at the November 13, 2016
> >>>>>> ICNRG
> >>>>>> Interim Meeting, and it was mentioned as well at the March 20,
> >>>>>> 2018
> >>>>>> and
> >>>>>> July 21, 2018 ICNRG meeting where IPoC was presented.  While this
> >>>>>> implementation is not currently being maintained, the code is
> >>>>>> available.
> >>>>>> The second implementation was built in ndnSim, and is available
> >>>>>> on
> >>>>>> GitHub..
> >>>>>> Experimental results and a link to the repo can be found in the
> >>>>>> paper
> >>>>>> listed in the Informative References of the IPoC draft.  That
> >>>>>> paper
> >>>>>> discusses the benefits compared to the existing GTP tunneling
> >>>>>> mechanisms
> >>>>>> used in LTE-EPC.  I’m not sure why you are questioning whether
> >>>>>> CCNx
> >>>>>> consumer mobility still holds.  This protocol makes use of CCNx
> >>>>>> stateful
> >>>>>> forwarding directly, and is designed precisely to make use of
> >>>>>> that
> >>>>>> feature.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I read the paper that describes and evaluates IPoC and compares
> >>>>>> to
> >>>>>> GTP.
> >>>>>> That's the whole point. The conclusion of the paper is that IPoC
> >>>>>> is
> >>>>>> no
> >>>>>> worse than GTP. Which is my whole point.
> >>>>>>
> >>>>>> What is the reason to disrupt a technology (GTP) and replace it
> >>>>>> with
> >>>>>> something that is no worse?
> >>>>>>
> >>>>>> As soon as the IPoC namespace is tied to the IP addresses of the
> >>>>>> end-points of the tunnel, IPoC becomes isomorphic to GTP or any
> >>>>>> tunneling
> >>>>>> protocol making use of locators.
> >>>>>>
> >>>>>> So it is no worse than any of those protocols. This does not look
> >>>>>> like a
> >>>>>> compelling reason to change the transport infrastructure. Worse,
> >>>>>> it
> >>>>>> looks
> >>>>>> like an argument NOT to move towards ICN.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I am surprised that this draft has moved to last call with this
> >>>>>> implicit
> >>>>>> message.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I did not pay attention to all drafts moving forward in this RG
> >>>>>> because
> >>>>>> there are so many of them being pushed by the chairs, but I hope
> >>>>>> we
> >>>>>> pay
> >>>>>> more attention to "shoot-yourself-in-the-foot" messages.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best
> >>>>>>
> >>>>>> Luca
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Best Regards,
> >>>>>>
> >>>>>> Greg
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> *From: *icnrg <icnrg-bounces@irtf.org> on behalf of Luca
> >>>>>> Muscariello
> >>>>>> <
> >>>>>> muscariello@ieee.org>
> >>>>>> *Date: *Monday, March 23, 2020 at 2:01 AM
> >>>>>> *To: *"Dave Oran (oran)" <daveoran@orandom.net>
> >>>>>> *Cc: *ICNRG <icnrg@irtf.org>
> >>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I went through the draft and I have a few comments and some
> >>>>>> questions.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 1 how does this system work when IP addresses at local interfaces
> >>>>>> change?
> >>>>>>
> >>>>>>   My question is about both the underlying mechanics and also the
> >>>>>> performance
> >>>>>>
> >>>>>>   of the system in such cases.
> >>>>>>
> >>>>>> 2 What are the implications of using signed Interests in this
> >>>>>> way?
> >>>>>> I
> >>>>>> mean
> >>>>>>
> >>>>>>   100% of the Interests are signed in the tunneling scheme. My
> >>>>>> question is
> >>>>>> both
> >>>>>>
> >>>>>>   in terms of security and performance. And with performance I
> >>>>>> mean
> >>>>>> both
> >>>>>>
> >>>>>>   mobility and local flow balance.
> >>>>>>
> >>>>>> 3 Is there any reality check and running code of this scheme?
> >>>>>>
> >>>>>>   Every Internet draft comes with a security section but not a
> >>>>>> cost
> >>>>>> section
> >>>>>>
> >>>>>>   however it is unclear in this specific case, what are the
> >>>>>> benefits
> >>>>>> of
> >>>>>> this
> >>>>>>
> >>>>>>   scheme and if one would need it compared to existing tunneling
> >>>>>> technologies.
> >>>>>>
> >>>>>>   The alleged benefits of CCNx in terms of mobility are never
> >>>>>> spelled
> >>>>>> out
> >>>>>> in the
> >>>>>>
> >>>>>>   draft but it is unclear if any mobility benefit still holds
> >>>>>> using
> >>>>>> this
> >>>>>> technique.
> >>>>>>
> >>>>>> 4 The cost of signing every packet is significant and would
> >>>>>> probably
> >>>>>> kill
> >>>>>>
> >>>>>>   the performance of the tunnel. In the last section the authors
> >>>>>> seem
> >>>>>> to
> >>>>>>
> >>>>>>   consider interest/data signatures as optional. Can this be
> >>>>>> clarified and
> >>>>>> spelled
> >>>>>>
> >>>>>>   out clearly? Is the intent to use the tunnel w/o signatures?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Thank
> >>>>>>
> >>>>>> Best
> >>>>>>
> >>>>>> Luca
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Mar 20, 2020 at 2:51 PM David R. Oran
> >>>>>> <daveoran@orandom.net>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hello ICNRG,
> >>>>>>
> >>>>>> This is a last call for comments on draft-irtf-icnrg-IPOC
> >>>>>> (Internet
> >>>>>> Protocol Tunneling over Content Centric Mobile Networks).
> >>>>>>
> >>>>>> We want to publish this as an Experimental RFC. Please read it
> >>>>>> and
> >>>>>> let
> >>>>>> us know if you think there are issues. The last call ends on
> >>>>>> April
> >>>>>> 15,
> >>>>>> i.e., 3 weeks from today.
> >>>>>>
> >>>>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-ipoc/
> >>>>>>
> >>>>>> Abstract
> >>>>>>
> >>>>>>     This document describes a protocol that enables tunneling of
> >>>>>> Internet
> >>>>>>     Protocol traffic over a Content Centric Network (CCNx) or a
> >>>>>> Named
> >>>>>>     Data Network (NDN).  The target use case for such a protocol
> >>>>>> is
> >>>>>> to
> >>>>>>     provide an IP mobility plane for mobile networks that might
> >>>>>> otherwise
> >>>>>>     use IP-over-IP tunneling, such as the GPRS Tunneling Protocol
> >>>>>> (GTP)
> >>>>>>     used by the Evolved Packet Core in LTE networks (LTE-EPC).
> >>>>>> By
> >>>>>>     leveraging the elegant, built-in support for mobility
> >>>>>> provided
> >>>>>> by
> >>>>>>     CCNx or NDN, this protocol achieves performance on par with
> >>>>>> LTE-EPC,
> >>>>>>     equivalent efficiency, and substantially lower implementation
> >>>>>> and
> >>>>>>     protocol complexity [Shannigrahi].  Furthermore, the use of
> >>>>>> CCNx/NDN
> >>>>>>     for this purpose paves the way for the deployment of ICN
> >>>>>> native
> >>>>>>     applications on the mobile network.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> ICNRG chairs
> >>>>>>
> >>>>>>
> >>>>>> DaveO
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> icnrg mailing list
> >>>>>> icnrg@irtf.org
> >>>>>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>> _______________________________________________
> >>>>> icnrg mailing list
> >>>>> icnrg@irtf.org
> >>>>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>
> >>
> >>
> >>> _______________________________________________
> >>> icnrg mailing list
> >>> icnrg@irtf.org
> >>> https://www.irtf.org/mailman/listinfo/icnrg
> >>
>
>
>