Subject: Re: [manet] RFC5444 schema-based compression - compatibility

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 28 Jan 2013 11:45:33 +0000

Just a few quick ideas for backwards and forwards compatibility between RFC5444 and schema-compression:

If the RFC5444 <pkt-header> is extended to use bit 2 (currently unused/ignored) to indicate that there are further schema-compressed message-blocks AFTER the RFC544 uncompressed message-blocks in the message then backwards compatibility is provided. However, a strictly compliant RFC5444 version 0 parser will error when encountering the extra bytes found after the last version 0 message-block, breaking forwards compatibility (See section 5.1 in RFC5444).

One possibility to maintain forwards compatibility would be to encode each schema-compressed message block as a version-0 packet-TLV, with a reserved packet-level TLV type, and using the tlv-flags to indicate length (the multi-value bits are not used).

Obviously if both ends of a conversation are both version-1 compliaint then using bit-2 in <pkt-header> results in better compression.

My question to the list is: Is forwards compatibility from RFC5444 version 0 important, or are people happy with producing RFC5444-version-1 that is backwards compatible, but will break a purely version-0 complaint parser?

Rick Taylor

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: Mon, 28 Jan 2013 12:55:36 +0100

On 01/28/2013 12:45 PM, Taylor, Rick wrote:
> If the RFC5444 <pkt-header> is extended to use bit 2 (currently
> unused/ignored) to indicate that there are further schema-compressed
> message-blocks AFTER the RFC544 uncompressed message-blocks in the
> message then backwards compatibility is provided. However, a strictly
> compliant RFC5444 version 0 parser will error when encountering the
> extra bytes found after the last version 0 message-block, breaking
> forwards compatibility (See section 5.1 in RFC5444).

I like the idea using the unused packet-header flags bit, but 
unfortunately what you suggest doesn't seem to be possible because there 
is no length field in the packet header.

This means a parser that doesn't know the "compressed" bit will not be 
able to determine how many uncompressed messages are in the packet.

The other problem is that RFC5444 specifies that parsers should IGNORE 
these two unused bits, they do not throw packets away if they are not zero.

> One possibility to maintain forwards compatibility would be to encode
> each schema-compressed message block as a version-0 packet-TLV, with
> a reserved packet-level TLV type, and using the tlv-flags to indicate
> length (the multi-value bits are not used).

This sounds like a waste of bytes for compressed packets. And a bad 
style too.

> Obviously if both ends of a conversation are both version-1
> compliaint then using bit-2 in <pkt-header> results in better
> compression.

Yes.

> My question to the list is: Is forwards compatibility from RFC5444
> version 0 important, or are people happy with producing
> RFC5444-version-1 that is backwards compatible, but will break a
> purely version-0 complaint parser?

I think the compressed version should make a standard compliant RFC5444 
parser to DROP the packet.

For proactive protocols we could define a packet-level protocol which 
can determine if neighbors support compression or not, but this is 
difficult for reactive ones.

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

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 28 Jan 2013 12:16:13 +0000

> these two unused bits, they do not throw packets away if they are not

One potential solution would be to add a NUL message-block (length = 0, 4 bytes) to mark the end of the version-0 message-blocks, and the start of the schema-compressed blocks.  Not nice, and adds 4 bytes, and it still breaks version-0 parsers, but does allow a mix-and-match approach and general-purpose parsers.

Unfortunately there are no unused bits in the message header - these would be ideal for classifying the message-block format.

> This sounds like a waste of bytes for compressed packets. And a bad

Agreed, it's not the nicest solution, but it does allow schema-compressed messages to be handled safely by a pre version-0 parser, at a cost of 3 or 4 bytes per schema-compressed message-block.  This is very much a work-around but it does allow best compatibility.

> > compliaint then using bit-2 in <pkt-header> results in better

And some higher-level negotiation can occur to achieve this.

> parser to DROP the packet.

I'm not sure if there are protocols in the reactive space that would like messages to be forwarded even if they are not understood by the intermediate node, or is that more relevant to optional TKLVs?

> difficult for reactive ones.

As I said above, I think this is out of scope for RFC5444, some higher level protocol can determine this.  Capability negotiation is a real can of worms.  Does the packetbb security RFC go into this at all?

Rick Taylor