Subject: Re: [manet] Thoughts about schema-based address compression

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 30 Jan 2013 10:01:01 +0000

It sounds elegant, but I have concerns over the maximum number of addresses per address-block.  But I suppose that if I have more than 14 addresses with a common prefix I can just add more address blocks with identical header information.

Given the restrictions on address length and number of addresses per block, it would be nice if the schema could specify that the address blocks of a schema-compressed message were in uncompressed (RFC5444) format, allowing the 8bit prefix-length and address-count.  I agree that this is a corner case, but people do try to stuff all kinds of data into 'addresses' when they first look at RFC5444 - I can imagine someone using a SHA1 hash as an address - terrible compression, but legitimate in RFC5444.

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Rogge
> Sent: 30 January 2013 08:03
> To: [email-masked]
> Subject: [manet] Thoughts about schema-based address compression
>
> I worked a bit on adding address compression to the schema-based system
> we are discussing at the moment.
>
> The idea is simple:
>
> - A schema can contain up to 14 addresses (up to 16 bytes) in addition
> to information about the message header and TLVs.
>
> - Every address block that use head or tail compression can refer to one
> of these addresses instead of explicitly including the prefix in the
> bytestream.
>
> Both head and tail compression of addresses call for a 1 byte length
> field to define the split between header-, tail- and mid-parts.
>
> Because of the limited address length of 16 bytes these length fields
> only contain numbers between 1 and 15.
>
> My idea is to reuse the "free" four bits of the length field to allow
> the address block to refer to one of the stored addresses or the
> originator of the message.
>
> I think this could be a major help for IPv6 MANETs.
>
> I am still thinking about how to include this idea for the originator
> address.
>
>
>
> Example Schema:
> ---------------
> ...
> Address 1: 10.0.0.0
>
>
>
> Uncompressed address block:
> ----------------------------
> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.),
> no prefix
>
> # <num-addr>
> 03
>
> # <addr-flags> = ahashead
> 80
>
> # <head-length> <head>
> 03 0A 00 00
>
> # <mid>*
> 01 02 03
>
>
> Example for compressed address blocks:
> --------------------------------------
>
> 3 addresses (10.0.0.1, 10.0.0.2, 10.0.0.3), three byte header (10.0.0.),
> no prefix
>
> # <num-addr>
> 03
>
> # <addr-flags> = ahashead
> 80
>
> # <head-length>, refer to schema address 1 for head bytes
> 13
>
> # <mid>*
> 01 02 03
>
>
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Straße 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:[email-masked] http://www.fkie.fraunhofer.de

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Jan 2013 15:20:34 +0100

On 01/30/2013 11:01 AM, Taylor, Rick wrote:
> It sounds elegant, but I have concerns over the maximum number of
> addresses per address-block.  But I suppose that if I have more than
> 14 addresses with a common prefix I can just add more address blocks
> with identical header information.

Its more a limit of different "pre-stored" prefixes for the whole
message. Multiple address blocks can use the same indexed schema-prefix
of course.

> Given the restrictions on address length and number of addresses per
> block, it would be nice if the schema could specify that the address
> blocks of a schema-compressed message were in uncompressed (RFC5444)
> format, allowing the 8bit prefix-length and address-count.  I agree
> that this is a corner case, but people do try to stuff all kinds of
> data into 'addresses' when they first look at RFC5444 - I can
> imagine someone using a SHA1 hash as an address - terrible
> compression, but legitimate in RFC5444.

The extension I suggested is full backward compatible to RFC5444.

if you set the length of your head/tail to 1-15, the compressor will 
just assume the head/tail will follow in the bytestream. If you set a 
number greater than 0 in the first four bits, you say "instead of 
explicitly writing the head/tail, just take it from schema address X".

Have to work out a text that is easier to understand.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 30 Jan 2013 16:21:16 +0100

I have deployments of OLSRv2 right now where (just checked this morning) I see messages with well more than 14 IPv6 addresses (max I saw was 29) with the same TLV. 

Just one datapoint. 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

On 30 janv. 2013, at 11:01, "Taylor, Rick" <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Jan 2013 18:58:05 +0100

Maybe just to add another explanation...

why a maximum of 14 schema-stored heads/tails? Because we have 4 free
bits in the <head/tail-length>.

Why not 15 or 16?

The 0000 is reserved for the default case where the <head/tail> is
stored in the message itself. And I would like to use the 1111 to make
the decompressor take the <head/tail> from the <originator> of the
message.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan