Subject: [icnrg] Comments on draft-suthar-icnrg-icn-lte-4g-01

From: "David Oran" <[email-masked]>
Date: Tue, 13 Jun 2017 10:27:40 -0400

I reviewed “Native Deployment of ICN in LTE, 4G Mobile Networks” 
(https://datatracker.ietf.org/doc/draft-suthar-icnrg-icn-lte-4g/) and 
have the following comments. These comments are with <Chair Hat Off>

####General Comments

This is a very good start to sorting through the complexities of 
integrating ICN into cellular wireless networks. It covers a lot of 
ground and can form the basis to guide further work, especially in 
directing efforts into parts of the design space most likely to work 
well technically, and to be practically deployable on the kinds of 
mobile edge and packet core equipment providers are likely to employ.

It does need a lot of work and further input from the community. To this 
end I think it would be useful to adopt this as an official work item 
for ICNRG. Among the overall things that need to be addressed are:

- The exposition is not clean in many places and there are language 
problems like missing articles and infelicitous working. A copy-edit 
review (sooner rather than later) would make future review and 
improvements much easier for the community.

- While much of the tutorial material is quite useful, especially on the 
relevant protocol designs and architectural constraints of 4G/LTE/5G 
networks, some of the material, notably the ICN tutorial material, is 
unnecessary and distracting, as the target audience is ICNRG, whose 
participants already know this stuff. An alternative way to cut this is 
to separate the document either into three semi-independent sections or 
three separate documents, along the lines of:
	- ICN tutorial material for 3GPP-knowledgeable people
	- 3GPP/LTE tutorial material of ICN-knowledgeable people
	- the existing material in the document on deployment scenarios, 
requirements, and options.

- The terminology section, while useful, needs to expand all the 
acronyms. As above, either restructure to have more tutorial material on 
LTE for the ICN community, or come out and say something like “you 
won’t understand the rest of this document unless you have more than 
passing familiarity with the technology and protocols of cellular 
networks. Go read [references a, b, c,] first and then come back after 
your head recovers from its journey through 3GPP-land”

- The document concentrates too much on content distribution as the 
poster-child use case. An unfortunate consequence of this is to 
reinforce a number of assumptions about caching that may not hold in 
practice. I suggest that a global editing pass be done to change most 
discussion of “content” to just talk about “data” and to 
describe ICN use cases in a more balanced way. For example, IoT is given 
short shrift, personal content on user devices is not considered, etc. 
Rather than wade too deeply into ICN use cases and applications, perhaps 
it’s best to simply cut down these discussions and simply focus on how 
to make ICN work well on these networks assuming you know little to 
nothing about the applications and use cases.

- I’m not sure this document needs to discuss privacy, but given the 
historical misconceptions of the mobile operators about their role in 
preserving/violating privacy in the IP world perhaps we need a 
discussion here about ICN. This interacts obviously with things like 
DPI, Lawful Intercept, and cache exploration for commercial gain. I 
don’t have a strong recommendation here other than to be sure your 
security considerations section (which you need to write) has some words 
about privacy.

####Detailed comments
#####Abstract
- Noting in here depends on whether spectrum is licensed or unlicensed. 
You appear to tie unlicensed to WiFi and licensed to LTE, which is 
breaking down with things like LTE-U. Delete this.

- There’s some very confusing wording here starting at “by embedding 
ICN into 3GPP protocol stack at IP datagram or replacing IP for non-IP 
datagrams”.

#####1 Introduction

- OSPF, ISIS, BGP etc. are routing protocols, not IP transport.

- saying “we can re-architect mobile networks and optimize design for 
efficient content delivery.” is arguable, at least in my mind, 
especially if you are thinking about caching and not better mobility 
management and error/congestion control.

#####2.1 Network Overview

- s/so the content is distributed using unicast mechanism/so the data 
can only be distributed using a unicast mechanism./

- some of the numbers on overhead confused me. Why is the absolute 
packet overhead dependent on packet size? Isn’t it constant, but the 
percentage overhead which gets higher with smaller packets?

#####2.2 Virtualizing Mobile Networks

- in the second paragraph, why are you talking about “call flow” 
which is strange terminology for a data service. Don’t you mean 
something like “control plane and data delivery”?

- when you say “evolve GTP-based architecture to open-flow SDN-based 
signaling” are you sure that 3GPP has settled on OpenFlow as the SDN 
protocol family to use in evolving GTP?

#####2.3 Key characteristics of Mobile Networks

- You say “Major benefit of the core network” - why only the core?

#####Content Delivery using IP

- this should be retitled “Data Transport using IP”

- you say “Other issues, such as out-of-order delivery due to ECMP” 
- where did you get this given that essentially all IP routers use 
flow-hashed ECMP, which does not mis-order packets.

#####Content Delivery using ICN

- this should be retitled “Data Transport using ICN”

- Not all ICN designs fall under the publish-subscribe paradigm. 
s/publish-subscribe/request-response/

- The description of Interest packets has some NDN-specific material 
(which is not needed). Fix to make generic for NDN/CCN (at least).

#####5.1 Recommendations in the Mobility Management

- it’s quite confusing when you say “IP is embedded very deeply into 
these messages as layer-3  transport and TLV carrying additional 
attributes.” since IP does not have TLV additional attributes. There 
has to be some protocol running on top of IP. What is it here?

- something really missing from this section is any identification of 
mobility management functions that are either rendered unnecessary or 
done in a very different way when using ICN. For example, UE’s don’t 
need to be tracked unless they are publishing their own content, you 
don’t need IP address assignment or any mobile-IP like functions to 
provide session continuity, etc. etc.

#####5.2.1 Dual stack ICN Deployments in UE

- I found the discussion in the numbered item “1. Insert Transport 
Selector function” really hard to follow. One persistent doubt I had 
was how you can have a single transport selector API when the semantics 
of transport interaction with an application are so utterly different 
for ICN and IP.

- In figure 6, what does it mean to say “PDCP (updated to support 
ICN)” You’d have to redo the protocol from scratch, unless you mean 
something much less than you imply and all you are doing is “updated 
to exchange parameters higher-layers use to run ICN”

- In NDN and CCN, every host (consumer or producer) has a local 
forwarder. This is not shown in figure 6, and in fact much of the 
following material is hard to understand in that context. For example, 
under numbered item 3 below figure 6, you talk about  “introduce an 
interface function  between ICN function and IP function”. There’s 
no need for this as any realistic ICN forwarder has various face types, 
one of which is a UDP tunnel face.

- In item 4, you land a teaser by saying “PDCP layer has to be aware 
of ICN capabilities and parameters.” We need to say a lot more here. 
PDCP seems to be a kind of ICN face and you need to know the parameters 
and restrictions (e.g. MTU) on both sides. In fact, what is needed (you 
don’t need to specify it all here) is a PDCP face type for ICN. It may 
also need a convergence protocol tuned, as NDN has done with its 
link-adaptation protocol.

- In item 5, while you are correct in saying no changes are required on 
the lower layers, ICN gives us an opportunity to de-ossify these layer 
boundaries and accrue the benefits of multi-layer optimizations for 
things like error recovery and wireless link scheduling.

#####5.2.3 ICN Deployment in Base Station (eNodeB)

- I don’t get why you have ICN with #3 dual stack, but not with #1 
native IP.

- More seriously, I have a real problem with your figure 8 and the 
description of the eNodeB functions. You seem to be viewing the eNodeB 
as a proxy gateway that just relays messages as opposed to containing an 
ICN forwarder. If it was a forwarder the inputs and outputs would be 
decoupled and your could receive on any of the face types from the UE 
side, and forward on any of the face types on the SGW/PGW side. If a 
proxy is what in fact was intended, then I suspect we’d be better off 
just continuing to tunnel through the eNodeB with GTP rather than invent 
something new and proxy-like that would have many peculiar 
characteristics. If on the other hand, you envision an ICN forwarder in 
the eNodeB, this section needs to be rethought and rewritten.

#####5.2.4 ICN Deployment in Packet Core (SGW/PGW) Gateways

- In item 3, what exactly is a “UE Name” is this an ICN name? If so 
you need to say more. If not, it’s really irrelevant to all this as 
it’s buried in the legacy 3GPP protocols.

#####6 Summary

- Where you say “To implement ICN in LTE mobile gateways, we are 
working to add”, who exactly is “we”? If you think ICNRG ought to 
work on this, just come out and say so.

- The paragraph starting “As per Cisco Visual networking…” seems 
out of place and should b rewritten or deleted.

[End of Comments]

---

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Mon, 26 Jun 2017 00:44:47 +0000

Hi Dave,
Thanks you so much for providing valuable comments. For last one week, we (authors) have been working intensely to further research and incorporate all the feedback into main document.  The work is in progress and we plan to release Version-2 of the document. Please see some of our comments inline in your feedback.

Do you have sometime next week to have review of our updated draft next week before we release new updated draft.

Best regards,
Prakash Suthar

---------- Forwarded message ----------
From: "David Oran" <[email-masked]<mailto:[email-masked]>>
Date: Jun 13, 2017 7:29 AM
Subject: [icnrg] Comments on draft-suthar-icnrg-icn-lte-4g-01
To: "icnrg" <[email-masked]<mailto:[email-masked]>>
Cc:

I reviewed “Native Deployment of ICN in LTE, 4G Mobile Networks” (https://datatracker.ietf.org/doc/draft-suthar-icnrg-icn-lte-4g/) and have the following comments. These comments are with <Chair Hat Off>

General Comments

This is a very good start to sorting through the complexities of integrating ICN into cellular wireless networks. It covers a lot of ground and can form the basis to guide further work, especially in directing efforts into parts of the design space most likely to work well technically, and to be practically deployable on the kinds of mobile edge and packet core equipment providers are likely to employ.

It does need a lot of work and further input from the community. To this end I think it would be useful to adopt this as an official work item for ICNRG. Among the overall things that need to be addressed are:

  *   The exposition is not clean in many places and there are language problems like missing articles and infelicitous working. A copy-edit review (sooner rather than later) would make future review and improvements much easier for the community.
  *   While much of the tutorial material is quite useful, especially on the relevant protocol designs and architectural constraints of 4G/LTE/5G networks, some of the material, notably the ICN tutorial material, is unnecessary and distracting, as the target audience is ICNRG, whose participants already know this stuff. An alternative way to cut this is to separate the document either into three semi-independent sections or three separate documents, along the lines of:

     *   ICN tutorial material for 3GPP-knowledgeable people
     *   3GPP/LTE tutorial material of ICN-knowledgeable people
     *   the existing material in the document on deployment scenarios, requirements, and options.

  *   The terminology section, while useful, needs to expand all the acronyms. As above, either restructure to have more tutorial material on LTE for the ICN community, or come out and say something like “you won’t understand the rest of this document unless you have more than passing familiarity with the technology and protocols of cellular networks. Go read [references a, b, c,] first and then come back after your head recovers from its journey through 3GPP-land”
  *   The document concentrates too much on content distribution as the poster-child use case. An unfortunate consequence of this is to reinforce a number of assumptions about caching that may not hold in practice. I suggest that a global editing pass be done to change most discussion of “content” to just talk about “data” and to describe ICN use cases in a more balanced way. For example, IoT is given short shrift, personal content on user devices is not considered, etc. Rather than wade too deeply into ICN use cases and applications, perhaps it’s best to simply cut down these discussions and simply focus on how to make ICN work well on these networks assuming you know little to nothing about the applications and use cases.
  *   I’m not sure this document needs to discuss privacy, but given the historical misconceptions of the mobile operators about their role in preserving/violating privacy in the IP world perhaps we need a discussion here about ICN. This interacts obviously with things like DPI, Lawful Intercept, and cache exploration for commercial gain. I don’t have a strong recommendation here other than to be sure your security considerations section (which you need to write) has some words about privacy. (Authors – We have discussed and revised the mobile gateway section)

Detailed comments
Abstract

  *   Noting in here depends on whether spectrum is licensed or unlicensed. You appear to tie unlicensed to WiFi and licensed to LTE, which is breaking down with things like LTE-U. Delete this. (Author- We have removed reference to unlicensed WiFi)
  *   There’s some very confusing wording here starting at “by embedding ICN into 3GPP protocol stack at IP datagram or replacing IP for non-IP datagrams”. (Author- We have re-worded the whole sentence)

1 Introduction

  *   OSPF, ISIS, BGP etc. are routing protocols, not IP transport. ((Author- We agree with your observation. We have provided more explanation)
  *   saying “we can re-architect mobile networks and optimize design for efficient content delivery.” is arguable, at least in my mind, especially if you are thinking about caching and not better mobility management and error/congestion control. (Author- Mobility management messages in 3GPP are very complex and any changes will need support from radio vendors, service providers etc., therefore our approach in this draft is to first deploy with IP transport or replace IP for content delivery. We are thinking about new draft dedicated specifically to re-design mobility-management using ICN)

  *

2.1 Network Overview

  *   s/so the content is distributed using unicast mechanism/so the data can only be distributed using a unicast mechanism./ (Authors – agreed and corrected)
  *   some of the numbers on overhead confused me. Why is the absolute packet overhead dependent on packet size? Isn’t it constant, but the percentage overhead which gets higher with smaller packets? (Authors – We put reference algorithms for IPSec overhead calculations)

2.2 Virtualizing Mobile Networks

  *   in the second paragraph, why are you talking about “call flow” which is strange terminology for a data service. Don’t you mean something like “control plane and data delivery”? (Authors –we have corrected)
  *   when you say “evolve GTP-based architecture to open-flow SDN-based signaling” are you sure that 3GPP has settled on OpenFlow as the SDN protocol family to use in evolving GTP? (Authors – At 3GPP open-flow SDN based signaling is discussed as evolution of GTP, however it is not accepted yet. To my knowledge many vendors are working on dis-aggregating mobile packet core into control and user plane. The signaling proposed between disaggregated control and user plane is based on open-flow. We can re-word as recommendation and site 3GPP reference document)

2.3 Key characteristics of Mobile Networks

  *   You say “Major benefit of the core network” - why only the core?  (Author – we have reviewed your comments and make appropriate changes)

Content Delivery using IP

  *   this should be retitled “Data Transport using IP”
  *   you say “Other issues, such as out-of-order delivery due to ECMP” - where did you get this given that essentially all IP routers use flow-hashed ECMP, which does not mis-order packets.

Content Delivery using ICN

  *   this should be retitled “Data Transport using ICN”
  *   Not all ICN designs fall under the publish-subscribe paradigm. s/publish-subscribe/request-response/
  *   The description of Interest packets has some NDN-specific material (which is not needed). Fix to make generic for NDN/CCN (at least).

5.1 Recommendations in the Mobility Management

  *   it’s quite confusing when you say “IP is embedded very deeply into these messages as layer-3 transport and TLV carrying additional attributes.” since IP does not have TLV additional attributes. There has to be some protocol running on top of IP. What is it here?
  *   something really missing from this section is any identification of mobility management functions that are either rendered unnecessary or done in a very different way when using ICN. For example, UE’s don’t need to be tracked unless they are publishing their own content, you don’t need IP address assignment or any mobile-IP like functions to provide session continuity, etc. etc.

5.2.1 Dual stack ICN Deployments in UE

  *   I found the discussion in the numbered item “1. Insert Transport Selector function” really hard to follow. One persistent doubt I had was how you can have a single transport selector API when the semantics of transport interaction with an application are so utterly different for ICN and IP.
  *   In figure 6, what does it mean to say “PDCP (updated to support ICN)” You’d have to redo the protocol from scratch, unless you mean something much less than you imply and all you are doing is “updated to exchange parameters higher-layers use to run ICN”
  *   In NDN and CCN, every host (consumer or producer) has a local forwarder. This is not shown in figure 6, and in fact much of the following material is hard to understand in that context. For example, under numbered item 3 below figure 6, you talk about “introduce an interface function between ICN function and IP function”. There’s no need for this as any realistic ICN forwarder has various face types, one of which is a UDP tunnel face.
  *   In item 4, you land a teaser by saying “PDCP layer has to be aware of ICN capabilities and parameters.” We need to say a lot more here. PDCP seems to be a kind of ICN face and you need to know the parameters and restrictions (e.g. MTU) on both sides. In fact, what is needed (you don’t need to specify it all here) is a PDCP face type for ICN. It may also need a convergence protocol tuned, as NDN has done with its link-adaptation protocol.
  *   In item 5, while you are correct in saying no changes are required on the lower layers, ICN gives us an opportunity to de-ossify these layer boundaries and accrue the benefits of multi-layer optimizations for things like error recovery and wireless link scheduling.

5.2.3 ICN Deployment in Base Station (eNodeB)

  *   I don’t get why you have ICN with #3 dual stack, but not with #1 native IP.
  *   More seriously, I have a real problem with your figure 8 and the description of the eNodeB functions. You seem to be viewing the eNodeB as a proxy gateway that just relays messages as opposed to containing an ICN forwarder. If it was a forwarder the inputs and outputs would be decoupled and your could receive on any of the face types from the UE side, and forward on any of the face types on the SGW/PGW side. If a proxy is what in fact was intended, then I suspect we’d be better off just continuing to tunnel through the eNodeB with GTP rather than invent something new and proxy-like that would have many peculiar characteristics. If on the other hand, you envision an ICN forwarder in the eNodeB, this section needs to be rethought and rewritten.

5.2.4 ICN Deployment in Packet Core (SGW/PGW) Gateways

  *   In item 3, what exactly is a “UE Name” is this an ICN name? If so you need to say more. If not, it’s really irrelevant to all this as it’s buried in the legacy 3GPP protocols.

6 Summary

  *   Where you say “To implement ICN in LTE mobile gateways, we are working to add”, who exactly is “we”? If you think ICNRG ought to work on this, just come out and say so.
  *   The paragraph starting “As per Cisco Visual networking…” seems out of place and should b rewritten or deleted.

[End of Comments]

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David Oran" <[email-masked]>
Date: Tue, 27 Jun 2017 08:42:27 -0400

On 25 Jun 2017, at 20:44, Prakash Suthar (psuthar) wrote:

> Hi Dave,
> Thanks you so much for providing valuable comments. For last one week, 
> we (authors) have been working intensely to further research and 
> incorporate all the feedback into main document.  The work is in 
> progress and we plan to release Version-2 of the document. Please see 
> some of our comments inline in your feedback.
>
> Do you have sometime next week to have review of our updated draft 
> next week before we release new updated draft.
>
I’m a bit short of time. Go ahead and get the new version submitted 
before the deadline.

> It does need a lot of work and further input from the community. To 
> this end I think it would be useful to adopt this as an official work 
> item for ICNRG. Among the overall things that need to be addressed 
> are:
>
>   *   The exposition is not clean in many places and there are 
> language problems like missing articles and infelicitous working. A 
> copy-edit review (sooner rather than later) would make future review 
> and improvements much easier for the community.
>   *   While much of the tutorial material is quite useful, especially 
> on the relevant protocol designs and architectural constraints of 
> 4G/LTE/5G networks, some of the material, notably the ICN tutorial 
> material, is unnecessary and distracting, as the target audience is 
> ICNRG, whose participants already know this stuff. An alternative way 
> to cut this is to separate the document either into three 
> semi-independent sections or three separate documents, along the lines 
> of:
>
>   *   The terminology section, while useful, needs to expand all the 
> acronyms. As above, either restructure to have more tutorial material 
> on LTE for the ICN community, or come out and say something like 
> “you won’t understand the rest of this document unless you have 
> more than passing familiarity with the technology and protocols of 
> cellular networks. Go read [references a, b, c,] first and then come 
> back after your head recovers from its journey through 3GPP-land”
>   *   The document concentrates too much on content distribution as 
> the poster-child use case. An unfortunate consequence of this is to 
> describe ICN use cases in a more balanced way. For example, IoT is 
> given short shrift, personal content on user devices is not 
> considered, etc. Rather than wade too deeply into ICN use cases and 
> applications, perhaps it’s best to simply cut down these discussions 
> and simply focus on how to make ICN work well on these networks 
> assuming you know little to nothing about the applications and use 
> cases.
>   *   I’m not sure this document needs to discuss privacy, but given 
> the historical misconceptions of the mobile operators about their role 
> in preserving/violating privacy in the IP world perhaps we need a 
> security considerations section (which you need to write) has some 
> words about privacy. (Authors – We have discussed and revised the 
> mobile gateway section)
>
> Detailed comments
> Abstract
>
>   *   Noting in here depends on whether spectrum is licensed or 
> unlicensed. You appear to tie unlicensed to WiFi and licensed to LTE, 
> which is breaking down with things like LTE-U. Delete this. (Author- 
> We have removed reference to unlicensed WiFi)
>   *   There’s some very confusing wording here starting at “by 
> embedding ICN into 3GPP protocol stack at IP datagram or replacing IP 
> for non-IP datagrams”. (Author- We have re-worded the whole 
> sentence)
>
> 1 Introduction
>
>   *   OSPF, ISIS, BGP etc. are routing protocols, not IP transport. 
> ((Author- We agree with your observation. We have provided more 
> explanation)
>   *   saying “we can re-architect mobile networks and optimize 
> design for efficient content delivery.” is arguable, at least in my 
> mind, especially if you are thinking about caching and not better 
> mobility management and error/congestion control. (Author- Mobility 
> management messages in 3GPP are very complex and any changes will need 
> support from radio vendors, service providers etc., therefore our 
> approach in this draft is to first deploy with IP transport or replace 
> IP for content delivery. We are thinking about new draft dedicated 
> specifically to re-design mobility-management using ICN)
>
>   *
>
> 2.1 Network Overview
>
>   *   s/so the content is distributed using unicast mechanism/so the 
> data can only be distributed using a unicast mechanism./ (Authors – 
> agreed and corrected)
>   *   some of the numbers on overhead confused me. Why is the absolute 
> percentage overhead which gets higher with smaller packets? (Authors 
> – We put reference algorithms for IPSec overhead calculations)
>
>   *   in the second paragraph, why are you talking about “call 
> flow” which is strange terminology for a data service. Don’t you 
> mean something like “control plane and data delivery”? (Authors 
> –we have corrected)
>   *   when you say “evolve GTP-based architecture to open-flow 
> SDN-based signaling” are you sure that 3GPP has settled on OpenFlow 
> as the SDN protocol family to use in evolving GTP? (Authors – At 
> 3GPP open-flow SDN based signaling is discussed as evolution of GTP, 
> however it is not accepted yet. To my knowledge many vendors are 
> working on dis-aggregating mobile packet core into control and user 
> plane. The signaling proposed between disaggregated control and user 
> plane is based on open-flow. We can re-word as recommendation and site 
> 3GPP reference document)
>
>   *   You say “Major benefit of the core network” - why only the 
> core?  (Author – we have reviewed your comments and make appropriate 
> changes)
>
>   *   you say “Other issues, such as out-of-order delivery due to 
> ECMP” - where did you get this given that essentially all IP routers 
> use flow-hashed ECMP, which does not mis-order packets.
>
>   *   The description of Interest packets has some NDN-specific 
> material (which is not needed). Fix to make generic for NDN/CCN (at 
> least).
>
>   *   it’s quite confusing when you say “IP is embedded very 
> deeply into these messages as layer-3 transport and TLV carrying 
> additional attributes.” since IP does not have TLV additional 
> attributes. There has to be some protocol running on top of IP. What 
> is it here?
>   *   something really missing from this section is any identification 
> of mobility management functions that are either rendered unnecessary 
> or done in a very different way when using ICN. For example, UE’s 
> don’t need to be tracked unless they are publishing their own 
> content, you don’t need IP address assignment or any mobile-IP like 
> functions to provide session continuity, etc. etc.
>
>   *   I found the discussion in the numbered item “1. Insert 
> Transport Selector function” really hard to follow. One persistent 
> doubt I had was how you can have a single transport selector API when 
> the semantics of transport interaction with an application are so 
> utterly different for ICN and IP.
>   *   In figure 6, what does it mean to say “PDCP (updated to 
> support ICN)” You’d have to redo the protocol from scratch, unless 
> you mean something much less than you imply and all you are doing is 
> “updated to exchange parameters higher-layers use to run ICN”
>   *   In NDN and CCN, every host (consumer or producer) has a local 
> no need for this as any realistic ICN forwarder has various face 
> types, one of which is a UDP tunnel face.
>   *   In item 4, you land a teaser by saying “PDCP layer has to be 
> aware of ICN capabilities and parameters.” We need to say a lot more 
> here. PDCP seems to be a kind of ICN face and you need to know the 
> parameters and restrictions (e.g. MTU) on both sides. In fact, what is 
> needed (you don’t need to specify it all here) is a PDCP face type 
> for ICN. It may also need a convergence protocol tuned, as NDN has 
> done with its link-adaptation protocol.
>   *   In item 5, while you are correct in saying no changes are 
> required on the lower layers, ICN gives us an opportunity to de-ossify 
> these layer boundaries and accrue the benefits of multi-layer 
> optimizations for things like error recovery and wireless link 
> scheduling.
>
>   *   More seriously, I have a real problem with your figure 8 and the 
> as a proxy gateway that just relays messages as opposed to containing 
> an ICN forwarder. If it was a forwarder the inputs and outputs would 
> be decoupled and your could receive on any of the face types from the 
> UE side, and forward on any of the face types on the SGW/PGW side. If 
> a proxy is what in fact was intended, then I suspect we’d be better 
> off just continuing to tunnel through the eNodeB with GTP rather than 
> invent something new and proxy-like that would have many peculiar 
> characteristics. If on the other hand, you envision an ICN forwarder 
> in the eNodeB, this section needs to be rethought and rewritten.
>
>   *   In item 3, what exactly is a “UE Name” is this an ICN name? 
> If so you need to say more. If not, it’s really irrelevant to all 
> this as it’s buried in the legacy 3GPP protocols.
>
> 6 Summary
>
>   *   Where you say “To implement ICN in LTE mobile gateways, we are 
> working to add”, who exactly is “we”? If you think ICNRG ought 
> to work on this, just come out and say so.
>   *   The paragraph starting “As per Cisco Visual networking…” 
> seems out of place and should b rewritten or deleted.
>
> [End of Comments]
>

> [email-masked]

DaveO