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

[Qinqing Zhang <[e-mail]>]

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



On 1/10/06, Ghyslain Pelletier (LU/EAB) <[e-mail]> wrote:
> 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
>
> [e-mail] 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/rohc
>
>

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