Subject: [rohc] RE: Clarification on timer-based compression

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 25 Apr 2005 10:20:04 +0200

Haipeng,

Timer-based compression has always been seen as an optional
mechanism, i.e. optional both from a compressor and a 
decompressor point of view. There are several reasons for
this, as there can be many reasons for not being able to
use it, or not wanting to use it. However, from a protocol
standards point of view, it does not matter why it is
used or not, the only important thing is to make sure that
it will interoperate if it is used, and that the endpoints
can unambiguously agree on whether to use it or not. 

If a protocol mechanism is fully optional, it can be
excluded from an implementation, and that is a feature.
It is not our job as standards writers to enforce what
to implement in terms of optimizations (like timer-based
compression), if it is not actually needed.

BR
/L-E

>  Lars-Erik and Kristofer,
> 
> Sorry for the late reply, but here are my comments:
> 
> Sending non-zero CLOCK feedback option to turn on timer-based
> compression seems fine. 
> 
> But I just want to clarify that timer-based compression is always
> required to be implemented in ROHC stack. It is an optional mechanism
> only in the sense that if the decompressor does not have timing
> information from a clock, then it can not be used. When the
> CLOCK_RESOLUTION on the decompressor side is non-zero, then 
> timer-based
> compression can always be used if the compressor indicates so.
> 
> In addition, if CLOCK feedback is needed to turn on timer-based
> compression, then we need to clarify in the implementer's 
> guide that if
> the decompressor hasn't sent CLCOK feedback to the compressor, upon
> receiving non-zero TIME_STRIDE from the compressor (e.g, in IR), the
> decompressor needs to send CLOCK feedback value to indicate the
> CLOCK_RESOLUTION. 
> 
> Thanks,
> Haipeng 
> 
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]]
> 
> Sent: Wednesday, April 20, 2005 12:22 AM
> To: Kristofer Sandlund; Jin, Haipeng
> Cc: [email-masked]
> Subject: RE: Clarification on timer-based compression (was: Re: [rohc]
> New Draft for Support of Reordering and Constant IP-ID)
> 
> Haipeng and Kristofer,
> 
> I believe Kristofer is correct in that the enabling of timer-based
> compression as a two-step process involving initiatives from both
> decompressor and compressor also serves the purpose of making timer-
> based compression an optional mechanism. We have always considered
> timer-based as an optional mechanism, requiring CLOCK-OPTION 
> + enabling
> from the compressor before it can be used. That was the purpose when
> writing it and that is what has always been the assumption, 
> even if 3095
> (as often) is not very clear on this. We see this being 
> reflected in the
> example implementation structure described in 6.5.1, where clock
> resolution is initially set to 0.
> 
> To summarize, I believe the requirement to have received a CLOCK
> feedback option before timer-based compression can be turned on, is
> correct.
> 
> I made a minor re-write of the text, making it more compact. 
> The result
> became as follows:
> 
> ----------------------------------------------------------------
> 4.8. Using timer-based compression
>    
>   Timer-based compression of the RTP timestamp, as described 
> in section
>   4.5.4, may be used to reduce the number of transmitted 
> timestamp bits
>   (bytes) needed when the timestamp can not be inferred from 
> the SN. It
>   should thus be noted that timer-based compression has no 
> influence on
>   decompression of packets where no timestamp bits are sent, in that
>   case the timestamp is just linearly inferred from the SN 
> (see section
>   4.2 of this document).
> 
>   Whether to use timer-based compression or not is controlled by the
>   TIME_STRIDE control field, which can be set either by an IR, an IR-
>   DYN, or by a compressed packet with extension 3. The 
> compressor turns
>   on timer-based compression by setting TIME_STRIDE to a 
> value > 0, but
>   that can be done first after the decompressor has declared its clock
>   resolution, which is done by sending a CLOCK feedback option for any
>   CID on the channel. 
> -----------------------------------------------------------------
> 
> Rgds,
> /L-E

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

---

From: "Jin, Haipeng" <[email-masked]>
Date: Mon, 25 Apr 2005 15:01:12 -0700

Hi, Lars-Erik and Kristofer,

If, as your interpretation, the decompressor is required to send CLOCK
feedback first before the compressor can send non-zero TIME-STRIDE, then
you can make timer-based compression optional. 

But this is not at all clear in RFC3095. For example, with my way of
interpretation, we can say that it is not optional but it is only turned
on if decompressor responds with non-zero CLOCK to the non-zero
TIME-STRIDE sent by the compressor. If the clock resolution is not high
enough or the compressor/decompressor doesnot want to use it (for
whatever reason), the compressor can simply choose not to send
TIME-STRIDE or the decompressor can choose to send zero CLOCK feedback
or not send feedback at all (on Unidirection link). I don't think there
will be inter-op problem as long as we have one consistent way of
interpretating the RFC text (as Lars-Erik pointed out). 

With that said, I don't want to get into argument before fully
understand the problem. Could you please explain the specific reasons
for making timer-based compression optional for implementation? 

Thanks,
Haipeng

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]]

Sent: Monday, April 25, 2005 1:20 AM
To: Jin, Haipeng; Kristofer Sandlund
Cc: [email-masked]
Subject: RE: Clarification on timer-based compression

Haipeng,

Timer-based compression has always been seen as an optional mechanism,
i.e. optional both from a compressor and a decompressor point of view.
There are several reasons for this, as there can be many reasons for not
being able to use it, or not wanting to use it. However, from a protocol
standards point of view, it does not matter why it is used or not, the
only important thing is to make sure that it will interoperate if it is
used, and that the endpoints can unambiguously agree on whether to use
it or not. 

If a protocol mechanism is fully optional, it can be excluded from an
implementation, and that is a feature.
It is not our job as standards writers to enforce what to implement in
terms of optimizations (like timer-based compression), if it is not
actually needed.

BR
/L-E

> timer-based compression can always be used if the compressor indicates

> so.
> compression, then we need to clarify in the implementer's guide that 
> if the decompressor hasn't sent CLCOK feedback to the compressor, upon

> writing it and that is what has always been the assumption, even if 
> 3095 (as often) is not very clear on this. We see this being reflected

> in the example implementation structure described in 6.5.1, where 
> clock resolution is initially set to 0.
> 
>   Timer-based compression of the RTP timestamp, as described in 
> section
>   4.5.4, may be used to reduce the number of transmitted timestamp 
> bits
>   (bytes) needed when the timestamp can not be inferred from the SN. 
> It
>   should thus be noted that timer-based compression has no influence 
> on
>   case the timestamp is just linearly inferred from the SN (see 
> section
>   4.2 of this document).
> 
>   DYN, or by a compressed packet with extension 3. The compressor 
> turns
>   on timer-based compression by setting TIME_STRIDE to a value > 0, 
> but

---

From: "West, Mark" <[email-masked]>
Date: Tue, 26 Apr 2005 00:47:32 +0100

Hi, Haipeng,

But if the compressor sets TIME_STRIDE then it is scaling the timestamp
before it knows (a) the decompressor clock resolution; or (b) whether the
decompressor even supports timer-based timestamp coding.

Given that the compressor should not send anything that it is not
confident that the decompressor can not decompress, I really don't see how
the compressor can decide to use timer-based encoding *without* some
information from the decompressor.

(or am I misunderstanding your argument?)

So, for example, I agree with Kristofer that, on a uni-directional link,
timer-based encoding (without out-of-band 'negotiation' of willingness and
parameters such as clock resolution) is a really, really bad idea.

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Mon, 25 Apr 2005, Jin, Haipeng wrote:

> Date: Mon, 25 Apr 2005 15:01:12 -0700
> From: "Jin, Haipeng" <[email-masked]>
> To: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>,
>      Kristofer Sandlund <[email-masked]>
> Cc: [email-masked]
> Subject: [rohc] RE: Clarification on timer-based compression
>

---

From: "Jin, Haipeng" <[email-masked]>
Date: Mon, 25 Apr 2005 17:20:47 -0700

Mark,
 
Please see my comments inline.

________________________________

From: West, Mark [mailto:[email-masked]] 
Sent: Monday, April 25, 2005 4:48 PM
To: Jin, Haipeng
Cc: Lars-Erik Jonsson (LU/EAB); Kristofer Sandlund; [email-masked]
Subject: Re: [rohc] RE: Clarification on timer-based compression

Hi, Haipeng, 

But if the compressor sets TIME_STRIDE then it is scaling the timestamp 
before it knows (a) the decompressor clock resolution; or (b) whether
the 
decompressor even supports timer-based timestamp coding. 

Given that the compressor should not send anything that it is not 
confident that the decompressor can not decompress, I really don't see
how 
the compressor can decide to use timer-based encoding *without* some 
information from the decompressor. 

(or am I misunderstanding your argument?)
[Haipeng Jin] I understand your point, but you might have missed my
point. What I mean is that I can interpret the RFC3095 text as saying
that: (a) all compressor/decompressor must support timer-based
compression (b) if decompressor tells the compressor that its
clock_resolution is 0, then the compressor can not use timer based
compression; (c) if the compressor wants to use timer-based compression
before it has info about decompressor's clock_resolution, it needs to
send non-zero TIME_STRIDE to prompt CLOCK feedback from the
decompressor. If the decompressor says CLOCK=0 or no feedback at all (in
U mode), then the compressor can not use timer-based compression.

timer-based encoding (without out-of-band 'negotiation' of willingness
and 
parameters such as clock resolution) is a really, really bad idea. 
[Haipeng Jin] Agree with you. But I am not proposing to do blind
timer-based compression on a uni-directional link or even bi-directional
links. What I really mean is both compressor and decompressor support
timer-based compression but such compression can only be used when the
decompressor has a clock and the compressor knows the clock's
resolution.

Thanks,

Haipeng  

Cheers, 

Mark.

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 26 Apr 2005 08:43:29 +0200

Haipeng,

(or am I misunderstanding your argument?)
[Haipeng Jin] I understand your point, but you might have missed my point. What I mean is that I can interpret the RFC3095 text as saying that: (a) all compressor/decompressor must support timer-based compression (b) if decompressor tells the compressor that its clock_resolution is 0, then the compressor can not use timer based compression; (c) if the compressor wants to use timer-based compression before it has info about decompressor's clock_resolution, it needs to send non-zero TIME_STRIDE to prompt CLOCK feedback from the decompressor. If the decompressor says CLOCK=0 or no feedback at all (in U mode), then the compressor can not use timer-based compression. 

[LEJ]

a) I know 3095 is not formally explicit on this, but to me it is pretty clear (based on technical grounds) that this is an optional mechanism, as it can not always be used, and it require explicit actions from both decompressor and compressor (in that order) before it can be used. In IETF specifications, we usually do not mandate things that can't be mandated, and if a mechanism is in any way optional, we leave it to the implementer(s) to decide whether to use it or not, thereby we do not restrict implementation. This is common practice, so to me it is clear that implementers are free to decide whether to implement timer-based compression or not.

b) This would mean timer-based compression would be default, and the decompressor would have to turn it off. That would not work, as pointed out by Mark and others, since the compressor need to know the clock_resolution BEFORE it can use timer-based compression, not because we have said so, but because it would not work otherwise.

c) That could mean the compressor would send packets that can not for sure be decompressed, and that is not the intension of the specification. Further, it is not stated anywhere that the decompressor must respond to such behavior by sending a CLOCK option.

So, for example, I agree with Kristofer that, on a uni-directional link, 
timer-based encoding (without out-of-band 'negotiation' of willingness and 
parameters such as clock resolution) is a really, really bad idea. 
[Haipeng Jin] Agree with you. But I am not proposing to do blind timer-based compression on a uni-directional link or even bi-directional links. What I really mean is both compressor and decompressor support timer-based compression but such compression can only be used when the decompressor has a clock and the compressor knows the clock's resolution. 

[LEJ] I do have a hard time seeing what you are after here. Why would you want to allow the compressor to start using an optimization scheme that require knowledge about decompressor capabilities before the decompressor has made that information available? I believe that would not work, neither would it be desirable as it would make timer-based compression a mandatory mechanism to implement, something that would go against both the intensions of 3095 and the opinions of the implementer's who have participated in the ROHC interoperability events. Timer-based is a scheme that provides a minimal compression gain for some packets by adding extra complexity, and it should be up to implementer's to decide whether the gain is worth the complexity. 

/L-E