Re: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)

Michael Demmer <demmer@cs.berkeley.edu> Wed, 25 May 2005 16:37 UTC

Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4PGb7V31139; Wed, 25 May 2005 09:37:07 -0700
Received: from demmer by pisco with local (Exim 4.50) id 1DaysV-00048E-GF; Wed, 25 May 2005 09:37:07 -0700
Date: Wed, 25 May 2005 09:37:07 -0700
From: Michael Demmer <demmer@cs.berkeley.edu>
To: dtn-security@mailman.dtnrg.org
Cc: dtn-dev@mailman.dtnrg.org
Subject: Re: SDNV-new (was: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.)
Message-ID: <20050525163707.GB14911@pisco.cs.berkeley.edu>
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <42949E83.9050000@cs.tcd.ie>
User-Agent: Mutt/1.4.2i
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

> I guess this could work ok. Whether its better or worse
> than sdnv-8/sdnv-16 depends on the frequency with which
> we're encoding values in the range 4096-65535, 

Actually, not quite. See below...

> and of course, my code currently does the -8/-16 thing, so if
> we're making this change, we'll want to do it in LTP
> at the same time.

That'd be fine with me of course.

> Also - can you give some more examples of values
> and how they're encoded - the description is a bit
> opaque.

Ok, here's some arbitrary examples that express some of the various
cases. Note that for the discriminator byte of the SDNV binary, I put
in a .  character to separate the relevant pieces.

value	       hex	SDNV hex	SDNV binary
10             0a       0a              0.000.1010
90             5a       5a              0.101.1010
197	       c5	80 c5		1.000.0000 11000101
2099	       833	88 33		1.000.1000 00110011
12345	       3039	90 30 39	1.001.0000 00110000 00111001
456789	       6f855    96 f8 55	1.001.0110 11111000 01010101
123456789      75bcd15  a7 5b cd 15     1.010.0111 01011011 11001101 00010101

So, as I see it, the relevant range is for the values like 2099,
456789, etc in which we encode the high-order nibble in the
discriminator byte itself. With SDNV-8, the value 2099 requires three
bytes, whereas with this scheme it requires only two. Similarly,
456789 would require four bytes with SDNV-8, but only three with this
scheme, etc.

> I don't think its really harder to code up use of
> sdnv-8 or -16 though, nor are coders likely IMO to
> get confused between these as long as we don't
> oscillate between 'em at specification time.

Agreed -- I don't think any one of these schemes is easier and/or
harder to implement. My argument would be to settle on any one, but as
long as we're consistent, I don't really care. 

It does, however, bring a naming question as to what to call this
scheme... I don't think SDNV-new is all that appealing in the long
run.

-m