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.
Thanks,
Haipeng
-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson at ericsson.com]
Sent: Wednesday, April 20, 2005 12:22 AM
To: Kristofer Sandlund; Jin, Haipeng
Cc: rohc at ietf.org
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:kristofer.sandlund at effnet.com]
Sent: den 20 april 2005 08:43
To: Jin, Haipeng
Cc: Lars-Erik Jonsson (LU/EAB); rohc at ietf.org; hjin at qualcomm.com
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