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

From: Qinqing Zhang <[email-masked]>
Date: Mon, 9 Jan 2006 18:16:34 -0500

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

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 10 Jan 2006 09:09:32 -0800

Ghyslain,

Thanks for your comments. But, the earlier mail from Qinqing did not
completely explain the procedure in 3GPP2 and let me explain it.

Essentially, when the AT acquires the "network" (this is prior to
setting up any flows), it sends the RAN its set of capabilities. These
include whether the RoHC at the AT can do timer-based compression,
delayed decompression etc.

Once the RAN has this knowledge, it may ask the AT to enable timer-based
compression **only if** the AT has indicated that it supports it. Else,
the RAN will not ask the AT to do timer-based for any flow. Also, the
RAN will typically only enable timer-based for VoIP flows and not for
any other flows. Moreover, when the RAN asks the AT to enable
timer-based, it only means that the AT's compressor should be ready to
do timer-based (subject of course, to the decompressor sending a
FEEDBACK with the CLOCK option non-zero).

Similar arguments are also for reverse decompression. Again, the RAN
will only ask the AT to do reverse decompression for flows which don't
have strict delay requirements. If it is felt by 3GPP2 that gains are
not being seen for any flow, then the RAN can always set this to 0 for
all flows.

One more point is that the architecture of 3GPP2 is such that the AT is
supposed to be "dumb", meaning that the AT does not have knowledge of
what the flow is. Of course, the AT's compressor can be smart and try to
identify that the flow is doing Silence Suppression by looking at the
RTP stream, but we have seen cases of implementations where the
compressor is not doing this (or is getting confused while doing this)
and thus, we cannot rely on the AT's compressor to identify this.
The RAN, on the other hand, knows exactly what flow it is, based on some
QoS Profile IDs that are exchanged prior to setting up the flow. So, the
RAN is in the best situation to let the AT know.

Also, even though timer-based buys only 1 or 2 bytes typically (and that
too at the beginning of a talkspurt), but this 1 or 2 bytes becomes very
important for us due to the fact that physical layer payloads are
discrete. Meaning that sometimes even 1 extra byte causes the higher
payload to be picked (which is then mostly padded away), causing a
significant waste in capacity.

Let me also stress here that we have been active on this list and have
been following all RoHC guidelines when designing how to use RoHC in
3GPP2.

Hope this helps answer your concerns.

Thanks,
Rohit

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Ghyslain Pelletier (LU/EAB)
> Sent: Tuesday, January 10, 2006 7:00 AM
> To: Qinqing Zhang; [email-masked]
> Subject: RE: [rohc] ROHC parameter configurations at the radio access
> network.
> 
> 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
> 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:
> >
> > 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
> > 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
> > 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.
> >

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Jan 2006 11:17:58 +0100

Kapoor, Qinqing

Let me try to answer in a more noncommital manner here wrt to 3GPP2,
because I was not essentially trying to recommend any specific direction
wrt 3GPP2 standardization of C.P0063-0_v1.15. Only the questions where
put into this context, so I seem to have fallen into it.

In short -- I don't think the proposed parameters will hurt a ROHC
implementation. It might only mandate implementing some "features" that
are today optional in 3095. I cannot see however that these "features"
will help or gain anything. My personal opinion wrt to 3095 Timer-based
TS compression is that the gains are insignificant (when any) and that
there is very little point in using it (or implementing it for that
matter). Reverse decompression is a local feature at the decompressor
for which it is also debatable if it is useful at all. IMHO, it's not.
This is also because it would anyway be triggered very infrequently, and
is likely not suitable for flows with strict delay requirements. This is
the essence of my previous mail.

Furthermore, I think it is generally a bad idea to add specify
signalling external to ROHC implementations, other than the 3095
mandatory channel parameters. I most often simply can't see a good case
for this.

I could be sympathetic to an argumentation based on that "the octet that
it will save for the k packets (k being somewhere close to 2-4 packets)
sent with the OA after the DTX period is important because the physical
layer payloads are discrete sizes" as Kapoor explained, if only I would
believe it would actually solve the problem that this presents, and I
believe it does not. The same has been discussed in other
standardization bodies. There are too many factors that impact the
choice of the compressed header, that requesting the use of Timer-based
TS compression gives in fact no guarantee that the size of those header
-- i.e. at the beginning of a talkspurt -- will be solely and
deterministicly based on the usage of this coding method.  

I think that the best way with ROHC is to not have any external
signalling other than what is necessary for the establishment of the
ROHC channel as described in 3095, and instead work your implementation
so that it always gives you the best fit for the other constraints
presented by the physical layer.

But again, it's very much outside my scope (and the one of this list) to
go beyond what I wrote above and make recommendations to 3GPP2. I am
simply trying to give you the best possible answer according to my
understanding, and at this point I think it is up to you guys in 3GPP2
to move on or not with these extra parameters.

Best regards,

/Ghyslain

Kapoor, Rohit wrote:
> Ghyslain,
> 
> Thanks for your comments. But, the earlier mail from Qinqing
> did not completely explain the procedure in 3GPP2 and let me explain
> it. 
> 
> Essentially, when the AT acquires the "network" (this is
> prior to setting up any flows), it sends the RAN its set of
> capabilities. These include whether the RoHC at the AT can do
> timer-based compression, delayed decompression etc.
> 
> Once the RAN has this knowledge, it may ask the AT to enable
> timer-based compression **only if** the AT has indicated that
> it supports it. Else, the RAN will not ask the AT to do
> timer-based for any flow. Also, the RAN will typically only
> enable timer-based for VoIP flows and not for any other
> flows. Moreover, when the RAN asks the AT to enable
> timer-based, it only means that the AT's compressor should be
> ready to do timer-based (subject of course, to the
> decompressor sending a FEEDBACK with the CLOCK option non-zero).
> 
> Similar arguments are also for reverse decompression. Again,
> the RAN will only ask the AT to do reverse decompression for
> flows which don't have strict delay requirements. If it is
> felt by 3GPP2 that gains are not being seen for any flow,
> then the RAN can always set this to 0 for all flows.
> 
> 
> One more point is that the architecture of 3GPP2 is such that
> the AT is supposed to be "dumb", meaning that the AT does not
> have knowledge of what the flow is. Of course, the AT's
> compressor can be smart and try to identify that the flow is
> doing Silence Suppression by looking at the RTP stream, but
> we have seen cases of implementations where the compressor is
> not doing this (or is getting confused while doing this) and
> thus, we cannot rely on the AT's compressor to identify this.
> The RAN, on the other hand, knows exactly what flow it is,
> based on some QoS Profile IDs that are exchanged prior to
> setting up the flow. So, the RAN is in the best situation to let the
> AT know. 
> 
> Also, even though timer-based buys only 1 or 2 bytes
> typically (and that too at the beginning of a talkspurt), but
> this 1 or 2 bytes becomes very important for us due to the
> fact that physical layer payloads are discrete. Meaning that
> sometimes even 1 extra byte causes the higher payload to be
> picked (which is then mostly padded away), causing a
> Let me also stress here that we have been active on this list
> and have been following all RoHC guidelines when designing
> how to use RoHC in 3GPP2.
> 
>> Of Ghyslain Pelletier (LU/EAB) Sent: Tuesday, January 10, 2006 7:00
>> AM 
>> Subject: RE: [rohc] ROHC parameter configurations at the radio
>> access network. 
>> 
>> Qinqing,
>> 
>>> 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.
>> 
>> 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). 
>> 
>> 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. 
>> 
>> 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). 
>> 
>> 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?
>> 
>> 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. 
>> 
>> 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. 
>> 
>> 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. 
>> 
>> 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
>> 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.
>> 
>> 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.  
>> 
>>> 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
>>> 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
>>> 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?