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

[Dirk Kutscher <[e-mail]>]

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