Subject: RE: [rohc] question about Dynamic Compression

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Wed, 21 Sep 2005 18:22:28 +0200

Hi,

The solution is that your compressor generates the state ID with the same state address as the decompressor does. Although it is not evident from your report, I think the state addresses differ. As the local endpoint's compressor instructs the remote endpoint to execute its own bytecode, it knows exactly what the address of the state will be, and it must use that one to generate the identical state ID.
Does this help?

br/Zacco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 21, 2005 4:56 PM
To: Rohc
Subject: [rohc] question about Dynamic Compression

Hi, experts,

Here is a question regarding Dynamic Compression, I could not
find out the answer via reading RFC3321.

Thanks a lot in advance for your patient to read through this email.

Here is the Dynamic Compression message flow from RFC3321, assume
that the "Remote Compressor Initiated Acknowledgements" are used
for explicit acknowledgement:
         Compressor 1                    Decompressor 2
Step  Saved       Acked    |            |   Saved
 #   State(s)    State(s)  |            |  State(s)
    -----------------------+------------+--------------
1)  s0             s0      |            |    s0
2)  s1=s0+m1               | --m1(s0)-->|
3)                         | <--ack(s1) |  s0,s1
4)  s0,s1        s0,s1     |            |
                           |            |
5)  s0,s1        s0,s1     | --m2(s1)-->| 
6)  s2=s1+m1               |            |

In step#2, state s1 is saved by compressor 1, assume the 
state ID is Sc1. Compressor 1 also includes requested 
feedback in m1 (it may put the Sc1 in requested feedback, 
or put an arbitrary identifier)

And in step#3, state s1 is also saved by decompressor 2, assume the 
state ID is Sd1. Actually, Sd1 correlates to Sc1, but they are not equal. 

Still in step#3,  state s1 is Acked by decompressor 2 to compressor 1 via
returned feedback (decompressor 2 shall put whatever data it received in
the requested feedback from step#2, into returned feedback according to 
RFC3320, page#19, the first paragraph). Now, compressor 1 knows that state 
s1 has been created in decompressor 2. 

So, in step#5, compressor 1 can make use of state s1 for m2. in SigComp
message m2, compressor 1 shall specify the PSI (partial state ID), which
should be Sc1. But, when decompressor 2 receives m2, how decompressor 2 
knows what is Sc1, it only knows Sd1. Should decompressor 2 remember the 
correlation between Sc1 and Sd1? Or, should decompressor 2 put Sc1 plus
Sd1 in the returned feedback in step#3, and then compressor 1 shall put
Sd1 in the PSI field in m2, instead of Sc1?

Thanks a lot for your patient to read through this email.

Regards,
Carrie

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

---

From: "Carrie Zhang" <[email-masked]>
Date: Wed, 21 Sep 2005 12:59:57 -0500

Hi, Lajos,

Thanks for your quick response.

For the published Deflate, the last bytecode instruction
END-MESSAGE tells decompressor to save its UDVM
memory from variables/registers to end of circular buffer.
And, the state ID generated in decompressor is the SHA-1 value
across this part of UDVM memory, not only based on the address
of the state. Does compressor know the whole memory layout
in decompressor side?

Regards,
Carrie

-----Original Message-----
From: Lajos Zaccomer (IJ/ETH) [mailto:[email-masked]]
Sent: Wednesday, September 21, 2005 11:22 AM
To: [email-masked]; Rohc
Subject: RE: [rohc] question about Dynamic Compression

Hi,

The solution is that your compressor generates the state ID with the same
state address as the decompressor does. Although it is not evident from your
report, I think the state addresses differ. As the local endpoint's
compressor instructs the remote endpoint to execute its own bytecode, it
knows exactly what the address of the state will be, and it must use that
one to generate the identical state ID.
Does this help?

br/Zacco

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 21, 2005 4:56 PM
To: Rohc
Subject: [rohc] question about Dynamic Compression

Hi, experts,

Regards,
Carrie

---

From: "Gustav E" <[email-masked]>
Date: Wed, 21 Sep 2005 20:14:51 +0200

Hi,

The fast answer to your question is: yes, the compressor must know of the 
whole UDVM memory area that it's decompressor utilizes at the other end. 
This is not tricky since the UDVM area is always initialized in a 
deterministic way and since the decompressor's behaviour is (or should) 
always be know by the compressor.
When a cyclic buffer is used during decompression it is quite common among 
compression algorithms that a cyclic buffer of the same size is used during 
compression and that the data in the buffer evolves exacly the same during 
compression as during decompression. I.e. the data in the buffers are 
identical from the beginning and that the content is the same after 
compression/decompression.

Hope you understand what I'm trying to say here...

BR,
/Gustav

>From: "Carrie Zhang" <[email-masked]>
>Reply-To: [email-masked]
>To: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>,"Rohc" 
><[email-masked]>
>Date: Wed, 21 Sep 2005 12:59:57 -0500
>
>Hi, Lajos,
>

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

---

From: "Carrie Zhang" <[email-masked]>
Date: Wed, 21 Sep 2005 16:35:23 -0500

Gustav,

Thanks for your further explanation. I think I understand this
it now.

Regards,
Carrie

-----Original Message-----
From: Gustav E [mailto:[email-masked]]
Sent: Wednesday, September 21, 2005 1:15 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rohc] question about Dynamic Compression

Hi,

BR,
/Gustav