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

[Luca Muscariello <[e-mail]>]

On Tue, Apr 21, 2020 at 4:28 PM Dirk Kutscher <[e-mail]> 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 <[e-mail]>
> > 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 <[e-mail]>
> >>>>> 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 <[e-mail]>
> >>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM
> >>>>>> *To: *Greg White <[e-mail]>
> >>>>>> *Cc: *"Dave Oran (oran)" <[e-mail]>, ICNRG
> >>>>>> <[e-mail]>
> >>>>>> *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
> >>>>>> <[e-mail]>
> >>>>>> 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 <[e-mail]> on behalf of Luca
> >>>>>> Muscariello
> >>>>>> <
> >>>>>> [e-mail]>
> >>>>>> *Date: *Monday, March 23, 2020 at 2:01 AM
> >>>>>> *To: *"Dave Oran (oran)" <[e-mail]>
> >>>>>> *Cc: *ICNRG <[e-mail]>
> >>>>>> *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
> >>>>>> <[e-mail]>
> >>>>>> 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
> >>>>>> [e-mail]
> >>>>>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>> _______________________________________________
> >>>>> icnrg mailing list
> >>>>> [e-mail]
> >>>>> https://www.irtf.org/mailman/listinfo/icnrg
> >>>>
> >>
> >>
> >>> _______________________________________________
> >>> icnrg mailing list
> >>> [e-mail]
> >>> https://www.irtf.org/mailman/listinfo/icnrg
> >>
>
>
>