Subject: RE: [rohc] ROHC parameter configurations at the radio access network.

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Tue, 10 Jan 2006 16:00:11 +0100

Qinqing,

I had a quick look at C.P0063-0_v1.15 (i.e. the V&V version), section
2.9.2.5.1.
(I assume in this section "supported" means "used for this RoHC
channel"?)

Comments inline.

> I do not quite see the needs for adding these two attributes
> at the air interface standards. These two parameters are
> purely ROHC implementation parameters, which should be
> handled by the compressor and decompressor, not by RAN, a 3rd
> party.

I completely agree with you on this.

> The arguments I heard about is that the RAN can make
> sure that the access terminal will use the timerbased
> compression for the voice application, and will not use timer
> based compression for the video application, by setting the
> TimerBasedCompression attribute for each flow.

These seem to be somewhat rather weak arguments.

First, from IETF specs (3095 + implementer's guide) neither the
compressor or the decompressor are mandated to implement and support
timer-based TS compression. Second, for video, the compressor would not
use it anyway because of the change pattern of the TS that would hinder
the use of timer-based compression. Thirdly, for voice, the gain of
timer-based compression is very small (closer to insignificant IMHO).

More specifically, from the way 3095 is written and together with the
clarifications from the implementer's guide (section section 4.3), it is
the decompressor that decides if Timer-based compression MAY be used or
not by the compressor. The decompressor can signal this that it supports
timer-based decompression by sending a feedback with a CLOCK option.
This is then valid for any flow over that RoHC channel. In this respect,
the decompressor is never mandated to implement Timer-based compression.
The compressor MAY then (but is not mandated to), on a per-context
basis, choose to use timer-based compression or not - for this the
compressor has to send a non-zero TIME_STRIDE to the decompressor. In
this respect, the compressor is never mandated to implement Timer-based
compression either.

See also a fine mail by Kristofer S. on this:
http://www.ietf.org/mail-archive/web/rohc/current/msg04097.html

With respect to the gain of this encoding method, it is mainly only
applicable to audio flows. Its gain is localized to right after the end
of a DTX period, at the beginning of the new talkspurt. At this point,
timer-based compression allows the compressor to send a UOR-2 header
without any extension, while without timer-based compression it would
normally have had to send at least a one-byte extension (e.g. extension
type 0).

The total gain is thus at most 1 byte for a number k of compressed
packets, where k corresponds to the number of packets sent in UO-mode
for the optimistic approach (i.e. normally equal to the maximum number
of consecutive losses over the link). We normally fix the value of k to
around k = 3, so the total gain becomes ... 3 octets per talkspurt when
compared to not using it.

> Does this make sense?

I am not sure that the suggested parameter is really useful.

First, this mandates that ROHC implementations willing to be compliant
to 3GPP2 specs shall support timer-based compression, which is currently
not mandated by IETF specifications as explained above, for neither
compressor or decompressor.

Second, the gain of timer-based compression is very limited, even
insignificant with respect to the added complexity of supporting it
IMHO.

So, would 3GPP2 really feels that these few octets are worth the fight,
then it should at least mandate RoHC implementations to explicitely
support Timer-based compression. But this is not something that I would
recommend to do anyway.

> Another question is that for this delayed compression, is
> there any implementation issue that this option is actually not
> recommended? 

I assume that delayed compression refers to the reverse compression of
3095, section 6.1. I am not sure what potential implementation issue you
are referring to, but reverse decompression is definitely purely an
implementation feature for the decompressor and IMHO it should not be
mandated to support.

Secondly, I wonder what is the purpose of having a parameter for
specifying reverse decompression? Is it meant as a "hint" for the
decompressor? If so, is it a hint for the purpose of indicating some
kind of maximum delay requirement? Otherwise, what prevents a
decompressor to ignore this parameter altogether and not perform reverse
decompression at all?

Finally, it seems to me that it is rather likely that the actual depth
for being successful with this "feature" would exceed the delay
requirements of the real-time flow(s). This is because the decompressor
must store all packets that have not successfully been decompressed
until a UOR-2, IR, or IR-DYN that solves the problem is received, and
these are normally infrequently sent by the compressor - mainly only
when feedback is received for a context repair.

In other words, I normally don't recommend the use of reverse
decompression at any time.

So, in short, I would suggest that these two parameters not be included
in C.P0063-0, but on the other end I do not believe that they will hurt
anything other than mandating the use of timer-based compression for all
implementers. MaxSupportedDelayedDecompressionDepth will have in my
opinion no effect.

I hope this helps you somewhat,

Regards,

/Ghyslain

[email-masked] wrote:
> Dear ROHC experts:
> 
> In a recent 3GPP2 standard document, TIA-1054  (not the final
> version), there is a proposal to add two attributes related
> with ROHC parameters configurated at the air interface. The
> two attributes are TimerBasedCompression, and
> DelayCompressionDepth. The description of these two attributes are as
> follows: 
> 
> DelayCompressionDepth:
> The sender shall set this field to the maximum number of
> packets that can be buffered and thus possibly be delayed
> decompressed by the decompressor according to ROHC RFC3095
> for this ROHC channel. If the value of this field is 0, then
> delayed compression shall not be enabled. The sender shall
> not set this field to a value greater than
> MaxSupportedDelayedDecompressionDepth.
> 
> TimerBasedCompression:
> The sender shall set this field to "0" if timer based
> compression is not enabled for this ROHC channel. The sender
> shall set this field to "1" if timer based compression is
> enabled for this ROHC channel. If
> TimerBasedCompressionSupported is set to "0", then the sender
> shall not set this field to "1".
> 
> I do not quite see the needs for adding these two attributes
> at the air interface standards. These two parameters are
> purely ROHC implementation parameters, which should be
> handled by the compressor and decompressor, not by RAN, a 3rd
> party. The arguments I heard about is that the RAN can make
> sure that the access terminal will use the timerbased
> compression for the voice application. and will not use timer
> based compression for the video application, by setting the
> TimerBasedCompression attribute for each flow.
> Does this make sense?
> Another question is that for this delayed compression, is
> there any implementation issue that this option is actually not
> recommended? 
> 
> I do not intend to bring the discussion from 3GPP2 standards
> to the IETF standards. But since this is related with ROHC, I
> would like to seek the opinion from the IETF ROHC experts.
> 
> Thanks in advance for your kind reply.
> 
> Regards,
> Qinqing
> 
> _______________________________________________
> 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: Qinqing Zhang <[email-masked]>
Date: Tue, 10 Jan 2006 11:26:04 -0500

Ghyslain:

Thank you for your thorough comments and suggestion.
I completely agree with your  arguments on why these two attributes
should not be included in the 3GPP2 RAN standards.

Another note is that for some voice flows over the RAN, silence
suppression may not be supported. If there is no silence suppression
(or 1/8 rate blanking), TS does not need to be compressed. It will be
deferred from the SN.  Timer based compression has no merits in this
scenario.

In the ROHC improvement draft,
draft-ietf-rohc-rfc3095bis-improvements-01.txt, section 6.1 on reverse
decompression, it is suggested to remove the reverse decompression
described in RFC3095, section 6.1, since it is "a very questionable
implementation".
I would assume that the DelayCompressionDepth has no merits as well 
in terms of decompression improvement.

Thanks,
Qinqing