<div dir="ltr"><div dir="ltr">Dear folks<div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> 1/ I didn't realize that NDNLP has this hard-coded seq# field -- this is really not IoT friendly.  Why not TLV?<br>
<br>
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.<br>
<br>
I do agree that this encoding is not IoT friendly at all, especially for low-MTU links.<br></blockquote><div><br></div><div>The protocol says:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote">Bit width of the sequence number is determined on a per-link basis, 8 octets are recommended for today's links. </div></blockquote><div class="gmail_quote"><div><br></div><div>TLV-LENGTH of sequence number field is determined per link.</div><div>"8 octets" is optimized for Ethernet and IP overlay links, at speeds between 1Mbps and 1Tbps.</div><div><br></div><div>Other sizes are certainly possible, but it will require prior agreement or a negotiation mechanism.</div><div>"NDNLPv2 supported feature advertisement" <a href="https://redmine.named-data.net/issues/2929">https://redmine.named-data.net/issues/2929</a>  would provide a negotiation mechanism.</div><div><br></div><div><div>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.</div><div>It also worsens performance, as reported on <a href="https://redmine.named-data.net/issues/4403">https://redmine.named-data.net/issues/4403</a> regarding a noncompliant implementation.</div><div><br></div><div>Sender and receiver MUST agree on the counter size, regardless of how it's encoded.</div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div><br></div><div>This above answer pertains to the "indexed fragmentation" method. There are, of course, completely different ways to do fragmentation and reassembly.</div><div>The beauty of NDNLP is that it's fully extensible. Other fragmentation protocols can be defined using a different TLV-TYPE number.</div><div>Obviously, prior agreement or negotiation will be needed to select which fragmentation protocol to use.</div><div><br></div><div></div></div><div>Yours, Junxiao</div></div></div>