Project

General

Profile

Feature #2520

NDNLPv2 high-level design

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

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

100%

Estimated time:
9.00 h

Description

Design a link layer header to support the following features, and keep it extensible:

  • fragmentation and reassembly
  • failure detection
  • reliability
  • NACK

References:

Scanned_20141115-1736.pdf (388 KB) Scanned_20141115-1736.pdf NDNLP-BFD protocol idea Junxiao Shi, 02/13/2015 02:28 PM
NDNLP-BFDSummaryReport.pdf (390 KB) NDNLP-BFDSummaryReport.pdf NDNLP-BFD project report Junxiao Shi, 02/13/2015 02:29 PM
NDNLPv2_20150311.pptx (120 KB) NDNLPv2_20150311.pptx Junxiao Shi, 03/11/2015 04:05 PM
NDNLPv2_20150428.pptx (131 KB) NDNLPv2_20150428.pptx Junxiao Shi, 04/28/2015 10:48 PM
NDNLPv2_20150513.pptx (137 KB) NDNLPv2_20150513.pptx Junxiao Shi, 05/28/2015 01:56 PM
NDNLPv2_20150617.pptx (137 KB) NDNLPv2_20150617.pptx Junxiao Shi, 06/17/2015 04:32 PM
NDNLPv2_20150729.pptx (136 KB) NDNLPv2_20150729.pptx Junxiao Shi, 07/29/2015 09:12 AM

Related issues

Related to NFD - Task #2763: NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceIdClosed

Blocks NFD - Task #3437: NDNLPv2 loss detection designClosed

History

#1 Updated by Junxiao Shi over 4 years ago

  • Status changed from New to In Progress

#2 Updated by Junxiao Shi over 4 years ago

I'm looking at existing work on NDNLPv1 and its extensions.

I realize a problem hasn't been addressed yet: the existing link acknowledgement and retransmission mechanism won't work for multicast.

I'm reading reliable multicast works such as RFC5740 in hope to find a solution.

#3 Updated by Davide Pesavento over 4 years ago

Whatever you do, please keep it extensible (or overridable, or optional). The reason is that in our scenario (mobile ad-hoc wifi/VANET) we have our own acknowledgment and retransmission policies, which can be drastically different from those used in a wired scenario. Thanks.

#4 Updated by Junxiao Shi over 4 years ago

Whatever you do, please keep it extensible (or overridable, or optional).

Yes, every feature will be optional, and the header is extensible.

But I feel necessary to put in at least one concrete design for each feature, instead of saying "everything is optional, and is null for now". I did that in #2200 ("null encryption") which caused many design problems.

The reason is that in our scenario (mobile ad-hoc wifi/VANET) we have our own acknowledgment and retransmission policies, which can be drastically different from those used in a wired scenario.

I need to know more about different designs in the solution space.
Please post a citation to your work (or similar existing work) so I can have a look.

#5 Updated by Davide Pesavento over 4 years ago

Junxiao Shi wrote:

But I feel necessary to put in at least one concrete design for each feature, instead of saying "everything is optional, and is null for now". I did that in #2200 ("null encryption") which caused many design problems.

Yeah, agreed.

I need to know more about different designs in the solution space.
Please post a citation to your work (or similar existing work) so I can have a look.

See for example http://new.named-data.net/wp-content/uploads/nom.pdf

There's also some code from our old (and ugly) implementation here: https://github.com/named-data/vndn/tree/master/network/mac

#6 Updated by Junxiao Shi over 4 years ago

#7 Updated by Junxiao Shi over 4 years ago

See for example http://new.named-data.net/wp-content/uploads/nom.pdf

I looked at this paper. Vehicular network is indeed very different from access point WiFi networks, because topology is highly dynamic, and application scenario determines that information becomes more useful when it is pushed farther away from its origin.

I can see that ACK or repair request based reliability is unsuitable. I also see that a header field containing sender's coordinates could be useful (although it won't be in the main spec, but can appear as an extension for vehicular network).

#8 Updated by Junxiao Shi over 4 years ago

  • % Done changed from 0 to 30

#9 Updated by Junxiao Shi over 4 years ago

I'm uploading design slides, despite that some parts are still incomplete.

#10 Updated by Davide Pesavento over 4 years ago

Slide 9: if I remember correctly fragmentation was implemented in v0.3

Slide 18: "fixed-bit"? Do you mean fixed width?

Slide 25: "one or more network layer packets"... how can you have a fragment of more than one packet?

Slide 27: I'm not sure I agree that packets with unknown fields must be dropped (btw is it a MUST or a SHOULD?), but we can come back on this later.

#11 Updated by Junxiao Shi over 4 years ago

Slide 9: if I remember correctly fragmentation was implemented in v0.3

Fragmentation implementation should be since v0.1 (#1206, #1208).

Fragmentation is enabled on EthernetFace (#1209) in v0.3.

Slide 18: "fixed-bit"? Do you mean fixed width?

Yes, "fixed width" is a better term.

Slide 25: "one or more network layer packets"... how can you have a fragment of more than one packet?

One NdnlpPacket can combine multiple network layer packets. This could be useful if the link prefers large frames, but network layer packets are small.

Current fragmentation design doesn't combine small packets, but I intend to keep this possibility as an extension option.

Slide 27: I'm not sure I agree that packets with unknown fields must be dropped (btw is it a MUST or a SHOULD?), but we can come back on this later.

I should have stated that this requirement is a MUST.

But I'm also unsure about this design choice.

Looking at features designed in the slides, suppose a host doesn't understand each field, fragmentation is the only feature that can cause major problem if not understood.

  • NdnlpFragIndex, NdnlpFragCount: the host cannot reassemble the network layer packet, and thus has no way to understand the chunk inside NdnlpFragment
  • NdnlpArq: no harm on correctness, but hurts reliability
  • NdnlpHmacSignature: no harm on correctness, but increases security risk
  • NdnlpNack: the host misunderstands a NACK as an Interest, which hopefully would be detected as a duplicate; small harm on correctness
  • NextHopFaceId, CachingPolicy, IncomingFaceId: irrelevant because they are used on local machine only

On a point-to-point link, it's fairly easy for both hosts to agree upon what NDNLPv2 features are used, eg. during tunnel authentication.

The question is what to do on a multi-access link.

If hosts MUST drop packets with unknown fields, assuming we could do negotiation (which itself could be harmful in terms of security), the group would have to operate with the feature set of the least capable host. Furthermore, if a new group member with less features joins the group, existing communication would have to downgrade.

Related: How to handle unrecognized TLVs in network layer packets:

IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)

#12 Updated by Davide Pesavento over 4 years ago

Junxiao Shi wrote:

One NdnlpPacket can combine multiple network layer packets. This could be useful if the link prefers large frames, but network layer packets are small.

Current fragmentation design doesn't combine small packets, but I intend to keep this possibility as an extension option.

Ok, that should be called "aggregation" or something like that. In any case, please explain in little more detail that this could be supported too, as it can be easily confusing.

Looking at features designed in the slides, suppose a host doesn't understand each field, fragmentation is the only feature that can cause major problem if not understood.

If a host doesn't understand fragmentation and ignores those TLVs, it probably won't be able to parse the rest of the packet anyway because it's just a fragment, so the network-level result would still be a drop.

Alternatively, we could make fragmentation (and only fragmentation) support mandatory, and everything else optional. (with "support" I mean that every host must understand what the relevant TLVs mean, it doesn't mean that the host has to be able to perform fragmentation itself)

The question is what to do on a multi-access link.

If hosts MUST drop packets with unknown fields, assuming we could do negotiation (which itself could be harmful in terms of security), the group would have to operate with the feature set of the least capable host. Furthermore, if a new group member with less features joins the group, existing communication would have to downgrade.

I wouldn't rely too much on negotiation, as it's unfeasible in highly dynamic wireless topologies.

Related: How to handle unrecognized TLVs in network layer packets:

IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)

Ah yeah I forgot about this. But can we do it without renumbering existing TLVs?

#13 Updated by Junxiao Shi over 4 years ago

Looking at features designed in the slides, suppose a host doesn't understand each field, fragmentation is the only feature that can cause major problem if not understood.

If a host doesn't understand fragmentation and ignores those TLVs, it probably won't be able to parse the rest of the packet anyway because it's just a fragment, so the network-level result would still be a drop.

Not necessarily, because a slice of some arbitrary network layer packet could still be a valid network layer packet, especially after encapsulation is invented.

Although these network layer packets are unlikely to be useful (eg. host has no route to forward, and no PIT entry to satisfy), they can confuse forwarding.

Alternatively, we could make fragmentation (and only fragmentation) support mandatory, and everything else optional. (with "support" I mean that every host must understand what the relevant TLVs mean, it doesn't mean that the host has to be able to perform fragmentation itself)

There could be multiple fragmentation designs.

Requiring a host to understand fragmentation implies that the host must know the TLV types of fields from all existing and future fragmentation designs.

One way to achieve that is to reserve a "ignore vs drop" bit similar to below, and then assign "drop" TLV types to fragmentation headers, assign "ignore" TLV types to other headers.

Related: How to handle unrecognized TLVs in network layer packets:

IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)

Ah yeah I forgot about this. But can we do it without renumbering existing TLVs?

NDNLPv2 wire format isn't required to be compatible with existing link protocols, so I won't worry about renumbering.

If you are talking about network layer, it's out of scope of this issue, please discuss on nfd-dev.

#14 Updated by Davide Pesavento over 4 years ago

  • Related to Task #2763: NDNLPv2: NACK, Fragmentation, NextHopFaceId, CachePolicy, IncomingFaceId added

#15 Updated by Junxiao Shi over 4 years ago

The following parts have been reviewed during NFD calls:

#16 Updated by Jeff Thompson over 4 years ago

#17 Updated by Junxiao Shi over 4 years ago

#18 Updated by Junxiao Shi over 4 years ago

As of 20150513, all features have been reviewed, but some are not yet approved.

#19 Updated by Junxiao Shi over 4 years ago

#20 Updated by Junxiao Shi about 4 years ago

Design document is updated to reflect packet format changes during #2763.

#21 Updated by Junxiao Shi about 4 years ago

Design is updated in the following areas:

  • "Motivation" page is added.
  • "ARQ reliability" is renamed to "repeat request", because the term "ARQ" is ambiguous, and repeat request is just one kind of ARQ.
  • NackReason uses a NackReason element with a code. Other TLVs can be appended after NackReason under Nack header field.
  • List of NackReasons is updated to match #3032 note-2.

#23 Updated by Junxiao Shi over 3 years ago

  • Target version changed from v0.4 to v0.5

This is to remain open until all planned features are approved.

#24 Updated by Junxiao Shi over 3 years ago

  • Status changed from In Progress to Closed
  • Target version changed from v0.5 to v0.4
  • % Done changed from 70 to 100

Loss detection (failure detection and reliability) feature design is re-assigned to Eric.

Thus there's nothing left in this issue.

#25 Updated by Junxiao Shi over 3 years ago

  • Blocks Task #3437: NDNLPv2 loss detection design added

Also available in: Atom PDF