Subject: Re: [rohc] question about Dynamic Compression

From: Carrie Zhang <[email-masked]>
Date: Wed, 09 Nov 2005 10:39:08 +0800

Gustav, et al,

Can I resume the question regarding generating the same
state ID in the compressor as the decompressor side?

In case in the decompressor side, the state memory is not
enough, and the state item gets truncated, the state ID will
be different. Does the compressor side need to predict the
state item will be truncated in far end decompressor, and
generate the state ID based on the truncated state item in
compressor side? So that the state ID can be the same in both
sides?

Regards,
Carrie

"Carrie Zhang" wrote:
> 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,
> 
> 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]>
>> Subject: RE: [rohc] question about Dynamic Compression
>> 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,
>>
>> 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
> 
> 
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/

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

---

From: Carrie Zhang <[email-masked]>
Date: Wed, 09 Nov 2005 11:02:09 +0800

Hi, experts,

The SMS is one of the SigComp parameters that are sent
in the returned_parameters_location in SigComp message.
And the SMS is per-compartment basis. In case of dynamic
compression, compressor also needs to save state items,
shall this SMS be used also for state items save in compressor,
or it is only used for state items saved in decompressor?

Regards,
Carrie

---

From: [email-masked]
Date: Fri, 11 Nov 2005 16:33:24 +0530

Hello Carrie,

Please find my answer to your question.

Regards,
Rasheed
Ext: 9113

             Carrie Zhang                                                  
             <[email-masked]                                             
             om>                                                        To 
             Sent by:                  [email-masked]                       
             rohc-bounces@ietf                                          cc 
             .org                                                          
                                                                   Subject 
                                       [rohc] question about SMS           
             11/09/2005 08:32                                              
             AM                                                            

Hi, experts,

<answer> In case of dynamic compression, the compressor only needs to save
the uncompressed message
and use it in the compression of the subsequest messages to that particular
end point. The SMS should be used
for state items saved at the decompressor only.

Regards,
Carrie

***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

---

From: Carrie Zhang <[email-masked]>
Date: Mon, 14 Nov 2005 13:33:31 +0800

All,

Could you please help to answer my question below.

Thanks a lot.

Carrie