Re: [rohc] Timer-based compression

["Lars-Erik Jonsson" <[e-mail]>]

Timer-based compression has never been brought up as something undesirable,
not-worth-the-effort, or as a candidate for removal. That is why it is not 
part
of the improvements draft. Personally, I think it does not really hurt to 
keep it,
but I do not care much about it either.

Assuming we keep it, I do not see anything wrong with the way it is set up,
just that it should be made clear how it works, as in the implementer's 
guide.
Requiring the decompressing to "announce" its ability to use it and then
ultimately let the compressor choose whether to use it, is in my opinion the
Right Way (tm) to design the usage negotiation.

Rgds,
/L-E

----- Original Message ----- 
From: <[e-mail]>
To: "Kristofer Sandlund (LU/EAB)" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 05, 2006 12:39 PM
Subject: RE: [rohc] Timer-based compression


Quoting "Kristofer Sandlund (LU/EAB)" <[e-mail]>:

> But one simple solution is to just not use it!

On a sidetrack... Is Timer-based compression something that we feel is
unnecessary for the updated set of profiles, or do I misunderstand your 
comment?

I had a quick look in

http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-improvements-
01.txt

where I didn't find anything related to Timer-based compression. 
Alternatively,
do we want its usage to setup in a different manner than how it currently is 
in
3095?

/Ghyslain

> /Kristofer
>
> >
> > BR,
> > 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
> >
> >
> >
> > "Lars-Erik Jonsson" <[e-mail]>
> >
> > 01/05/2006 02:28 PM To
> > "Kavitha KR" <[e-mail]>, <[e-mail]>
> > cc
> > Subject
> > Re: [rohc] Timer-based compression
> >
> >
> >
> >
> >
> >
> > The decompressor can also send a CLOCK option vith value zero, but
> > a compressor is still not allowed to start timer-based compression
> > before it has received the CLOCK option. The specifications do not
> > allow that,
> > and one reason for that is the fact that the compressor can
> > not know how
> > to compress with timer-based compression without knowing the clock
> > resolution.
> >
> > /L-E
> >
> >
> > ----- Original Message -----
> > From: "Kavitha KR" <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, January 05, 2006 9:52 AM
> > Subject: Re: [rohc] Timer-based compression
> >
> >
> >> Hi L-E/Kristofer,
> >>
> >> But, if we look at the explanation for CLOCK option in Sec 5.7.6.7
> >> of 3095,
> >>
> >> "The smallest clock resolution which can be indicated is 1
> >> millisecond. The value zero has a special meaning: it indicates that
> >> the decompressor cannot do timer-based compression of the RTP
> >> Timestamp."
> >>
> >> So even if there are impertinent Compressors (Scenario 2 and 4),
> >> Decompressors can still send CLOCK value zero and
> >> choose not to do timer based decompression. Isn't it so ?
> >>
> >>
> >> Regards,
> >> 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
> >>
> >>
> >>
> >> "Lars-Erik Jonsson" <[e-mail]>
> >> 01/05/2006 02:10 PM
> >>
> >> To
> >> <[e-mail]>, "Kavitha KR" <[e-mail]>
> >> cc
> >>
> >> Subject
> >> Re: [rohc] Timer-based compression
> >>
> >>
> >>
> >>
> >>
> >>
> >> Kavitha,
> >>
> >> As said in the implementer's guide, "Before timer-based compression
> >> can be used, the decompressor will have to inform the compressor (on
> >> a per- channel basis) about its clock resolution."
> >>
> >> This means only scenario 1 and 3 make sense. The compressor is not
> >> allowed to start timer-based compression before the decompressor has
> >> sent the clock resolution (i.e. the CLOCK option).
> >>
> >> BR
> >> /L-E
> >>
> >>
> >> ----- Original Message -----
> >> From: "Kavitha KR" <[e-mail]>
> >> To: <[e-mail]>
> >> Sent: Thursday, January 05, 2006 9:35 AM
> >> Subject: RE: [rohc] Timer-based compression
> >>
> >>
> >>> Hi,
> >>>
> >>> There could be 4 cases for switching from scaled TS compression to
> >>> Timer based compression of RTP TS.
> >>>
> >>> Scenario 1 : Decompressor initializes and compressor accepts
> >>> =====================================================
> >>> Packet flow with scaled timestamp compression going
> >>> on................. D => send feedback with CLOCK option
> >>> C => send TIME_STRIDE information (timer based compression starts
> >>> here) Further packet flow continues with timer based
> >>> compression..................
> >>>
> >>> Scenario 2: Compressor initializes and decompressor accepts
> >>> =====================================================
> >>> Packet flow with scaled timestamp compression going
> >>> on................. C=> send TIME_STRIDE information (timer based
> >>> compression starts here) D=> send feedback with CLOCK option
> >>> Further packet flow continues with timer based
> >>> compression..................
> >>>
> >>> Scenario 3: Decompressor initializes and compressor rejects
> >>> =====================================================
> >>> Packet flow with scaled timestamp compression going
> >>> on................. D => send feedback with CLOCK option
> >>> C=> No TIME_STRIDE info is sent (indicates not wanting to switch to
> >>> Timer Based) Further packet flow continues with scaled timestamp
> >>> compression..................
> >>>
> >>> Scenario 4: Compressor initializes and decompressor rejects
> >>> =====================================================
> >>> Packet flow with scaled timestamp compression going
> >>> on................. C =>send TIME_STRIDE information
> >>> D=> send feedback with CLOCK option set to zero (means no desire to
> >>> do timer based compression) Further packet flow continues with
> >>> scaled timestamp compression..................
> >>>
> >>> For various compressor and decompressor implementations to
> >>> interoperate, this may be the minimum set to be taken care.
> >>>
> >>>
> >>> =================================================
> >>> When your work speaks for itself, get out of the way. -- Thomas
> >>> 'Wayne' Brazell =================================================
> >>> 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
> >>>
> >>>
> >>>
> >>> "Kristofer Sandlund \(LU/EAB\)" <[e-mail]>
> >>> 01/05/2006 01:26 PM
> >>>
> >>> To
> >>> "Sarkar, Biplab" <[e-mail]>, "Kavitha KR"
> >>> <[e-mail]> cc
> >>> <[e-mail]>
> >>> Subject
> >>> RE: [rohc] Timer-based compression
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> [e-mail] <mailto:[e-mail]> 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: [e-mail]
> > [mailto:[e-mail]] On Behalf
> >>>> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
> >>>> To: [e-mail]
> >>>> 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" <[e-mail]>
> >>>> Sent by: [e-mail]
> >>>>
> >>>> 01/05/2006 11:41 AM
> >>>>
> >>>> To
> >>>>
> >>>> <[e-mail]>
> >>>>
> >>>> 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
> >>>> [e-mail]
> >>>> https://www1.ietf.org/mailman/listinfo/rohc
> >>>>
> >>>>
> >>>>
> > ______________________________________________________________________
> >>>
> >>>
> >>>
> > ______________________________________________________________________
> >>>
> >>>
> >>>
> >>>
> > ______________________________________________________________________
> >>
> >>
> >>
> > --------------------------------------------------------------
> > ------------------
> >>
> >>
> >>> _______________________________________________
> >>> Rohc mailing list
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/rohc
> >>>
> >>
> >>
> >>
> > ______________________________________________________________________
> >>
> >>
> >>
> >>
> > ______________________________________________________________________
> >
> >
> > --------------------------------------------------------------
> > ------------------
> >
> >
> >> _______________________________________________
> >> Rohc mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/rohc
> >>
> >
> >
> > ______________________________________________________________________
> >
> >
> > ______________________________________________________________________
>
>
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rohc
>
>





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


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