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

From: Greg White <[email-masked]>
Date: Wed, 15 Apr 2020 22:50:50 +0000

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.

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.

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.

Best Regards,
Greg

From: icnrg <[email-masked]> on behalf of Luca Muscariello <[email-masked]>
Date: Monday, March 23, 2020 at 2:01 AM
To: "Dave Oran (oran)" <[email-masked]>
Cc: ICNRG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Luca Muscariello <[email-masked]>
Date: Thu, 16 Apr 2020 09:29:14 +0200

Hi Greg,

comments in line.

On Thu, Apr 16, 2020 at 12:50 AM Greg White <[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Luca Muscariello <
> [email-masked]>
> *Date: *Monday, March 23, 2020 at 2:01 AM
> *To: *"Dave Oran (oran)" <[email-masked]>
> *Cc: *ICNRG <[email-masked]>
> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
>
>
>
> Hi
>
>
>
> On Fri, Mar 20, 2020 at 2:51 PM David R. Oran <[email-masked]>
> wrote:
>
> Hello ICNRG,
>
> [email-masked]

---

From: Greg White <[email-masked]>
Date: Tue, 21 Apr 2020 04:05:19 +0000

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 <[email-masked]>
Date: Thursday, April 16, 2020 at 1:29 AM
To: Greg White <[email-masked]>
Cc: "Dave Oran (oran)" <[email-masked]>, ICNRG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Luca,

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.

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.

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 <[email-masked]<mailto:[email-masked]>> on behalf of Luca Muscariello <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 23, 2020 at 2:01 AM
To: "Dave Oran (oran)" <[email-masked]<mailto:[email-masked]>>
Cc: ICNRG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc

Hi

Thank
Best
Luca

Abstract

Best regards,
ICNRG chairs

DaveO

---

From: Luca Muscariello <[email-masked]>
Date: Tue, 21 Apr 2020 09:54:00 +0200

Greg,

I think you did not answer any of my questions.
Considering hICN, this is a whole different thread and out of scope for now.
BTW, the current hICN codebase supports IPv4 as well in addition to IPv6.

If you can please go back to my specific questions  that would help make
progress.
Maybe you can start from the question related to mobility, namely:

- IPoC makes early bindings between the IP address of the interface (inner
header in the tunnel)
  and the ccnx name, which contains the IP address in a specified encoding
(defined in the I-D).
  The CCNx header is the outer header in the tunnel. The ccnx://ipoc is
also a locator for the GW.
  It looks to me that location independence is gone. Take the example of
LISP, using xTR as GW,
  and the EPC using the SGW as GW, it looks that GTP and IPoC are
equivalent. A change in IP address
  at the client side, will reset the tunnel. Also, even if not mentioned in
the draft, you may probably
  have several IPoC GWs and so several ccnx://ipoc locators one per IPoC
GW. Just like SGW in EPC.
  If all above is correct, what does IPoC bring as a benefit?

- security
- performance

While I do not fail to see the difference between hICN and IPoC, I do fail
to see ANY difference between
IPoC and GTP in EPC. Also, IPoC MUST compare to GTP as they are both
tunneling protocols.
And let us be clear, IMHO, anything today should compare to the current
state of the art: LISP in enterprise networks
and GTP in cellular networks, deployed globally. Deployment incentives
should consider cost/benefits to move
from the starting point (LISP/EPC) to any new technology. I fail to see
compelling arguments to move away
from the current model in favor of IPoC.

Can you please answer these specific questions? If they are not clear,
please just say it.

Luca

On Tue, Apr 21, 2020 at 6:05 AM Greg White <[email-masked]> 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 <[email-masked]>
> *Date: *Thursday, April 16, 2020 at 1:29 AM
> *To: *Greg White <[email-masked]>
> *Cc: *"Dave Oran (oran)" <[email-masked]>, ICNRG <[email-masked]>
> Also what are the security implications of signing every Interest? It
> looks very similar to an IPSEC GW with all the certificate business.
>
>
>
> 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.
>

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 21 Apr 2020 10:15:44 +0200

Thanks for the discussion and these comments, Luca.

Just on this particular statement:

> from the starting point (LISP/EPC) to any new technology.

To be fair, IPOC is not proposed as a solution that improves over LISP, 
GTP etc. I see it as a transition mechanism that might of interest once 
you have converted to ICN and still want to support legacy traffic.

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.

Cheers,
Dirk

>> It is an option in EPC for 4G but for 5G UPC confidentiality is 
>> mandatory..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The second implementation was built in ndnSim, and is available on 
>> GitHub..
>>   100% of the Interests are signed in the tunneling scheme. My 
>> question is
>> both
>>
>>   however it is unclear in this specific case, what are the benefits 
>> of
>> this
>>
>>   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.
>>
>>   consider interest/data signatures as optional. Can this be 
>> clarified and
>> spelled
>>

---

From: Luca Muscariello <[email-masked]>
Date: Tue, 21 Apr 2020 10:44:14 +0200

> you have converted to ICN and still want to support legacy traffic.

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.

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
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final54.pdf>

Teng Liang *(The University of Arizona)*, Ju Pan *(The University of
Arizona)*,

Beichuan Zhang *(The University of Arizona)*

https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final54.pdf

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.

The solution above, does provide incentives for an application
to be NDNized. It comes with an effort of course that is tied
to the chain: incentives, risks, rewards.

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?

> problems) -- that's why it's not proposed as a standard.

It cannot be proposed as standard from the IRTF.

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 21 Apr 2020 15:26:01 +0200

Hi Luca,

> the authors made that comparison in the first place.

Sure, it's helpful to explain how it compares to the GTP approach.

> 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).

> 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.

> and in the access/backhaul network. Who's gonna take that

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

>>>> 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
>>>> getting the advantages of the full CCNx architecture.  
>>>> Additionally,
>>>> other
>>>> IPoC gateway that provides reachability to the client’s assigned 
>>>> IP
>>>> address
>>>> with a different IP address.   It would also be possible for a 
>>>> client
>>>> to
>>>> gateway (and thus gets a new IP address) it could begin 
>>>> transitioning
>>>> new
>>>> 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
>>>> provide any advantage w.r.t. LISP or GTP which both rely on IP 
>>>> only.
>>>> I'd
>>>> The fact that IPoC binds IP addresses to the CCNx namespace 
>>>> destroys
>>>> all
>>>> inferior mobility wrt the state of the art and also no incentives 
>>>> to
>>>> move
>>>> authorization is managed via existing means. Interest and CO 
>>>> signing
>>>> would
>>>> *From: *icnrg <[email-masked]> on behalf of Luca 
>>>> Muscariello
>>>> <
>>>> [email-masked]>
>>>> 2 What are the implications of using signed Interests in this way? 
>>>> I
>>>> mean
>>>>
>>>> 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
>>>>

---

From: Luca Muscariello <[email-masked]>
Date: Tue, 21 Apr 2020 15:43:05 +0200

Dirk,

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.

this is the abstract:

This document describes a protocol that enables tunneling of Internet
   provide an IP mobility plane for mobile networks that might otherwise

For me the above text is wrong with a marketing tone.

---

From: "Dirk Kutscher" <[email-masked]>
Date: Tue, 21 Apr 2020 16:28:40 +0200

Hi Luca,

> 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.

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.

> For me the above text is wrong with a marketing tone.

Yes, I get it. This should be discussed.

Cheers,
Dirk

>>>>>> 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
>>>>>> to deploy and maintain two parallel forwarding planes. On the 
>>>>>> other
>>>>>> hand,
>>>>>> 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
>>>>>> transition technologies (like HTTP->CCN proxies) can be deployed 
>>>>>> to
>>>>>> enable
>>>>>> On Thu, Apr 16, 2020 at 12:50 AM Greg White 
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Luca,
>>>>>>
>>>>>>
>>>>>>
>>>>>> mechanism ensure that the IPoC client remains in communication 
>>>>>> with
>>>>>> the
>>>>>> unreachable due to a network attachment change (e.g. if the 
>>>>>> client
>>>>>> leaves
>>>>>> mechanism described in Section 8.  It would thus be in a 
>>>>>> different
>>>>>> subnet,
>>>>>> was connected to the topologically nearest gateway.  If it finds 
>>>>>> a
>>>>>> nearer
>>>>>> essentially the same question, i.e.:  is it expected that 
>>>>>> Interests
>>>>>> and
>>>>>> Objects, and implies that it is optional.  It is in fact 
>>>>>> optional.
>>>>>> As
>>>>>> complexity associated with encrypted tunnels in IP, so the 
>>>>>> benefits
>>>>>> of
>>>>>> doing so would need to be weighed against the scalability 
>>>>>> impacts.
>>>>>> I’ll
>>>>>> All gone. This is what Q2 is about. Sorry for being so compact, 
>>>>>> but
>>>>>> I'm
>>>>>> Also what are the security implications of signing every 
>>>>>> Interest?
>>>>>> It
>>>>>> The security implication of using non authenticated end-points 
>>>>>> are
>>>>>> very
>>>>>> available.  One was built on the PARC Metis libraries, 
>>>>>> experimental
>>>>>> results
>>>>>> Interim Meeting, and it was mentioned as well at the March 20, 
>>>>>> 2018
>>>>>> and
>>>>>> 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
>>>>>> compelling reason to change the transport infrastructure. Worse, 
>>>>>> it
>>>>>> looks
>>>>>> there are so many of them being pushed by the chairs, but I hope 
>>>>>> we
>>>>>> pay
>>>>>>   in terms of security and performance. And with performance I 
>>>>>> mean
>>>>>> both
>>>>>>
>>>>>>   Every Internet draft comes with a security section but not a 
>>>>>> cost
>>>>>> section
>>>>>>
>>>>>> 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,
>>>>>>     Data Network (NDN).  The target use case for such a protocol 
>>>>>> is
>>>>>> to
>>>>>>     leveraging the elegant, built-in support for mobility 
>>>>>> provided
>>>>>> by

---

From: Luca Muscariello <[email-masked]>
Date: Tue, 21 Apr 2020 16:41:39 +0200

> 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.

> 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.

> 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?

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 22 Apr 2020 10:55:00 -0400

Not to derail the discussion, but one clarification on process. Last 
Call is both for technical review and to assess consensus or the lack 
thereof. As chair I have no problem with Last-calling documents in order 
to achieve both goals. Sometimes last call works as a forcing function 
to produce good technical review and foster discussion that did not 
happen while a document languished as an RG work item with little or no 
feedback.

So, I’d make the observation that I think the process is working in 
this case. We have a solid, comprehensive technical review and a 
discussion with the authors on that. It would be helpful if more ICNRG 
participants would also review IPOC and weigh in on these and possibly 
other issues that get raised.

Lastly, the IRTF doesn’t work by consensus formally, so let’s focus 
on the technical questions. The document won’t have passed last call 
until we get better understanding of whether the technical questions are 
of a nature that would argue against publication.

DaveO.

On 21 Apr 2020, at 10:41, Luca Muscariello wrote:

>>>>> If a transition mechanism should be used it has to bring 
>>>>> advantages
>>>>> to
>>>> There are different ways to support applications, from adapting 
>>>> them
>>>> to
>>>> As a general comment: in a Research Group, we don't have to 
>>>> converge
>>>> on
>>>>>>> On Tue, Apr 21, 2020 at 6:05 AM Greg White 
>>>>>>> <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Luca,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> multiple technologies to enable the transition from IPv4 to 
>>>>>>>> IPv6,
>>>>>>>> there is
>>>>>>>> provide a mobility solution for IP traffic, and thus requires 
>>>>>>>> the
>>>>>>>> operator
>>>>>>>> that step easier, and once taken, native CCNx applications can 
>>>>>>>> be
>>>>>>>> deployed
>>>>>>>> Similarly from the eNB to the SGW using GTP tunneling. IPoC 
>>>>>>>> does
>>>>>>>> not
>>>>>>>> say that in this case I only see the disadvantages of IPoC as 
>>>>>>>> it
>>>>>>>> makes the
>>>>>>>> Correct me if I am misunderstanding, but questions 2 & 4 seem 
>>>>>>>> to
>>>>>>>> be
>>>>>>>> Q2: This is about the fact that interests are signed because 
>>>>>>>> they
>>>>>>>> carry
>>>>>>>> implications in terms of congestion management, loss recovery 
>>>>>>>> AND
>>>>>>>> mobility.
>>>>>>>> Q4: This is about the computation cost. In the hICN project 
>>>>>>>> we're
>>>>>>>> spending
>>>>>>>> Current solid deployments of LISP in enterprise networks make 
>>>>>>>> use
>>>>>>>> of
>>>>>>>> used in LTE-EPC.  I’m not sure why you are questioning 
>>>>>>>> whether
>>>>>>>> CCNx
>>>>>>>> So it is no worse than any of those protocols. This does not 
>>>>>>>> look
>>>>>>>> like a
>>>>>>>> 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
>>>>>>>>
>>>>>>>>   scheme and if one would need it compared to existing 
>>>>>>>> tunneling
>>>>>>>> technologies.
>>>>>>>>
>>>>>>>>     use IP-over-IP tunneling, such as the GPRS Tunneling 
>>>>>>>> Protocol
>>>>>>>> (GTP)
>>>>>>>>     equivalent efficiency, and substantially lower 
>>>>>>>> implementation
>>>>>>>> and

DaveO