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

From: "Qian Zhang" <[email-masked]>
Date: Tue, 2 Jul 2002 23:37:25 +0800

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.

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.
 
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.

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.

Comments are welcome,

Thx,
Qian & Hongbin

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Tue, 02 Jul 2002 21:44:46 +0100

Hi Qian,

There seems to a fundamental question here that we have been unable to 
resolve:

"Should the 'structure' and 'encoding' description be combined or separate?"

We clearly have different opinions!  So, how should we proceed?

Cheers,

Mark.

-- 
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)

Permission is hereby granted to pass the contents of this communication
to third parties and any restrictions regarding confidentiality do not
apply.

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Tue, 02 Jul 2002 22:32:20 +0100

Hi Qian, Hongbin,

Some more detailed comments!

Cheers,

Mark.

> 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.

> 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?!

> data an encoding methods may generate and their order in the

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...

> 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.

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...