Subject: RE: [rohc] Re: comments on draft-west-rohc-formal-notation-00.txt

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Wed, 3 Jul 2002 20:08:31 +0800

Hi, Mark
	see comments inline

Hongbin & Qian
07/03/2002

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2002 5:32 AM
> To: Qian Zhang
> Cc: [email-masked]
> Subject: [rohc] Re: comments on draft-west-rohc-formal-notation-00.txt
> 
> 
> 
> Hi Qian, Hongbin,
> 
> Some more detailed comments!
> 
> Cheers,
> 
> Mark.
> 
> 
> Qian Zhang wrote:
> 
> > Mark,
> > 
> > We had read the draft you submitted for formal notation
> (referred as
> > ROHC-FN later). Here please find some comments about it.
> > 
> > 1. This version still assumes that the uncompressed header
> is stored
> > in uncompress_data (a bit-based stack), each method will
> process the
> > data in uncompress_data sequentially and generate the compressed
> > packet. That means the order of the methods written in the profile 
> > will affect the processing of compression and decompression. If our 
> > understanding is correct, ROHC-FN will affect how to generate the 
> > actual compressed header formats (compression_stack in ROHC-FN) in 
> > some extent. That may violate the requirements of Generic ROHC 
> > Notation.
> > 
> 
> 
> This comment is slightly confused.  Yes, we do assume that the
> uncompressed is consumed 'bit-by-bit' in the compression process. 
> However, this doesn't tell you anything about the generation of the 
> compressed packet -- that's what the encoding rules are for.  
> We would 
> suggest that our notation is, so far as possible, agnostic to the 
> encoding rules.
> 

Ok, we would like to explain more details.

The following is partial text in ROHC-FN's Appendix B, the normative definition of encoding methods:

   IRREGULAR(n,P%)

   COMPRESS (IRREGULAR)
       var item

       pop (uncompressed_data, n, item)
       encode (item)
       return true
   end COMPRESS

   DECOMPRESS (IRREGULAR)
       var item

       pop (compression_stack, n, item)
       restore (uncompressed_data, item)
   end DECOMPRESS

In DECOMPRESS (IRREGULAR), 'pop(compression_stack, n, item)' is used to get the compressed data. If the compressed packet is not defined by the profile, how can ROHC-FN guarantee that 'pop(compression_stack, n, item)' will get the compressed value of the specified field without any prior knowledge how 'encode' in compression method packages the compressed data in the compressed header, i.e. the compressed header format. (PS, 'compression_stack' is undefined in your draft, I guess this must be the compressed packet, otherwise there will no way to get the compressed value)

Even 'pop(compression_stack, n, item)' is replaced with some function else, it still ambiguous for two different call of that function without any prior knowledge, i.e. that function have to use the order at which is called to indicate which field's compressed value should be read.

> 
> > 2. We noticed that the sections on STACK encoding has been removed, 
> > instead, several labeling methods are added: they are
> >         a. LABEL(name, length)
> >         b. NEXT_FIELD(name)
> >         c. MSN
> > LABEL and NEXT-FIELD don't have definitions in Appendix B, 
> we can not 
> > know how they are implemented. However, by assuming each encoding 
> > method will process the top of stack or value specified by 
> NEXT-FIELD, 
> > it seems that the profile writer still have to take care 
> the order of 
> > each encoding method is placed.
> >  
> 
> 
> Well, we promised to get rid of the STACK encodings.  So, 
> they've gone! It really doesn't matter how the label methods 
> are implemented, which is 
> why they are not documented.  (What's important about, e.g. 
> LSB is that 
> we define under exactly what circumstances it can be 
> applied). (BTW, 'MSN' is not a method, it's just a well-known label)
> 
> Regarding the issue of order, are you seriously going to try 
> and me that 
> your specification of the header structure does not depend upon the 
> order of the specification?!
> 

In our proposed notation, the generation of compressed header is independent from the order in which the profile is written. In fact, we only describe which components a compressed header consists of.

> 
> > 3. Some methods, such as NBO, SCALE, INFERRED, etc., can 
> generate data 
> > in the uncompressed bits stack. For example, it is described in 
> > INFERRED-OFFSET that "the encoding subtracts the base field 
> from the 
> > field to be compressed and replaces the field value by 
> these "offset" 
> > bits in the uncompressed header." This may confuse profile writers 
> > since they have to take care of what data an encoding methods may 
> > generate and their order in the uncompressed bits stack.
> > 
> 
> 
> This raises a good point.  We have got some slightly confused 
> things in 
> the draft right now.  Although I'm quite comfortable with the 
> way that 
> data is consumed from the uncompressed header, there are alternative 
> ways of thinking about the inferences that you cite above.  
> For example, 
> we could store the meta-data under well-known labels.  I suspect that 
> this requires some more thought...
> 

Yeah, due to rule of re-use of labels, the profile writer can not change the order of the well-known labels' references if they may be defined multi-times. For example, the well-known 'optional' is such a well-known labels. This may provide not enough flexibility as a generic notation.

> 
> > To our knowledge, all those above issues exist because that 
> we need to 
> > find an efficient way to refer to the corresponding field in the 
> > uncompressed packet. So, how about introduce the notation for the 
> > structure of the uncompressed packet as we proposed before. In that 
> > way, we can simplify the notation and profile writing.
> > 
> 
> 
> I agree that we need to efficiently refer to fields.  But no, 
> I'm sorry, 
> I don't agree with your conclusion.  Combining the structure and 
> encoding reduces redundant information and allows compression to be 
> performed in a single-pass operation.
> 

As stated before, such redundant information, which can be called "redundant" in terms of profile document writing, doesn't affect the efficiency of compressed header, only the profile document is somewhat enlarged. As to single-pass operation, that is an implementation issue.

> 
> -- 
> Mark A. West, Consultant Engineer
> Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
> Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433
> 
> Yes, I do know that my disclaimer is in an attachment.  And, no, I 
> didn't ask for it to be that way.  Oh, and...
> 
> Permission is hereby granted to pass the contents of this 
> communication to third parties and any restrictions regarding 
> confidentiality do not apply.
> 
> 

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 03 Jul 2002 14:49:06 +0100

And yet more comments..!

 > The following is partial text in ROHC-FN's Appendix B, the normative 
definition of encoding methods:
[snip]
 >
 > In DECOMPRESS (IRREGULAR), 'pop(compression_stack, n, item)' is
 > used to get the compressed data. If the compressed packet is
 > not defined by the profile, how can ROHC-FN guarantee
 > that 'pop(compression_stack, n, item)' will get the compressed
 > value of the specified field without any prior knowledge how
 > 'encode' in compression method packages the compressed data
 > in the compressed header, i.e. the compressed header format.
 > (PS, 'compression_stack' is undefined in your draft, I guess
 > this must be the compressed packet, otherwise there will no way
 > to get the compressed value)

You are correct in pointing out that the description as given is not 
ideal.  In terms of extracting data from the uncompressed header 
(compression) and rebuilding the uncompressed header (decompression), I 
don't see a problem with treating the header as a 'bit stack'.

But, in terms of compression, for example, we should not talk about a 
'compression_stack'.  Instead, we should just hand the bits that are 
generated over to the encoding rules.  I don't, of course, care what the 
encoding rules do with the data...

(and I assume that it doesn't matter in what order the data is passed to 
the encoding function, provided that the compressor and decompressor agree)

 >
 > Even 'pop(compression_stack, n, item)' is replaced with some
 > function else, it still ambiguous for two different call of
 > that function without any prior knowledge, i.e. that function
 > have to use the order at which is called to indicate which
 > field's compressed value should be read.
 >

It is clear that the processing is order dependent.  However, again, the 
representation is down to the encoding rules.

So, there is a constraint on the encoding that it must be able to 
support multiple uses of a compression function in a defined order. 
However, this is no different from your proposal.

 > In our proposed notation, the generation of compressed header is
 > independent from the order in which the profile is written. In fact,
 > we only describe which components a compressed header consists of.
 >

Your profile is in two parts:

The first part describes the header components.  This uses a BNF-like 
structure.  It is clearly order dependent (just like our profile).

The second part describes the encoding of the values.  Because it can 
refer to the fields identified in the first part, this part can have 
arbitrary order.  (Although the order still has to be *defined* for 
interoperability).

I still don't see any advantage to separating these two aspects of the 
processing.  And I don't see why being able to control the order of 
encoding makes any difference.

 > Yeah, due to rule of re-use of labels, the profile writer can not
 > change the order of the well-known labels' references if they may be
 > defined multi-times. For example, the well-known 'optional' is such a
 > well-known labels. This may provide not enough flexibility as a
 > generic notation.
 >

I don't think that it would cause any particular issues, but I agree 
that it is something that would need to be thought about.

 > As stated before, such redundant information, which can be called
 > "redundant" in terms of profile document writing, doesn't affect the
 > efficiency of compressed header, only the profile document is somewhat
 > enlarged. As to single-pass operation, that is an implementation
 > issue.
 >

I realise that it doesn't affect the compressed header. However, I see 
no point in enlarging the profile document unless it actually gives us 
some measurable benefit.  You are equally correct that single-pass 
operation is an implementation decision, but only if the input data 
supports it.

Mark.