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

[Scott Burleigh <[e-mail]>]

Wesley Eddy wrote:
> 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 ...
>   
You're right, Wes, it's easy to lapse into a verbal shorthand that 
introduces ambiguity.  We do need to be careful when we use these terms.
> 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
>   
Yes, this was the (small) downside to moving from the old SDNV-8/16 
scheme to what we're using now.  There are cases that are less 
bit-efficient, but that has seemed a reasonable price to pay for the new 
system's simplicity and flexibility.

Scott