Subject: RE: [rohc] question about Dynamic Compression

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Mon, 14 Nov 2005 07:38:21 +0100

Hi Carrie,

As the local compressor always knows the minimum SMS provided by the
remote decompressor (either the default value guaranteed in RFC 3320 [or
some other standards in special applications] or the advertised SMS),
the basic answer is again yes. The compressor knows if the state gets
truncated, so there is even no need to send more (unless your
compressor/bytecode cannot handle the situation easily).
Shared compression is the one exception where the compressor cannot send
the truncated state, as the state is the un/decompressed message, in
which case, the compressor must advertise the truncated state's ID.
Don't forget: If the SMS is not advertised, the remote endpoint might
still offer SMS greater than that of the standard's default value, and
in this case the state might not be truncated as you would expect (e.g.
you assume 2k SMS in lack of advertisement, but the decompressor has 4k:
a state of 3k will not be truncated then).
br/Zacco

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, November 14, 2005 6:34 AM
> To: [email-masked]
> Subject: Re: [rohc] question about Dynamic Compression
> 
> All,
> 
> Could you please help to answer my question below.
> 
> Thanks a lot.
> 
> Carrie
> 
> Carrie Zhang wrote:
> > 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
> 

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