Subject: RE: [rohc] doubt regarding shared compression in rfc 3321

From: "Hans Hannu (LU/EAB)" <[email-masked]>
Date: Mon, 5 Apr 2004 13:57:14 +0200

Step (3) is what your uploaded bytecode does in order to "announce" the shared state. In order to save a number of transmitted bytes per message the calculation of the shared_state_id was included. 
However, you could omit the calculation of the shared_state_id in step (3) by sending the shared_state_id as is over the link instead of having your bytecode calculate it and then announce it.  

BR,
/Hans Hannu

> 
> RFC 3321 speaks about shared compression procedures as follows:
> 
>    (1): Compressor 1 saves e.g., state(M), which is the uncompressed
>         version of the current application message to be 
> compressed and
>         sent.
>    (2): The UDVM bytecode to indicate the presence of state(M) at
>         endpoint 1 is either carried in the compressed message, or can
>         be retrieved by decompressor 2 from a state already saved at
>         endpoint 2.
>    (3): The SHA-1 instruction is used at endpoint 2 to calculate the
>         shared_state_id for state(M).  The indication is passed to the
>         state handler, by placing the shared identifier at 
> the location
>         of the "returned SigComp parameters" [SIGCOMP].  The 
> location of
>         the "returned SigComp parameters" is given to the 
> state handler
>         using the END-MESSAGE instruction.
>    (4): If endpoint 2 uses shared compression, it compares the state
>         identifier values in the "returned SigComp parameters"
>         information with the value it has calculated for the current
>         decompressed message received from endpoint 1.  If there is a
>         match then endpoint 2 uses the shared state together with the
>         state it would normally use if shared compression is not
>         supported to compress the next message.
>    (5): The UDVM bytecode that will use the shared state (state(M)) in
>         the decompression process at decompressor 1 is either carried
>         in the compressed message, or can be retrieved by 
> decompressor 1
>         from a state already saved at endpoint 1.
> 
> I am not able to figure out the difference between step 3 and 
> step4. Step 3
> says that the shared_state_id
> is calculated using SHA-1 and stored in location of "returned Sigcomp
> Parameters" before passed to state handler.
> 
> Step 4 says that the state identifer value in "returned 
> Sigcomp Parameters"
> is compared against
> the state value computed value of state id for the 
> decompressed message.
> 
> But as per your explanation below, it seems to me like step 3 
> and step 4 are
> trying to compute the
> state id over the same piece of data.(i.e. the uncompressed 
> message...)using
> the same procedures.(SHA-1).

> In this case, the results of state 3 and state 4 wil always be the
> same...and a match would always occur..
> 
> So if step 4 computes the state id over the decompressed 
> message, step 3
> should be something different.
> otherwise it does not make sense...
> 
> correct me if i am wrong in my understanding,
> 
> thanks
> suman

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

---

From: suman <[email-masked]>
Date: Mon, 05 Apr 2004 17:48:03 +0530

Hi Hans,

I got your point now..and I appreciate the need to avoid sending the
shared_state_id
each time.
But i am not able to figure out how this bytecode could be intelligent
enough to "announce" the shared state..
How exactly will the bytecode generate the shared state which should be same
as step 4.

Could u throw some more light on this ??

All I know for now is that bytecode cannot perform the SHA-Hash over the
ucompressed message..
because in that case, it would be same as Step (4).

thanks
suman

----- Original Message -----
From: "Hans Hannu (LU/EAB)" <[email-masked]>
To: "'suman'" <[email-masked]>; <[email-masked]>
Sent: Monday, April 05, 2004 5:27 PM
Subject: RE: [rohc] doubt regarding shared compression in rfc 3321

> Step (3) is what your uploaded bytecode does in order to "announce" the
shared state. In order to save a number of transmitted bytes per message the
calculation of the shared_state_id was included.
> However, you could omit the calculation of the shared_state_id in step (3)
by sending the shared_state_id as is over the link instead of having your
bytecode calculate it and then announce it.