NFD

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.

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.

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.

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

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).

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.

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)

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?

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.

For information: according to A. Compagno, M. Conti, C. Ghali, G. Tsudik,
To NACK or not to NACK? Negative Acknowledgments in Information-Centric Networking,
arXiv: 1503.02123, March 7, 2015, HMAC integrity is useful in securing network-layer NACKs.