RE: nsec++

["Andrew Draper" <ADRAPER@altera.com>]

Roy,

The algorithm for calculating the smallest RR is very simple.  It's something like this:

next = 0;
while (there are types with a value >= next)
{
	start = first active type with a value of next or more
	start = start - (start % 32); // round down to multiple of 32

	Create a temporary bitmap containing all types from start to start + 255
	length = 32

	Trim zero octets off the end of the bitmap, reducing length as you do

	Look for three consecutive zeros in the bitmap, at byte offsets 1, 5, 9 etc.
	If you find one then set the length of the bitmap to the address at which
      you found it.

	Output the bitmap, specifying the start address and the length.
	next = start + length * 8
}

I could write it in real C, but I'm sure you get the idea.  Of course the algorithm above could be optimised for processing time.

This looks like a trivial piece of code to me, it certainly isn't discrete mathematics.

If small RRDATA size isn't considered important then I'll shut up, but my experience is that one of the things holding DNSSEC back is that users think it causes enormous increases in packet size.  Putting a bit of thought into saving some bytes seems worth it to me.

Regards,
    Andy




> -----Original Message-----
> From: Roy Arends [mailto:roy@logmess.com]
> Sent: 04 December 2003 16:02
> To: Andrew Draper
> Cc: Jakob Schlyter; IETF DNSEXT WG
> Subject: RE: nsec++ 
> 
> 
> On Thu, 4 Dec 2003, Andrew Draper wrote:
> 
> > Roy,
> >
> > I think the maximum size of my encoding is the same as the 
> one specified
> > in version 0 of the draft.  Use 256 blocks, each 34 octets 
> long, gives
> > 8704 octets total.
> >
> > All I suggest changing is to allow the start value of each 
> block to be
> > on a multiple of 32 instead of a multiple of 256.
> 
> So the worst case scenario would not be that different. The 
> 'multiplier'
> would now be 32 instead of 256, where you'd have a special graph-like
> algortihm to determine the most optimized presentation.
> 
> You'd have to calculate all possible encodings to determine 
> which one is
> the shortest.
> 
> I don't think RDATA size is really that important to allow 
> for discrete
> mathematics to determine the shortest representation.
> 
> The current one (nsec++) satisfies all requirements. Yours adds
> complexity.
> 
> Roy
> 

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>