Project

General

Profile

Task #2763

NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceId

Added by Junxiao Shi over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Protocol
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Write spec for initial batch of NDNLPv2 features:

  • network NACK
  • fragmentation
  • NextHopFaceId
  • CachingPolicy
  • IncomingFaceId
NDNLPv2_20150417.pptx (132 KB) NDNLPv2_20150417.pptx Junxiao Shi, 04/21/2015 12:45 PM

Related issues

Related to NFD - Feature #2520: NDNLPv2 high-level designClosed

Related to NFD - Feature #2222: NDNLPv2 design: link serviceClosed

Related to ndn-cxx - Task #2883: NDNLPv2 design: NACK in client FaceClosed

Blocks NDN-CCL - Feature #2531: LocalControlHeaderClosed2015-02-17

Blocks ndn-cxx - Task #2841: NDNLPv2 design: packet format API for NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceIdClosed

Blocked by NDN Specifications - Task #2866: Reserve TLV-TYPE codes for NDNLPv2Closed

History

#1 Updated by Junxiao Shi over 4 years ago

20150420 conference call approved the design of listed features in NDNLPv2_20150417.pptx.

Other features are not yet approved, and are not part of this Task.

#2 Updated by Davide Pesavento over 4 years ago

#3 Updated by Junxiao Shi over 4 years ago

  • Status changed from New to In Progress

#4 Updated by Junxiao Shi over 4 years ago

  • % Done changed from 0 to 30

Wiki page is created: NDNLPv2

The content is currently embedded from Gist for better version control during initial writing.
It will be copied to Redmine wiki when final version (including all NDNLPv2 features) are complete.

#5 Updated by Junxiao Shi over 4 years ago

  • % Done changed from 30 to 60

Fragmentation is written.

#6 Updated by Junxiao Shi over 4 years ago

  • Category changed from Docs to Protocol
  • % Done changed from 60 to 70

NACK is written.

#7 Updated by Junxiao Shi over 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100

LocalControlHeader-equivalent field (NextHopFaceId CachingPolicy IncomingFaceId) are complete.

#8 Updated by Junxiao Shi over 4 years ago

#9 Updated by Junxiao Shi over 4 years ago

  • Blocks Task #2841: NDNLPv2 design: packet format API for NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceId added

#10 Updated by Junxiao Shi over 4 years ago

Answer to #2841 note-13:

Can we call "NdnlpHeaderExtension" a "Feature"?

No, they are distinct concepts.

A feature can have zero or more header extensions (and trailer extensions).

For example, indexed fragmentation feature defines two HeaderExtensions: NdnlpFragIndex and NdnlpFragCount.

Why don't we call "Nack" as "NackReason" or just "Reason". The description already calls it this way. For "DuplicataNack" and "GiveUpNack" I would lose "Nack" suffix. Why NACK reason should have "Nack" in it's name?

Agreed.

Why NdnlpPacket is assigned code 100 (0x64)?

This is to avoid clashing with NDNLP-TLV and LocalControlHeader, both of which use 80 as TLV-TYPE code for top-level element.

#11 Updated by Junxiao Shi over 4 years ago

20150608 conference call reviewed revision 213b5818fefc773902728e66d5685cebf883f106.

Some comments are:

  • The Ndnlp prefix on all types are unnecessary, because the design is in NDN context. However, Lp prefix should appear on some types, because the "namespace" of TLV-TYPE declarations is flat, and Lp is necessary to distinguish the type as part of NDNLPv2.
  • Currently there are only 21 TLV-TYPEs reserved for link protocols, which would be insufficient according to the roadmap of NDNLPv2. We decide to reserve a block of TLV-TYPEs in 3-octet range for link protocols, and assign 3-octet codes to less common fields.
  • The concept of HeaderExtension is confusing. It shall be renamed as HeaderField.
  • It's unnecessary to let Sequence stand out. Instead, it could be one choice of HeaderField.
  • HeaderFields under a header should be sorted in increasing TLV-TYPE order, so that there's only one way to encode a packet.
  • NdnlpHeader and NdnlpTrailer wrappers are wasting octets. Those wrappers should be dropped, in favor of letting header and trailer fields appear directly under LpPacket struct.

#12 Updated by Junxiao Shi over 4 years ago

  • Blocked by Task #2866: Reserve TLV-TYPE codes for NDNLPv2 added

#13 Updated by Junxiao Shi over 4 years ago

  • Description updated (diff)

#14 Updated by Junxiao Shi over 4 years ago

  • Status changed from Resolved to Closed

#15 Updated by Junxiao Shi over 4 years ago

#16 Updated by Junxiao Shi over 4 years ago

  • Subject changed from NDNLPv2: NACK, Fragmentation, LocalControlHeader to NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachingPolicy, IncomingFaceId

#17 Updated by Junxiao Shi over 4 years ago

  • Related to Task #2883: NDNLPv2 design: NACK in client Face added

#18 Updated by Junxiao Shi about 4 years ago

  • Status changed from Closed to In Progress
  • % Done changed from 100 to 80

#19 Updated by Junxiao Shi about 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

https://gist.github.com/yoursunny/92d8c3514476be6a7b93/c2213a318211cf0980b19bb174c7a835ac51d186

This revision takes some design from https://gist.github.com/cawka/f8bb5f558568f06c78ca/f552c86630eb07579b85849f3108d32bfa2340e6, with the following differences:

  • "NackReason-specific TLVs" is not defined, because Duplicate and GiveUp don't need this.
  • TLV-TYPE code assignments are updated with NackReason element.

#20 Updated by Junxiao Shi about 4 years ago

  • Description updated (diff)

Question: should I change CachingPolicy header field to use a structure similar to Nack?

#21 Updated by Eric Newberry about 4 years ago

Junxiao Shi wrote:

Question: should I change CachingPolicy header field to use a structure similar to Nack?

It would create consistency within the API. Does CachingPolicy need anything besides a non-negative integer to indicate the policy?

#22 Updated by Junxiao Shi about 4 years ago

Answer to #2841 note-33:

I don't really like that you completely removed NackReason-specific elements in the spec. Why do you want to modify core parts of the specification (i.e., suddenly adding rules that Nack can actually contain multiple elements and define rules how to process those elements) instead of defining it just once upfront?

It's pointless to define something that won't be used.

We have decided not to define LpTrailerField until it's first used.
For the same reason, NackReason-specific elements won't be defined until it's first used.

#23 Updated by Alex Afanasyev about 4 years ago

Junxiao Shi wrote:

Question: should I change CachingPolicy header field to use a structure similar to Nack?

I don't have a strong preference, but leaning towards consistency (so, towards the change).

#24 Updated by Junxiao Shi about 4 years ago

  • Status changed from Resolved to In Progress
  • % Done changed from 100 to 90

I also prefer to make the note-20 change.
Based on votes in note-21 and note-23, the change will be made, although this means implementation needs reworking.

#25 Updated by Junxiao Shi about 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

https://gist.github.com/yoursunny/92d8c3514476be6a7b93/f5fd5211a0dff7d33c8ad8e44dad9971dcfcaeea

note-20 is fulfilled.

I also renamed CachingPolicy to CachePolicy to reduce the length.

#26 Updated by Davide Pesavento about 4 years ago

  • Subject changed from NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachingPolicy, IncomingFaceId to NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceId

#27 Updated by Junxiao Shi about 4 years ago

Spec is updated to revision 4893b3a6183b2751755cc2e9ee208c0c0bbfb8bc with NackReasons defined in #3032 note-2.

#28 Updated by Junxiao Shi about 4 years ago

  • Description updated (diff)

Also available in: Atom PDF