Re: [rohc] Problem about list compression

[tangzhenghua <[e-mail]>]

Hi Jonsson

Thanks for your reply.

The problem i proposed has something wrong because i misunderstand the 
concept between table-based compression and
reference list compression.

(1)I have researched list compression recently and compressor can only use 
gereric scheme to support list compression,which means
compressor can only support table-based compression.But i have confused with 
the following sentence discribed in 5.8.1[3095]
"The compressor assigns each item in a list a unique identifier Index"

I am not sure the index assign scheme.The unique is for context,compressor 
or each list(ip extension header or CSRC list)
If a packet include inner ip extend header,outer ip extend header and RTP 
header,which means there are 3 part must be compressed with
list compression scheme.So is the index assigned for inner ip extend header 
can be same as the index assigned for inner ip extend header ? or
the index for inner ip must different from the index for outer ip and CSRC 
list.

If compressor and decompressor use different index assignment scheme,we can 
not ensure the interoperate between different vendor.

(2)The index assigned for item can be 7 bit,which means maybe we need assign 
128 memory space for a list to save the corresponding information(known 
,index and item).on one hand,the 3gpp define the default value for max_cid 
is 15,on the other hand,the size of IP entend header is uncertained(at most 
2040 bytes for a extend header),So the memory space for table-based 
compression is too large.

(3)For reference list compression,I think decompressor should keep slide 
window for reference list.Because if compressor send a new reference list 
before receive
the ACKfor last reference list.So the decompressor must put the new 
reference list into slide window and removed from the slide window only 
received a compressed packet with the same ref id

Regards

Zhenghua



----- Original Message ----- 
From: "Lars-Erik Jonsson (LU/EAB)" <[e-mail]>
To: "tangzhenghua" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 05, 2006 10:10 PM
Subject: RE: [rohc] Problem about list compression


Hi Zhenghua,

I get a little confused by your question since it seems to be
addressing how to do things according to RFC 3095, but at the
same time you refer to draft-ietf-rohc-rfc3095bis-improvements-01.

Anyway, I will try to clarify both the actual functionality of
RFC 3095 and the envisioned functionality for "ROHC v2" or "ROHC
bis", whatever we prefer to call the envisioned outcome which
draft-ietf-rohc-rfc3095bis-improvements-01 aims at.

First, what do draft-ietf-rohc-rfc3095bis-improvements-01 aim at?

  It is correct that "ROHC v2" is planned to only use the
  generic scheme. Further, v2 is supposed to use a unified
  mode approach as ROHC TCP, which means a U/O-like scheme.
  However, "ROHC v2" will clearly be a second generation ROHC
  variant defining new profile, while current profiles will
  still stay as defined by RFC 3095.

So, what about your question regarding list compression in
RFC 3095?

  You have correctly noticed that gen_id is only needed in
  U/O-mode. R mode has a sliding window of references, and
  the compressor must keep in its sliding window all possible
  references the decompressor can potentially use for
  decompression. When compressing, the compressed header
  must be made decompressible with any of these references.
  The decompressor on the other hand keeps only one single
  reference, which is acked. There are no sliding windows
  at the decompressor. This is how it works for several
  fields in R-mode, and thus also for list compression.

Hope this helps!
/L-E


----Original Message----
From: tangzhenghua [mailto:[e-mail]]
Sent: den 29 mars 2006 08:33
To: [e-mail]
Subject: [rohc] Problem about list compression

> Hi,Rohcer's
>
> I have a problem about list compression
>
> Section 5.8.6.1 of RFC3095 define the compressed list format
> of generic scheme.there is a field of gen_id to express the reference
> list But this field just exist at u/0 mode,if compressor and
> decompressor work at R mode,How decompressor find the correct
> reference list from the compressed list format.
>     5.8.6.1.  Encoding Type 0 (generic scheme)
>
>      0   1   2   3   4   5   6   7
>    +---+---+---+---+---+---+---+---+
>    | ET=0  |GP |PS |    CC = m     |
>    +---+---+---+---+---+---+---+---+
>    :            gen_id             :  1 octet, if GP = 1
>    +---+---+---+---+---+---+---+---+
>    |        XI 1, ..., XI m        |  m octets, or m * 4 bits
>    /                --- --- --- ---/
>    |               :    Padding    :  if PS = 0 and m is odd
>    +---+---+---+---+---+---+---+---+
>    |                               |
>    /       item 1, ..., item n     /  variable
>    |                               |
>    +---+---+---+---+---+---+---+---+
>
> For example,
> (1)In IR state and R mode,compressor send 5 IR packet to
> decompressor,decompressor put this 5 reference list into
> sliding window and send ACK to compressor one by one.
> (2)Compressor receive the ACK of NO.1 packet after send No.5
> IR packet,So the list of No.1 can be used as reference list.
> (3)Compressor receive a new packet marked with No.6.It can be
> compressed according to above format .
> (4)decompressor receive a compressed list,Because there is no
> gen_id in this format and there are 5 reference list in the
> sliding window,So how can decompressor choose the reference
> list to restore the origin list.
>
>
> Because draft-ietf-rohc-rfc3095bis-improvements-01
> demonstrate that the List compression should only use the
> generic scheme.So i am confusing with this problem.
>
> Can someone give me some suggestion
>
> Thanks
>
> Regards
>
> Zhenghua 


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