[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader

[Junxiao Shi]

Hi Klaus

Thanks for your detailed review.

WiFi
Yes, NDNLPv2 will work on all links including wireless links.
I didn't specifically mention WiFi because most WiFi links are emulating
Ethernet, and there's no difference from software perspective.

Unknown Fields
Excerpt from NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
27:

Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to
understand all fields.


Ignoring an unknown field will cause incorrect operations, see #2520
note-11.

NACK means "negative acknowledgment"
Agreed.

Local Cache Policy
CachingPolicy field is neither cache decision policy nor cache replacement
policy.
It indicates a suggestion to ContentStore about one specific Data. This
point is already made explicit in "whether and how to cache a Data packet",
but I should use "the" instead of "a" to clarify, or add another sentence.
See NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
72 on other values in the plan.

Reliability Improvement
This is in the plan but not in this spec.


I'll also consider minor suggestions in the PDF.

Yours, Junxiao

On Thu, May 28, 2015 at 7:30 AM, Klaus Schneider <
klaus.schneider at uni-bamberg.de> wrote:

> Hi Junxiao,
>
> I hope it's not too late for my comments.
>
> Most of the spec looks good to me. Here are just a few remarks/questions.
>
>
> ## Goals
>
> I suppose that NDNLP will also work on wireless links? Maybe it's a good
> idea to add IEEE 802.11 (WiFi) to the list of examples.
>
> ## NDNLP Packet Format
>
> Maybe you can elaborate on why a NDNLP packet with unknown fields must be
> dropped. What is the benefit against accepting the packet and ignoring the
> unknown field? Should the receiver send a notice to sender of the dropped
> packet (sth. like a NACK)?
>
> ## Network NACK
>
> Maybe one can write out that NACK means "negative acknowledgment". It's
> probably obvious though.
>
> ## Local Cache Policy
>
> Am I right to assume that the policy affects only the single data packet
> and not the other caching decisions (so CachingPolicy can't be set to LRU,
> LFU, etc.)? Maybe one can make that more explicit.
>
> I am also unsure if the caching policy is about the cache decision policy
> (like cache/no cache), cache replacement policy or both. I assume it's the
> latter case, but I think it can't hurt to make it more explicit.
>
> ## Misc.
>
> Regarding the "reliability improvement": Did you have a look at RFC 3366
> "Advice to link designers on link Automatic Repeat reQuest (ARQ)" (
> http://www.rfc-base.org/txt/rfc-3366.txt) ?
>
> They differentiate between Perfectly-Persistent (Reliable),
> High-Persistence (Highly-Reliable) and Low-Persistence (Partially-Reliable)
> ARQ Protocols. Maybe you can use some ideas from that document. I think
> it's a great read.
>
> I have appended a pdf file with a few orthographical suggestions. Please
> consider that I am not a native speaker and may be wrong about some of
> these.
>
> I hope that helps.
>
> Best regards,
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150528/5b7c3e3f/attachment.html>