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

From: "Qian Zhang" <[email-masked]>
Date: Mon, 13 May 2002 21:10:33 +0800

Hi, Mark
	Comments inline...

Cheers,

Qian and Hongbin
05/13/2002

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

Please note that we want to distinguish two concepts. One is the field
to be compressed, and the other is the method how to compress it. The
notation of uncompressed header is used just to clarify the terms and
relations in the protocol headers. It does not add any complexity or
affect the efficiency of header compression. That is to say, it will not
introduce redundancy. 

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

By the name. However, we should use different names for IR and CO from
the uncompressed header.

> 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 am not clear about what is the problem? LIST-0, LIST-N and LIST-LEN
are all used to organize a list of fields, however, they are different
from how to determine the end of the list. LIST-0 uses a 'zero' as the
end of the list, which is mostly used to organize fields with
self-identifier and the total of length can be inferred; LIST-N uses a
field specify the number of items in the list, which is mostly used to
organize fields of the same type, no self-identifier is needed; and
LIST-LEN uses length of octet to determine the end of the list, which is
mostly used to organize fields with self-identifier, how the total of
length can be inferred.

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

---

From: Wang Hui <[email-masked]>
Date: Tue, 14 May 2002 16:11:23 +0800 (CST)

Hi,

We startup to implement the RFC3095.  When I have read through the rfc
file and found there is no guide of how to set some key parameters in the
ROHC framework, such as TIMEOUT interval between the different compression
state.  I decide to do some simulations to find out the optimisc values of
the key parameters.  But first, I wonder if the same work having been done
here before?  Any papers? Or may I ask for your suggestion on how to set
this values?

Thanks in advance.

Best,
--
 Wang Hui
 Next Generation Internet Research Team,
 InfoNet Lab, USTC
 http://mail.ustc.edu.cn/~whui
 Tel: +86-551-3603634