Subject: Re: [dtn] RFC 6260 Compressed Bundle Header Encoding (CBHE)

From: Brendan A R Sechter <[email-masked]>
Date: Mon, 29 Feb 2016 20:46:01 -0600

Scott-

Replying to a mailing list, just in case anyone else is interested.

> For now I think we’re okay: a big part of the reason for CBHE is to
> be able to use ulongs instead of strings to store these identifiers
> (for a host of reasons), and that purpose would be defeated if identifiers
> occupying more than 64 bits were authorized by the specification.

>From the practical standpoint of getting things done now, a 64 bit
representation makes sense.  Without knowing the reasons why 64 bit ulong
was chosen, I am not convinced using a 128 bit representation will be a big
deal in the future.  Transitioning is a separate issue.

Not that it is a priority, but theoretically does typedef-ing something
like an ipn_eid_t make sense?

> In that spec I will say something to the effect that node and service
> numbers SHOULD (rather than MUST) be no more than 64 bits in
> length, and why.  After which I think we can just let the future happen,
> and produce new superseding RFCs in a few years when and if that
> becomes necessary.  How does that sound?

That sounds reasonable.

The same physical object can conceptually live at the node, service or
service dependency level.  This could be used to conserve nodes or
services.  To use a sensor in a car as an example.
ipn:myCarOilSensorNode.oilLevelService  // uses more nodes
ipn:myCarNode.iolSensorService/oilLevel
ipn:myHouseholdNode.myCarService/iolLevel  // uses more services

ipn:node.service is a lot like host:port.  Should all installations of a
service use the same number?  If so, what if a node runs multiple copies of
the same service?

The rest of message will largely delve into the realm of fantasizing about
big numbers.

IPv6 is a scheme with 2^128 addresses so 2^128 available names seems
reasonable.  Name to address mapping is not necessarily 1 to 1.  More than
one person can live at the same address.  One person can have multiple
addresses.  Most of the people I know have exactly 1 address most of the
time.  They may briefly have 0 or 2 addresses when moving.

128 bits of namespace is unambiguously enough if used efficiently.  64 bits
of node namespace is unambiguously enough for a long time.  Superseding
RFCs will almost certainly be unnecessary in just a few years time.  My
concern is that almost good enough can be one of the worst places to be
from an engineering standpoint.

8 billion is the lowest global peak population projection I have read-
almost 2^33.  High projections put peak population at some 34 bit number.
At a 34 bit population, 65 bits of nodes would require over 2 billion
(2^31) named devices per person.  I am having trouble visualizing 2 billion
nodes per person- devices, sensors, supporting infrastructure.

Exponential population growth combined with an exponential growth in
devices per person could exceed 64 bits.  2^16 worlds with populations of
2^34 and 2^16 devices per person is 66 bits.  2^50 is about 10^15.  This is
well within back of the envelope estimates I have read for the theoretical
maximum number of people the solar system can support.  Possible?  Maybe.
Likely?  No clue, but easier for me to visualize than 2 billion devices per
person.

Once technology is standardized and infrastructure investments have been
made, there is an incentive to use what exists until it needs to be
replaced.  Avoiding another Y2K or IPv4 situation in the future is ideal.
Having ~2^64 obsolete devices could be a disaster.  The more mundane
reality is probably that unupgradable devices will simply be unable to
communicate with node IDs that require more than 64 bits.  Everything needs
to be replaced eventually and they could be replaced at end of life.

Regards,
-Brendan

On Mon, Feb 29, 2016 at 12:27 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

> A fair question, Brendan.  For now I think we’re okay: a big part of the
> reason for CBHE is to be able to use ulongs instead of strings to store
> these identifiers (for a host of reasons), and that purpose would be
> defeated if identifiers occupying more than 64 bits were authorized by the
> specification.  But you’re right, it is important to try to future-proof
> the protocol as much as we can.
>
>
>
> I think the answer lies in the new BP specification structure: we no
> longer specify the bit representation of EIDs (or anything else) in the BP
> spec, delegating that work instead to an open-ended population of
> representation specs.  I think the CBHE concept will be subsumed in that
> delegation.  That is, I will be trying to get a BP representation spec out
> in the next few weeks that lays out a CCSDS-oriented bit representation of
> the abstract protocol data items in the BP spec, retaining the SDNV concept
> and making CBHE the standard (rather than a convergence-layer option) for
> ipn-scheme EIDs.  In that spec I will say something to the effect that node
> and service numbers SHOULD (rather than MUST) be no more than 64 bits in
> length, and why.  After which I think we can just let the future happen,
> and produce new superseding RFCs in a few years when and if that becomes
> necessary.  How does that sound?
>
>
>
> Scott
>
>
>
> *From:* Brendan A R Sechter [mailto:[email-masked]]
> *Sent:* Sunday, February 28, 2016 11:21 AM
> *To:* Burleigh, Scott C (312B) <[email-masked]>
> *Subject:* Re: RFC 6260 Compressed Bundle Header Encoding (CBHE)
>
>
>
> Scott-
>
>
>
> Just to pose the question, is 64 bits enough for the node and service
> number?  32 bits for IPv4 turned out to be a limitation.  2^64 is about
> 18.4 * one billion squared (or 2^4*2^30*2^30).  Current global population
> is about 7.4 billion (~2^2.8*2^30).
>
>
>
> CBHE gracefully scales without a hard bit cap.  64 bit processors are
> state of the art now.  Storage for terrestrial applications is cheap now.
> Would it make sense to use a wording that allows scaling to a 128+ bit
> "word size" if that needs to happen in the future?  Alternatively or in
> addition, does is make sense to pull the hard cap out of the CBHE
> definition and put it into something with a version number?
>
>
>
> Regards,
>
> -Brendan
>