Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID)

From: "Jin, Haipeng" <[email-masked]>
Date: Fri, 22 Apr 2005 15:32:04 -0700

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

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 20 april 2005 08:43
> To: Jin, Haipeng
> Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]; [email-masked]
> Subject: Re: Clarification on timer-based compression (was: Re: [rohc]

> New Draft for Support of Reordering and Constant IP-ID)
> 
> 
> Hi Haipeng,
> 
> comments inline.
> 
> Jin, Haipeng wrote:
> > Hi, Lars-Erik and Kristofer,
> > 
> > The proposed text does not allow setting TIME_STRIDE to
> non-zero value
> > before receiving CLOCK feedback in the case where the compressor has

> > advanced knowledge of the decompressor's clock resolution.
> Can we append
> > the following sentence after the text proposed by Kristofer?
> > 
> > ----START--------
> > However, if the compressor has learned the clock resolution of the 
> > decompressor from external means (e.g., when both compressor and 
> > decompressor are synchronized to the same timing source), then 
> > TIME_STRIDE can be set to non-zero value even when no CLOCK
> feedback is
> > received. 
> > -----END---------
> 
> This change would be in violation of 3095 (section 6.5.1, which 
> specifies that the initial value of the clock resolution is set to 0).
> It is a big advantage to have the timer-based compression specified 
> this way, since BOTH compressor and decompressor must make an explicit

> action to start using timer-based compression, and your proposed text 
> would make it mandatory for the decompressor to support timer-based 
> compression.
> 
> The point of the implementer's guide is to clarify things without 
> changing intended behavior, so I'm going to have to oppose the text 
> suggested above.
> 
> BR,
> 	Kristofer Sandlund, Effnet AB
> 
> > 
> > Thanks,
> > Haipeng

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 25 Apr 2005 08:38:51 +0200

Hi Haipeng,

comments inline.

> compression can always be used if the compressor indicates so.

I don't agree. Timer-based compression is meant to be optional in the ROHC 
stack, which to me is an important "feature" to keep. The point is that to use 
timer-based compression, _first_ the decompressor must make an explicit action 
(sending CLOCK) and then the compressor must _also_ make an explicit action 
(sending TIS). And things should only happen in that order, not the reverse.

Allowing the behavior you suggest could also cause some big interoperability 
problems, if the compressor could for example tries to send TIS on a 
unidirectional link.

> decompressor needs to send CLOCK feedback value to indicate the

The compressor is not allowed to send TIME_STRIDE until it has received the 
CLOCK feedback, so this situation seems moot. Do we need to clarify what the 
decompressor should do if this happens anyway? I don't think so, it should be 
detected by the decompressor that the compressor is bad and should take the same 
actions it normally does on failure.

BR,