Re: [dtn-interest] Re(2): [dtn-dev] discussion draft

[Wesley Eddy <[e-mail]>]

On Fri, Mar 30, 2007 at 02:18:24PM -0700, Scott Burleigh wrote:
> 
> [Practically speaking, your 9-byte limit is fine.  Technically, though, 
> the limit in the BP spec means "any number that can be encoded in 64 
> bits", and in order to encode a 64-bit integer in an SDNV I think you 
> actually need 10 bytes.  You can put up to 7 significant bits in each 
> octet, which means you can get a 63-bit integer into (63 / 7) = 9 
> octets, but for a 64-bit integer you need the low-order bit of one 
> additional octet.]
> 


Ah, right, thanks for the correction; it's the old SDNV-8/16 scheme
where 9 bytes gets you exactly 64 value bits.  I guess code that only
supports 9-byte encodings doesn't have to be as careful when parsing,
but code that supports 10-byte encodings have to do a little extra
checking to make sure the value is in-bounds.

I guess the point I wanted to make was not related to the specific
length, but rather that we just have to be very careful with language
because making statements about "64-bit SDNVs", when we really mean
"64-bit SDNV values" could lead to mis-communication and difficult to
find interop problems.  I think the docs are alright with regards to
this, but we should also be precise about this in emails, papers, and
other communication since implementations often draw on a lot more (or
less) than just the specs alone ...

64-bit values are right in the area where new-style SDNVs start to get
less efficient, but this has been discussed a few times here and is
summed up pretty well in the table in:
http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt

-- 
Wesley M. Eddy
Verizon Federal Network Systems