[Nfd-dev] NDNLPv2 and NDN-RIOT L2 fragmentation

[Junxiao Shi]

Dear folks


> > 1/ I didn't realize that NDNLP has this hard-coded seq# field -- this is
> really not IoT friendly.  Why not TLV?
>
> Let me try to clarify. The NDNLPv2 "Sequence" field *is* a TLV element,
> but its value is a fixed 8 bytes, not a variable-length nonNegativeInteger.
> In addition to the Sequence field, NDNLPv2 fragmentation also uses the
> FragIndex and FragCount TLV elements, both of which have nonNegativeInteger
> values.
>
> I do agree that this encoding is not IoT friendly at all, especially for
> low-MTU links.
>

The protocol says:

Bit width of the sequence number is determined on a per-link basis, 8
octets are recommended for today's links.


TLV-LENGTH of sequence number field is determined per link.
"8 octets" is optimized for Ethernet and IP overlay links, at speeds
between 1Mbps and 1Tbps.

Other sizes are certainly possible, but it will require prior agreement or
a negotiation mechanism.
"NDNLPv2 supported feature advertisement"
https://redmine.named-data.net/issues/2929  would provide a negotiation
mechanism.

Using nonNegativeInteger will NOT solve the problem: the sender can still
increment the sequence number counter to above 2^32, and then the field
becomes 8 octets.
It also worsens performance, as reported on
https://redmine.named-data.net/issues/4403 regarding a noncompliant
implementation.

Sender and receiver MUST agree on the counter size, regardless of how it's
encoded.
If a sender assumes uint32 counter but a receiver assumes uint64 counter,
even if the encoding is nonNegativeInteger, the protocol would not operate
correctly: the sender would transmit two fragments of a network layer
packet with sequence numbers 0xFFFFFFFF and 0x00000000, but the receiver
would expect the second fragment to have sequence number 0x0000000100000000.

One solution that does not need negotiation is: let the sender choose
whatever bit width it wants to use, and the receiver should assume the
sender's sequence number counter has this width.
If the above example, if the sender uses a uint32 counter, it would encode
the first sequence number as 0xFFFFFFFF in a 4-octet field, so that the
receiver will expect the next sequence number to be 0x00000000; if the
sender uses a uint64 counter, it would encode the first sequence number as
0x00000000FFFFFFFF in a 8-octet field, so that the receiver will expect the
next sequence number to be 0x0000000100000000.
A sender is not supposed to change the TLV-LENGTH of its sequence number
field. If that happens, the receiver SHOULD discard the reassembly buffer
and restart the reassembler with the new sequence number width.
A receiver implementation can specify, in its documentation, what
TLV-LENGTHs it's willing to accept. Two implementations are interoperable
when the sender uses a bit width that is acceptable to the receiver.


This above answer pertains to the "indexed fragmentation" method. There
are, of course, completely different ways to do fragmentation and
reassembly.
The beauty of NDNLP is that it's fully extensible. Other fragmentation
protocols can be defined using a different TLV-TYPE number.
Obviously, prior agreement or negotiation will be needed to select which
fragmentation protocol to use.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191204/e3a549e9/attachment-0001.html>