Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

["Anil Jangam (anjangam)" <[e-mail]>]

Hello Dave,



We did incorporate your review comments. I provide below exact changes we made for each of your comments. Hope this helps.



Detailed comments:

•          On the top of page 10, you say “However, a common limitation of these research efforts is that they focus on faster routing of Interest request towards the content rather than the quality of experience based on actual content delivery. For that to happen, QoS should be implemented and enforced on the Data packet path.” I don’t know what this is doing here. It isn’t terribly helpful to just invoke QoS. It’s also not appropriate to bring QoE into this, as QoE is an application layer concept. Lastly, there is current research on QoS for ICN, so the statement isn’t all that accurate.

[AJ] We reworded it as – “focus of these research efforts is on faster routing of Interest requests towards the content rather than content delivery.”



•          On page 11, you say “The mapping of CoS to DSCP takes place at layer 2/3 switching and routing elements.” Isn’t it the opposite - the DSCP is mapped to the COS rather than vice versa?

[AJ]  [A close up of a device  Description automatically generated]



•          On page 13, I’m not sure what you are trying to say with “The content matching tuple uniquely identifies the correlation between an Interest and data packet.” I don’t think correlation is the right word. Please re-work to say something to the effect that the Interest is matched against the named date subject to the tuple referred to above.

[AJ]  [cid:image002.png@01D59D36.24EA5730]



•          A bit further down, while a detail and maybe not worth mentioning, some loops are in fact suppressed through Interest aggregation only loops that look like Interest retransmissions coming in through the same ingress interface as an earlier Interest produce persistent looping that has to be caught with the hop limit.

[AJ] We removed the concerning statement from the text. See below.

[AJ]   [A close up of a device  Description automatically generated]



•          On page 14, I’m not sure what you mean by “signed key”? In any event the actual key is not usually in the data packet; only a key-id or key locator.

•          on page 17, what do you mean by “stored in the ICN node”? Is this producers, repos, caches, or all of the above?

[AJ] To address this, we added this – “stored in the ICN node (such as repos, caches)”



•          On page 19, you assert the “main advantage of ICN is in caching and reusing content”. I would disagree with this statement, and it isn’t necessary to your argument that the work needed to convert LTE signaling protocols to ICN might be a bad use of engineering and design effort.

[AJ] To address this we paraphrased it as – “One of the advantages of ICN is in the caching and reusing of the content”



•          On page 21, it might be worth toning down the assertion that providing a transport-level API that is comment for IP and ICN would result in no impact on application programmers. While that might be true in a literal sense, if you don’t give application programmers access to the richness of ICN semantics (e.g. hierarchical names, trust schemas based on those names, etc.) arguably much of the benefit of introducing ICN in the first place is lost.

[AJ] To address this toning down, we paraphrased it as – “Our proposal is to provide an Application Programming Interface (API) to the application developers so they can choose either ICN or IP transport for exchanging the traffic with the network”. We removed the wording “no impact on ..”



•          On page 26, some requirements language is creeping in - you say “eNodeB shall be upgraded…”. There may be other instances of this, so I’d recommend a scrub to get rid of things that smack of requirements language.

[AJ] We paraphrased it as – “eNodeB can be upgraded to support three different types of transport”



•          On page 29, in the proposed test scenarios you say “EPC: Cisco evolved Pack Core…”. I’d scrub this since one would not want a test deployment specification to require a particular vendor’s LTE implementation.

[AJ] We reworded it to remove mention of Cisco – “EPC: Evolved Packet Core in a single instance (such as vPC-SI).”



Thank you,

/anil.



    On 17 Nov 2019, at 11:37, Dirk Kutscher wrote:



    > Thanks, Milan and co-authors.

    >

    > Martin and Dave, could you have a look at the 05 version of this draft and check whether it addresses your comments?

    >

    I went looking for an email that responded to my individual comments but didn’t find one. Did I miss it? I was hoping to not have to do an entire additional careful read-through to figure out if my individual comments were addressed and how.



    If I didn’t miss anything I’ll go ahead and read -05 through from top to bottom, but it may take me a while to find the time.



    >

    > Thanks,

    > Dirk

    >

    >

    >

    > On 4 Nov 2019, at 20:28, Milan Stolic (mistolic) wrote:

    >

    >> In addition to the below, as suggested by Dave, we have applied formatting and grammar corrections with help of a native speaker.

    >>

    >> Thanks,

    >> Milan

    >>

    >> From: Milan Stolic (mistolic)

    >> Sent: Monday, November 4, 2019 13:15

    >> To: Akbar Rahman <[e-mail]>; Börje Ohlman <borje.ohlman=[e-mail]>; [e-mail]

   >> Cc: Prakash Suthar (psuthar) <[e-mail]>; Anil Jangam (anjangam) ([e-mail]) <[e-mail]>

    >> Subject: RE: RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

    >>

    >> Hello ICNRG team,

    >>

    >> We have submitted a revision of our Native Deployment of ICN in LTE, 4G Mobile Networks draft. It addresses comments received in the past few months from Luca, Akbar, Martin and Dave. The latest draft can be found here<https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/>. We would like to take this opportunity and thank the team for their feedback, and to ask for the next steps related to the RG last call.

    >>

    >> Thank you,

    >> Milan

    >>

    >> From: icnrg <[e-mail]<mailto:[e-mail]>> On Behalf Of Akbar Rahman

    >> Sent: Tuesday, September 24, 2019 13:03

    >> To: Börje Ohlman <borje.ohlman=[e-mail]<mailto:borje.ohlman=[e-mail]>>; [e-mail]<mailto:[e-mail]>

    >> Subject: Re: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

    >>

    >> I support progressing the document as we have had several rounds of reviews, and also general RG interest in the draft.

    >>

    >> I recommend publishing it as Informational as it is not a pure protocol draft but also covers other aspects such as architecture, configuration and open issues.

    >>

    >>

    >> Best Regards,

    >>

    >>

    >> Akbar

    >>

    >> From: icnrg <[e-mail]<mailto:[e-mail]>> On Behalf Of Börje Ohlman

    >> Sent: Thursday, September 19, 2019 10:29 PM

    >> To: [e-mail]<mailto:[e-mail]>

    >> Subject: [icnrg] RG Last call on the ICN in LTE, 4G document - closes October 6th, 2019

    >>

    >> Dear ICNRG’ers,

    >>

    >> The draft Native Deployment of ICN in LTE, 4G Mobile Networks has now been reviewed, see mailing list for details, and the comments has been addressed by the authors in the new -04 version of the draft.

    >> We as chairs, now think the document is ready for the RG last call. Please let us now if you agree with this or if you have further comments on the draft. Please also let us know if you support that we should publish this document.

    >>

    >> We also would like your comments on whether you think this document is best published as an Experimental or Informational RFC?

    >>

    >> You can find the document at:

    >> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g

    >>

    >> Given the upcoming ICN conference and ICNRG Interim meeting, as noted above, the last call closes on Sunday, October 6th, 2019.

    >>

    >> Hope to see you in Macao.

    >>

    >> Your Chairs,

    >> Börje, Dave and Dirk

    >> [Banner]

    >>

    >>

    >> [Banner][Banner]

    >> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

    >

    >

    >> _______________________________________________

    >> icnrg mailing list

    >> [e-mail]

    >> https://www.irtf.org/mailman/listinfo/icnrg





    > _______________________________________________

    > icnrg mailing list

    > [e-mail]

    > https://www.irtf.org/mailman/listinfo/icnrg



    DaveO