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

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Sat, 3 Jun 2017 22:20:42 +0000

Hi Dear All,

We have uploaded new version of our original draft Native Deployment of ICN in LTE, 4G Mobile Networks on 16 May 2017.

The updates are based our further research in this area. You can find updated document at following link
https://datatracker.ietf.org/doc/html/draft-suthar-icnrg-icn-lte-4g

Please review and draft and provide feedback. I am planning to present this draft in IETF-99 at Prague.
Thanks you so much and looking forward for your valuable input.
Best regards,

Prakash Suthar, Milan Stolic and Anil Jangam,
Autors

---

From: "Jagodits, Thomas" <[email-masked]>
Date: Fri, 9 Jun 2017 15:57:47 +0000

Hi,

Feedback is as follows.

a)      [pg 4] “..is using a 3rd party backhaul provider), then it will add ~15-23
   overhead based…”, state if this overhead is bytes or percentage. If bytes, the overhead with IPSec may be even higher (e.g. http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/) and also in the referenced IPSec overhead calculator tool .

b)      [pg 5 – 2.2] It is being implied that major service providers do not use x86 based hardware;  this is not necessarily the case.

c)       [pg 5 - 2.2] Last sentence of the first paragraph is mangled and should be rewritten.

d)      [pg 5 – 2.3, first paragraph] Major benefit of CN is not just predictability of traffic parameters. The CN functionality is more than what is listed.

e)      [pg 5 – 2.3, third paragraph] QoS involves configuration and scheduling.

f)       [pg 6 – 2.3, last paragraph] But presumably any configuration update is verified during operations and thus a misconfiguration would be identified promptly.

g)      [pg 9, figure 4] The numbers shown  in the table are not defined anywhere. Provide clarification of the meaning.

h)      [pg 10 – 5.1] Facts should be provided why it is not beneficial to deploy ICN in this case.

i)        [pg 10 – 5.2.1] For clarity do list the points of attachments.

j)        [pg 11 – figure 5] Figure 5 shows a box for “Transport Selector”  and a separate one for “ICN/IP” but the text below states that Transport Selector consists of ICN+IP function.

k)      [pg 11] API stands for Application Program Interface.

l)        [pg 11 – last sentence] Describe the granularity. Would routing done per packet?

m)    [pg 14 – 5.2.2] Be specific what areas of PDCP would need to be changed.

n)      [pg 14 – 5.2.3] If enodeB or Packet Core  provides ICN functionality then presumably the hardware architecture may change to add more storage so that caching from ICN can be leveraged.

o)      [general] Grammar can be improved throughout.

p)      [5.x] List any security considerations if any when enodeB or packet Core provide the ICN functionality.

Regards,
Thomas Jagodits
From: icnrg [mailto:[email-masked]] On Behalf Of Prakash Suthar (psuthar)
Sent: Saturday, June 03, 2017 6:21 PM
To: [email-masked]
Cc: Anil Jangam (anjangam) <[email-masked]>; Milan Stolic (mistolic) <[email-masked]>
Subject: [icnrg] draft-suthar-icnrg-icn-lte-4g

Hi Dear All,

---

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Fri, 9 Jun 2017 16:34:37 +0000

Dear Jagodits,
Good morning and Thank you so much for reviewing the draft and providing input. Let me review them and make appropriate changes after investigations and validation.
Thanks

Prakash Suthar
Principal Architect
Cisco System Inc.

From: "Jagodits, Thomas" <[email-masked]>
Date: Friday, June 9, 2017 at 11:57 AM
To: Prakash Suthar <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Anil Jangam <[email-masked]>, "Milan Stolic (mistolic)" <[email-masked]>
Subject: RE: [icnrg] draft-suthar-icnrg-icn-lte-4g

Hi,

Feedback is as follows.

  1.  [pg 5 – 2.2] It is being implied that major service providers do not use x86 based hardware;  this is not necessarily the case.
  2.  [pg 5 - 2.2] Last sentence of the first paragraph is mangled and should be rewritten.
  3.  [pg 5 – 2.3, first paragraph] Major benefit of CN is not just predictability of traffic parameters. The CN functionality is more than what is listed.
  4.  [pg 5 – 2.3, third paragraph] QoS involves configuration and scheduling.
  5.  [pg 6 – 2.3, last paragraph] But presumably any configuration update is verified during operations and thus a misconfiguration would be identified promptly.
  6.  [pg 9, figure 4] The numbers shown  in the table are not defined anywhere. Provide clarification of the meaning.
  7.  [pg 10 – 5.1] Facts should be provided why it is not beneficial to deploy ICN in this case.
  8.  [pg 10 – 5.2.1] For clarity do list the points of attachments.
  9.  [pg 11 – figure 5] Figure 5 shows a box for “Transport Selector”  and a separate one for “ICN/IP” but the text below states that Transport Selector consists of ICN+IP function.
  10. [pg 11] API stands for Application Program Interface.
  11. [pg 11 – last sentence] Describe the granularity. Would routing done per packet?
  12. [pg 14 – 5.2.2] Be specific what areas of PDCP would need to be changed.
  13. [pg 14 – 5.2.3] If enodeB or Packet Core  provides ICN functionality then presumably the hardware architecture may change to add more storage so that caching from ICN can be leveraged.
  14. [general] Grammar can be improved throughout.
  15. [5.x] List any security considerations if any when enodeB or packet Core provide the ICN functionality.

Regards,
Thomas Jagodits

Hi Dear All,

---

From: "Prakash Suthar (psuthar)" <[email-masked]>
Date: Sun, 25 Jun 2017 23:37:46 +0000

Hi Thomas,
Greetings. Thank you so much for providing input to our document. We (authors) have been reviewing and incorporating changes to the document. The changes are highlighted point-wise.
We are also incorportating changes suggested by Mr. Dave Oran and others. New version will be released soon.
Best regards,

Authors

Hi,

Feedback is as follows.

a)       [pg 4] “..is using a 3rd party backhaul provider), then it will add ~15-23
   overhead based…”, state if this overhead is bytes or percentage. If bytes, the overhead with IPSec may be even higher (e.g. http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/) and also in the referenced IPSec overhead calculator tool .- reviewed and reference included

  1.  [pg 5 – 2.2] It is being implied that major service providers do not use x86 based hardware;  this is not necessarily the case. – corrected and added text about open-flow messages for control and user plane separation
  2.  [pg 5 - 2.2] Last sentence of the first paragraph is mangled and should be rewritten - corrected
  3.  [pg 5 – 2.3, first paragraph] Major benefit of CN is not just predictability of traffic parameters. The CN functionality is more than what is listed.
  4.  [pg 5 – 2.3, third paragraph] QoS involves configuration and scheduling – Reviewed and re-written with more explanation
  5.  [pg 6 – 2.3, last paragraph] But presumably any configuration update is verified during operations and thus a misconfiguration would be identified promptly. - Reviewed and re-written
  6.  [pg 9, figure 4] The numbers shown in the table are not defined anywhere. Provide clarification of the meaning. -- Done
  7.  [pg 10 – 5.1] Facts should be provided why it is not beneficial to deploy ICN in this case. -- Done
  8.  [pg 10 – 5.2.1] For clarity do list the points of attachments. – Done, removed the line. Refer to section 5.1.
  9.  [pg 11 – figure 5] Figure 5 shows a box for “Transport Selector” and a separate one for “ICN/IP” but the text below states that Transport Selector consists of ICN+IP function.  – Corrected the context with more preference params.
  10. [pg 11] API stands for Application Program Interface. - corrected
  11. [pg 11 – last sentence] Describe the granularity. Would routing done per packet? – With ICN the routing is per packet.
  12. [pg 14 – 5.2.2] Be specific what areas of PDCP would need to be changed.  – listed the PDCP functions to be modified.
  13. [pg 14 – 5.2.3] If enodeB or Packet Core provides ICN functionality then presumably the hardware architecture may change to add more storage so that caching from ICN can be leveraged.   -- Done
  14. [general] Grammar can be improved throughout.  – Reviewed and grammar corrected.
  15. [5.x] List any security considerations if any when enodeB or packet Core provide the ICN functionality. – We have added separate section about security considerations for ICN. We have first covered security best practices deployed for IP  based LTE network and then we analyzed how it get impacted with ICN

      q)  Routing impact for mobility of UE. How ICN and mobility of UE are married? – As first step, we are considering ICN deployment for IP transport rather than mobility management messages, so there is not major impact. However, UE mobility after attachment (mobile gateways) and then moving to different location. This is referred as handover from one eNodeB to another. We have analyzed ICN mobility impact and appropriate changes done in document.

Regards,
Thomas Jagodits

Hi Dear All,

Authors