[Nfd-dev] NDNLP Seq Number Length

Junxiao Shi shijunxiao at email.arizona.edu
Wed Jan 18 15:03:40 PST 2017


Hi Klaus

NDNLPv2 spec does not require the Sequence number field to have a specific
width. It's a per-link decision.

Sequence contains a sequence number that is useful in multiple features.
This field is REQUIRED if any enabled feature is using sequence numbers,
otherwise it's OPTIONAL.
Bit width of the sequence is determined on a per-link basis; 8-octet is
recommended for today's links.
A host MUST generate consecutive sequence numbers for outgoing packets on
the same face.


To choose the Sequence width on a link, one should consider a trade-off
between
(1) the Sequence should be wide enough to avoid wrapping sooner than a few
RTTs;
(2) the bandwidth consumption of the Sequence field, especially on low-MTU
links.

The recommendation of 8-octet applies to most links in Internet
infrastructure, home Internet access, data center, etc.
Sensor networks and personal area networks may need shorter Sequence field.
Core Internet (100Gbps or above) may need longer Sequence field.

Yours, Junxiao

On Fri, Jan 13, 2017 at 5:24 PM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> Hi Junxiao,
>
> the NDNLP Wiki describes a sequence number as 32bit (
> https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2), but in the
> code it's 64 bit:
>
>
>> #45 Updated by Eric Newberry about 6 hours ago
>>
>> Klaus Schneider wrote:
>>
>> Minor point: The NDNLP Spec. says that the sequence number is a
>> "fixed-width unsigned integer", the ACK number however is "64-bit
>> non-negative integer".
>>
>> Shouldn't it be the same length?
>>
>> Good catch. In the current implementation of NDNLP, a Sequence is defined
>> as a uint64_t. I corrected the slides to use the NDNLP notation.
>>
>
>
> Should we change the Wiki Entry to 64 bit?
>
> Best regards
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170118/8cd9039e/attachment.html>


More information about the Nfd-dev mailing list