Subject: Re: [rohc] ROHC-TCP and EPIC-LITE

From: Julije Ozegovic <[email-masked]>
Date: Thu, 07 Nov 2002 16:15:18 +0100

William,

there is a difference between EPIC and EPIC-Lite. EPIC is IPR 
covered technique that codes finite set of possible headers with 
hierarchical Huffman code, while EPIC-Lite uses only plain 
Huffman to identify chosen format.

At University of Split we have so far covered only EPIC-Lite 
compression.

Please, refer to most recent issues of EPIC and EPIC-Lite 
drafts, because recently lot of development took place. Myself, 
I don't even have a copy of draft-price-rohc-epic-00, actual 
version (as far as I know) is draft-price-rohc-epic-03.

Best regards,
Julije

---------------------------
Julije Ozegovic, PhD
University of Split
FESB Split
R.Boskovica bb
Croatia
tel.++385 21 305725
mailto:[email-masked]
http://www.fesb.hr/~julije
---------------------------

william zheng wrote:
> Hi, Julijie,
> 
> As I read the old file about EPIC-LITE (draft-price-rohc-epic-00), I am 
> confused.
> 
> 1. I understand the Hierarchical Huffman tree is used to generate the 
> codeword after getting M value (P.26-27), which includes the encoding 
> method and its parameters (e.g LSB (k,p), LSB is the encoding method, k, 
> p are parameters), but what the branches (three possible cases 
> as introduced, i.e. 'X', 'D','N') means?
> 
> 2. If we want the M value for tcp-options-co i.e. LIST 
> (...U(OPTIONAL(....), how can we do?
> 
> Could you help me to explain them ? Thanks.
> 
> BR,
> 
> William
> P.S. Currently I start to implement ROHC-TCP using EPIC-LITE as encoding 
> framework. I hope I can have your help if possible.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> MSN 8 with e-mail virus protection service: 
> <http://g.msn.com/8HMWEN/2019> 2 months FREE*

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 7 Nov 2002 17:29:26 -0000

Hi William,

I'm impressed that you managed to find a copy of the very first
EPIC draft! The scheme has undergone many changes since the
original draft - with any luck making it a lot simpler and
easier to implement.

The very latest version of the scheme can be found in:

http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-00.txt

This draft defines a notation for describing the behaviour of
a protocol stack - both EPIC and EPIC-LITE use this information
to generate sets of compressed packet formats.

The notation was previously included in the EPIC-LITE draft
itself, but we split it out as it makes sense to keep the
solution as modular as possible. An updated version of
EPIC-LITE minus the notation will be published shortly.

If you're thinking about implementing EPIC-LITE then it would
be great if you could take a look at the new notation draft
and let the WG know if you find any mistakes or ambiguities.

Regards,

Richard

> -----Original Message-----
> From: Julije Ozegovic [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 3:15 PM
> To: william zheng
> Cc: [email-masked]
> Subject: Re: [rohc] ROHC-TCP and EPIC-LITE
> 
> 
> William,
>

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 8 Nov 2002 10:42:20 -0000

Hi William,

>Now about your question. The format of EPIC-lite frame is as 
>follows:
>
>+---------+--------------+--+-----------+--+----------------+
>|ID_bits  |Compr. header |P1|UNC_fields |P2|Payload         |
>+---------+--------------+--+-----------+--+----------------+
>
>UNC_fields is accssed (assuming U method is used) field by field 
>using data from PRESENCE and ORDER fields located in Compressed 
>header (after LIST). So it is true that Payload position is not 
>known apriori, but is well known after the Compressed header 
>processing. We just advance UNC_fields read pointer and consider 
>Payload starting at next byte boundary. The same mechanism is 
>used for UNCOMPRESSED method.
>

This is true, however, I'll explain OPTIONAL in a bit more detail here.  

ID_bits explicitly give the methods which have been used to compress the header.  Each method has a known number of bits that goes into Compr. header (which is zero for UNCOMPRESSED and U).  If a group of fields is inside OPTIONAL and is not present in the uncompressed header, then an arbitrary choice of methods is made and n bits of padding (where n is the number of bits known to go with that choice, and the padding is defined to be zero) are put into Compr. header in the correct place.  The decompressor removes and ignores these bits.

For example, if I have an IRREGULAR(8,100%) encoding then whether or not it appears inside an OPTIONAL it will occupy 8 bits - it's just that the 8 bits in the compressed header are ignored if the OPTIONAL field is not present.  Clearly when encoding something inside an OPTIONAL rule that is not present, I want to choose an encoding with zero bits (if possible).

This means that the length of Compr. header is known, as is the number of bits of P1.  If the profile doesn't contain U or UNCOMPRESSED then unc_fields is empty; so P2 is zero bits wide and the position of the payload is known.

If UNCOMPRESSED is used then the length of Compr. header doesn't change.  A field earlier in the header than the one to be sent UNCOMPRESSED specifies the length of the uncompressed data.  This length is compressed after the data from UNCOMPRESSED has been put on unc_fields.  This means that at the decompressor you can decode the ID_bits, know the length of Compr. header and P1 and so know the position of unc_fields (but not at this point the position of the payload).  When the header is decompressed the length of data on unc_fields will be decompressed before the UNCOMPRESSED method is reached.  When the UNCOMPRESSED method is reached the decompressor knows the length of data to remove from the unc_fields stack.  When decompression of the header is complete the unc_fields stack should be empty and P2 can be removed as the payload should be byte aligned.

So where does U fit?  U is a method that allows methods of known length to be excluded from Compr. header and the data to be put on the unc_fields stack in the same way as for UNCOMPRESSED (the length comes from the method rather than from a decompressed field value). 
 
One place where this is particularly useful (and has slightly different behaviour) is that of U(OPTIONAL(x)).  If the fields within OPTIONAL are present the data gets put on unc_fields as with any other method.  Unlike the compressed header, unc_fields can be variable length.  Consequently OPTIONAL does not need to add padding bits when it is within a U method.  For groups of optionally present fields for which the padding cannot be zero bits (e.g. tcp timestamp) it is more efficient to use U than to frequently (when the option isn't present) add large amounts of padding which is ignored at the decompressor.  

I hope this clarifies things.  Basically, you can always know the length of Compr. header and P1 as soon as ID_bits have been decoded and decompression uses up unc_fields as it goes leaving you with P2 (known to be less than 1 byte) and the payload.

Note: 
In the new notation draft, OPTIONAL remains the same, UNCOMPRESSED has changed its name to UNCOMPRESSIBLE and U is not mentioned.  The notation is about describing the protocol stack and mappings between uncompressed and compressed field values.  However, it makes no statements or assumptions about the format of the bits on the wire.

Best regards,

Abbie

Abbie Surtees
Engineer
Internet Applications and Mobility
Roke Manor Research Ltd
Tel:   +44 (0) 1794 833131

>NOTE: While padding P1 is covered in draft, padding P2 is not, 
>so we just fill it with zeroes at the compressor, and ignore it 
>in decompressor.
>
>Best regards,
>Julije Ozegovic
>
>zheng_william wrote:
>> Hi, all,
>> Is anyone interested in implementation of ROHC-TCP with EPIC-LITE as 
>> coding framework?
>>  
>> I happen to have a question about splitting the compressed 
>header packet 
>> into compressed header and the payload before decompressing 
>the fields 
>> (procedure  READ-FLAGS, P. 54-56 in 'Framework for 
>EPIC-LITE'). As LIST 
>> encoding method is used in ROHC-TCP (P. 39, 
>draft-ietf-rohc-tcp-02.txt), 
>> the compressed bits length may be unable to decide (e.g OPTIONAL 
>> encoding method is used, see the example as follows,
>> tcp-options-co = ROTATE(3,1);
>>                         LIST (4,1,32,-160,8, 
>U(OPTIONAL(tcp-sack-co), ...).
>> Therefore, the compressed header length may be unavailable through 
>> calling the function get-header-length (the precodure 
>READ-FLAGS, P. 56, 
>> 'Framework for EPIC-LITE'). Is it right? 
>>  
>> BR,
>> William
>>  
>>  
>
>

---

From: Julije Ozegovic <[email-masked]>
Date: Fri, 08 Nov 2002 14:26:22 +0100

Hi William,

PEBBLE is official IETF draft, it is concerned for draft 
standardization as RFC, and future implementations should 
consider PEBBLE.

However, PEBBLE is syntax-only specification, it does not imply 
actual implementation model, like EPIC-Lite does. So, to make 
functional implementation, you must choose PEBBLE/ROHC or 
PEBBLE/EPIC-Lite model. Or, to wait until whole situation clears 
up. Or to proceed with EPIC-Lite, and later upgrade with PEBBLE 
preprocessing.

Best regards,
Julije Ozegovic

william zheng wrote:
> Hi, julije & Abbie,
> 
> Both are very impressive description on my question.
> 
> Could you tell me when to finalize the encoding framework for ROHC-TCP, 
> using EPIC-LITE ( there is no update version now ) or further based 
> on the new draft proposed by Roke Manor i.e. PEBBLE ?
> 
> Thanks.
> 
> Best Regards,
> 
> William
> 
> 
> 
> 
>  
>  >From: "Surtees, Abigail"
>  >To: [email-masked], zheng_william
>  >Subject: RE: [rohc] ROHC-TCP and EPIC-LITE
>  >Date: Fri, 8 Nov 2002 10:42:20 -0000
>  >
>  >Hi William,
>  >
>  >ID_bits explicitly give the methods which have been used to compress 
> the header. Each method has a known number of bits that goes into Compr. 
> header (which is zero for UNCOMPRESSED and U). If a group of fields is 
> inside OPTIONAL and is not present in the uncompressed header, then an 
> arbitrary choice of methods is made and n bits of padding (where n is 
> the number of bits known to go with that choice, and the padding is 
> defined to be zero) are put into Compr. header in the correct place. The 
> decompressor removes and ignores these bits.
>  >
>  >For example, if I have an IRREGULAR(8,100%) encoding then whether or 
> not it appears inside an OPTIONAL it will occupy 8 bits - it's just that 
> the 8 bits in the compressed header are ignored if the OPTIONAL field is 
> not present. Clearly when encoding something inside an OPTIONAL rule 
> that is not present, I want to choose an encoding with zero bits (if 
> possible).
>  >
>  >This means that the length of Compr. header is known, as is the number 
> of bits of P1. If the profile doesn't contain U or UNCOMPRESSED then 
> unc_fields is empty; so P2 is zero bits wide and the position of the 
> payload is known.
>  >
>  >If UNCOMPRESSED is used then the length of Compr. header doesn't 
> change. A field earlier in the header than the one to be sent 
> UNCOMPRESSED specifies the length of the uncompressed data. This length 
> is compressed after the data from UNCOMPRESSED has been put on 
> unc_fields. This means that at the decompressor you can decode the 
> ID_bits, know the length of Compr. header and P1 and so know the 
> position of unc_fields (but not at this point the position of the 
> payload). When the header is decompressed the length of data on 
> unc_fields will be decompressed before the UNCOMPRESSED method is 
> reached. When the UNCOMPRESSED method is reached the decompressor knows 
> the length of data to remove from the unc_fields stack. When 
> decompression of the header is complete the unc_fields stack should be 
> empty and P2 can be removed as the payload should be byte aligned.
>  >
>  >So where does U fit? U is a method that allows methods of known length 
> to be excluded from Compr. header and the data to be put on the 
> unc_fields stack in the same way as for UNCOMPRESSED (the length comes 
> from the method rather than from a decompressed field value).
>  >
>  >One place where this is particularly useful (and has slightly 
> different behaviour) is that of U(OPTIONAL(x)). If the fields within 
> OPTIONAL are present the data gets put on unc_fields as with any other 
> method. Unlike the compressed header, unc_fields can be variable length. 
> Consequently OPTIONAL does not need to add padding bits when it is 
> within a U method. For groups of optionally present fields for which the 
> padding cannot be zero bits (e.g. tcp timestamp) it is more efficient to 
> use U than to frequently (when the option isn't present) add large 
> amounts of padding which is ignored at the decompressor.
>  >
>  >I hope this clarifies things. Basically, you can always know the 
> length of Compr. header and P1 as soon as ID_bits have been decoded and 
> decompression uses up unc_fields as it goes leaving you with P2 (known 
> to be less than 1 byte) and the payload.
>  >
>  >Note:
>  >In the new notation draft, OPTIONAL remains the same, UNCOMPRESSED has 
> changed its name to UNCOMPRESSIBLE and U is not mentioned. The notation 
> is about describing the protocol stack and mappings between uncompressed 
> and compressed field values. However, it makes no statements or 
> assumptions about the format of the bits on the wire.
>  >
>  >Best regards,
>  >
>  >Abbie
>  >
>  >Abbie Surtees
>  >Engineer
>  ><< RMRL-Disclaimer.txt >>
> 
> MSN 8 helps ELIMINATE E-MAIL VIRUSES. <http://g.msn.com/8HMQEN/2023> Get 
> 2 months FREE*.

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 11 Nov 2002 13:58:50 -0000

Hi Julije,

Yes, ultimately, bits on the wire are all that count but defining the (reversible) mappings between uncompressed and compressed field values is critical.  A formal notation can cover this part and applying the encoding rules (to turn this into packets) is not a large part of the whole process, as can be seen in the following diagram:

|<-----------generating compressed field values---------->|<-packet format->|

			   protocol 
		    ----description -------
		   |				  |
		   |				  |
 ---------     V    --------------    V	  --------------         --------
| header  | -----> | uncompressed | -----> | compressed   | ----> | packet |
|	    |		 | field values |        | field values |   ^	| format |
 ---------          --------------          --------------    |    --------
										  |
									    encoding
										rules
									 (as yet undefined)

As you can see, it is possible to get as far as the compressed field values using the formal notation, and the expired feb-02 EPIC-lite draft defines encoding rules which could work with this if you need an implementation before the encoding rules are agreed.

All of this would need to be defined in a profile to be inserted into the ROHC framework.

Best regards,

Abbie

>Sent: 11 November 2002 10:12
>To: Surtees, Abigail
>Cc: william zheng; [email-masked]
>Hi Abbie, William,
>this is exactly what I have said: at the moment we do not have 
>explicit standard how to implement PEBBLE to actual ROHC or 
>EPIC-Lite model, assuming EPIC-Lite is a refinement under the 
>ROHC framework.
>
>For interoperability, "bits on the wire" is all that counts!
>
>Best regards,
>Julije
>
>Surtees, Abigail wrote:
>> Hi Julije, William,
>> The working group has agreed that this approach to header 
>compression can be split into
>> - a formal notation for describing a protocol header and 
>> - the encoding rules for mapping from the compressed 
>information to 'bits on the wire' (defining packet formats 
>e.g. EPIC-lite).  
>> The formal notation is deliberately abstract from an 
>implementation, to give maximum implementation freedom.  The 
>key issue is interoperability, which means having a formal 
>definition of what the mappings between compressed and 
>uncompressed field values mean.
>> 
>> I'm not sure what you mean by PEBBLE/ROHC and 
>PEBBLE/EPIC-lite?  EPIC-lite is an algorithm for generating 
>packet formats from a formal description.  ROHC encompasses a 
>complete framework for compression, as well as a number of 
>profiles.  EPIC-lite is one possible way of generating the 
>packet formats to go with a particular profile in this 
>framework, so there is no 'choice' between ROHC and EPIC-lite.
>> 
>> The current focus of work is on the notation, because 
>without that it is difficult to define packet formats (or the 
>means of generating them).  The packet format generation is a 
>relatively small part of the whole process.  As work is 
>ongoing and the current focus is the notation, it would be 
>better to comment on and implement the formal notation for 
>parsing and compressing field values, and then put the packet 
>generation on afterwards when that has been agreed.
>> 
>> Best regards,
>> 
>> Abbie
>> 
>> 
>>>Sent: 08 November 2002 13:26
>>>To: william zheng
>>>Cc: [email-masked]
>>>Registered Office: Roke Manor Research Ltd, Siemens House, 
>Oldbury, Bracknell, 
>>>Berkshire. RG12 8FZ
>>>
>>>The information contained in this e-mail and any attachments 
>is confidential to Roke 
>>>Manor Research Ltd and must not be passed to any third party 
>without permission. This 
>>>communication is for information only and shall not create 
>or change any contractual 
>>>relationship.
>> 
>
>