Subject: RE: [rohc] Timer-based compression

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 5 Jan 2006 08:56:06 +0100

Hi,

Implementer's guide section 4.3:

   Before timer-based compression can be used, the decompressor will
   have to inform the compressor (on a per-channel basis) about its
   clock resolution. Further, the compressor has to send (on a per-
   context basis) a non-zero TIME_STRIDE to the decompressor.

   When the compressor is confident that the decompressor has received
   the TIME_STRIDE value, it can switch to timer-based compression.
   During this transition from window-based compression to timer-based
   compression, it is necessary that the compressor keep k large enough
   to cover both interpretation intervals. 

So the procedure is:
0) TIME_STRIDE starts out as zero
1) CLOCK option is sent by decompressor and received by compressor
2) Compressor decides that it wants to use timer-based compression.
   If so, the compressor sends a non-zero TIME_STRIDE
3) Compressor repeats time-stride until it is _confident_ that the
   decompressor has correctly received the new TIME_STRIDE. Note that
   these packet are already encoded with timer-based compression since
   they contain a time-stride that is non-zero.
4) All packets sent after this that contain an encoded timestamp are
   assumed to be using timer-based compression.

The timer-based compression initialization seems to be the most frequent
question on this list, but I don't know how to improve the text in the 
impl-guide any further. I thought it was quite clear now, but obviously 
it still isn't good enough. Do you have any suggestions on how to 
improve it further?

BR,
	Kristofer

[email-masked] <mailto:[email-masked]> wrote:

> Hi Kavitha,
> 
> 
> 
> I believe with the UOR-2+ext-3 the compressor says that it
> "can" support "timer-based" compression. If the decompressor
> supports this, it can send an ACK with the CLOCK option. Once
> the compressor gets the CLOCK-opt from the decompressor it
> can change to the "timer-based" compression. But it doesn't
> let the decompressor know precisely when to start expecting
> packets compressed with "timer-based" compression.  There has
> to be some way to tell the decompressor that the current
> packet is compressed with the "timer-based" compression algo.
>  I don't see any flags for this in the RFC. One has to
> consider the number of packets on transit before deciding to
> change the compression algorithm after the initial negotiation.
> 
> 
> 
> Thanks
> 
> Biplab
> 
> 
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
> To: [email-masked]
> Subject: Re: [rohc] Timer-based compression
> 
> 
> 
> 
> Hi,
> 
> Compressor can be made to send an UOR-2 packet with ext-3 or
> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it
> begins to do Timer based Compression of TS.  It is a way to
> indicate timer-based compression of TS to the decompressor.
> (Refer RFC 3095 Sec 5.7.5  Extension Formats)
> 
> Kavitha K.R.,
> L&T Infotech,
> Bangalore.
> 
> ( ) L&T Infotech Proprietary & Confidential
> ( ) L&T Infotech Confidential
> () L&T Infotech Internal Use only
> (+) General Business Information
> 
> 
> 
> "Sarkar, Biplab" <[email-masked]>
> Sent by: [email-masked]
> 
> 01/05/2006 11:41 AM
> 
> To
> 
> <[email-masked]>
> 
> cc
> 
> 
> 
> Subject
> 
> [rohc] Timer-based compression
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> All,
> 
> I have a query.
> 
> How does the decompressor know "from" which packet onward it
> would be getting packets encoded with
> timer-based-compression? Since the ACK from the decompressor
> which carries the CLOCK option might take some time to reach
> and get processed at the compressor; is there any way for the
> decompressor to know when to expect packets to be encoded
> with the timer-based compression method.
> 
> Thanks
> Biplab
> 
> ++++++++++++++++++++++++++++++++
> Biplab Sarkar
> Starent Networks, Bangalore
> ++++++++++++++++++++++++++++++++
> 
> 
> 
> ______________________________________________________________
> _______________________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
> 
> ______________________________________________________________________

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 5 Jan 2006 10:31:45 +0100

> Okay. Then this means only decompressor can initiate timer
> based decompression.
> And for that it sends a feedback with CLOCK option.

Well, yes, the decompressor has to let the compressor know
that it supports it, and with what clock resolution. Then
it is the compressor who actually initiates it.
 
> If a decompressor does not want to do timer based
> compression, it would just not send a  CLOCK option at all.
> Then when does the decompressor  send a CLOCK option with
> value zero ?
> This 'special meaning' thing in CLOCK option (Sec 5.7.6.7)
> looks a bit misleading.

Yes, it seems so. I believe the idea was (as often when 3095
was written) to provide tools that could later be found to
be useful, here to give the decompressor means to explicitly
tell the compressor it does not do timer-based compression
(while it actually is of no practical use to do so).

Rgds,
/L-E