Subject: RE: [rohc] proposals for generic notation of compressed header

From: "Qian Zhang" <[email-masked]>
Date: Fri, 10 May 2002 23:08:51 +0800

Hi, Mark
	
We introduce the notation of the structure for the uncompressed header
just for clarification purpose. The notation for structure only used to
clarify the labels (or fields) used in the notation of compressed
headers and some structure information among these labels (or fields).
It's unrelated to the complexity of compression and the efficiency of
compression. 
We agree that it may be verbose (in terms of the length for the
notation). However, it doesn't affect the complexity of handling the
profile and the final compression efficiency.

BR,

Qian & Hongbin

> -----Original Message-----
> From: West, Mark (ITN) [mailto:[email-masked]]
> Sent: Sunday, May 05, 2002 7:14 PM
> To: Qian Zhang
> Cc: [email-masked]
> Subject: Re: [rohc] proposals for generic notation of compressed
header
> 
> 
> Hi Qian, Hongbin,
> 
> I think that there is one critical issue raised by this proposal:
> 
> Should the structure and encoding of the header be described in a
single
> or separate notation(s)?
> 
> Clearly what you are proposing implies separate description of the
> structure and the encodings.  However, the notation that we have
> proposed uses a single description.
> 
> My main concern about separating the notation is the redundancy that
> this may imply (and, perhaps, the efficiency -- is there any need to
be
> able to deconstruct the packet header other than to compress/encode
it?)
>   On that basis, can you explain in more detail why you are proposing
> this approach?  (I'd hesitate to say at this stage which is the
> right/better answer, but I'd like to understand the landscape a little
> better...)
> 
> Cheers,
> 
> Mark.
> 

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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Sat, 11 May 2002 21:35:21 +0100

Thanks for the clarification.

I agree that it does not affect the compression complexity or 
efficiency.  I am also not particularly concerned about the verbosity of 
using this approach.

However, I would worry about the introduction of redundancy.

Where this structural notation just includes the length of a field, this 
doesn't seem to pose any great problem -- we simply remove the 'length' 
from the encoding method.
Although I note that we still need to tie the two pieces of information 
(field size and encodings) together...  How would this be done?  By the 
order in which the fields occur?  By the name?  (Note that, in the 
latter case, there are typically at least 2 different sets of encodings 
for a field [IR and CO], which are identified by different names)

More importantly, for the 'structural' constructs (most obviously, 
lists), is there not a greater risk of duplicating information?  (If I 
decide, in notating a protocol to change from a LIST-0 to a LIST-N, I 
would like to change this in as few places as possible...)

I do also take account of Micke's point, which suggests that there may 
be mileage in separating structure and encoding information.  I'm still 
not sure...

Any other thoughts..?

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)