Subject: RE: [rohc] RE: CDRs for WGCLdraft-ietf-rohc-rfc3095bis-rohcv2-profiles-02

From: "Ghyslain Pelletier" <[email-masked]>
Date: Sat, 1 Dec 2007 11:33:34 +0100

Hello Haipeng,

I would like to conclude this discussion.

I hope that we can agree to the following:

- leave current text as it is wrt use of TBC
  
  Current text is correct because the compressor is only allowed to
  use TBC (i.e. Set time_stride!=0) if and only if it has received a
  non-zero value for the CLOCK_RESOLUTION; even then
  (i.e. CLOCK_RESOLUTION!=0), the compressor is not required to use
  TBC (i.e. Set time_stride!=0). Obviously, the compressor is coherent
  with setting time_stride and whether it uses TBC or not, folliwong
  the definition of the TBC encoding.

- modify the text about the handling of the error case

  What's important here for the decompressor is what it receives
  (valueof time_stride) wrt to what it has sent before
  (valueof CLOCK_RESOLUTION). It is not about the value of the
  decompressor's clock resolution, but about what it has
  communicated to the compressor (i.e. The case where both ends
  have a non-zero CLOCK_RESOLUTION without decompressor having
  sent its value does not apply, neither the case where the
  compressor "polls" the decompressor for the purpose of enabling TBC).

The proposed resulting change is then as follow:

OLD:

   The control field time_stride controls whether or not the
   timer_based_lsb method is used in the CO header.  The decompressor
   SHOULD send the CLOCK_RESOLUTION option if it receives a non-zero
   time_stride value and it has not previously informed the compressor
   that it supports timer-based compression using the CLOCK_RESOLUTION
   option with a non-zero value.  Whether the CLOCK_RESOLUTION is set to
   a non-zero value or to a zero value is up to the implementation.

   The support and usage of timer-based compression is optional for both
   the compressor and the decompressor; the compressor is never required
   to set the time_stride control field to a non-zero value when it has
   received a non-zero value for the CLOCK_RESOLUTION option.

NEW:

    The control field time_stride controls whether or not the
    timer_based_lsb method is used in the CO header.  The decompressor
.   SHOULD send the CLOCK_RESOLUTION option with a zero value, if:
.   - it receives a non-zero time_stride value, and
.   - it has not previously sent a CLOCK_RESOLUTION feedback with a
.     non-zero value.
.   This is to allow compression to recover from the case where a
.   compressor erroneously activates timer-based compression.

    The support and usage of timer-based compression is optional for
both
    the compressor and the decompressor; the compressor is never
required
    to set the time_stride control field to a non-zero value when it has
    received a non-zero value for the CLOCK_RESOLUTION option.

Please see my comments inline to your mail for more details on the
above.

Cheers,

///Ghyslain

Jin, Haipeng wrote:
> Hi, Ghyslain,
> 
> Thanks for the detailed response. There might be some misunderstanding
> here, but I would like to emphasize again that we both agree TBC is
> optional. The confusion here seems to be the wording used to describe
> this optional functionality.
> 
> Please see my further comments inline.
> 
> Br,
> Haipeng
> 
> -----Original Message-----
> From: Ghyslain Pelletier [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2007 3:29 AM
> To: Jin, Haipeng; Kristofer Sandlund; Carl Knutsson
> Cc: rohc
> Subject: RE: [rohc] RE: CDRs for
> WGCLdraft-ietf-rohc-rfc3095bis-rohcv2-profiles-02
> 
> Haipeng, all,
> 
> There seems to be two different aspects being discussed here.
> 
> o The first one is whether TBC is optional or not in the RoHCv2
> protocol.
> 
> The agreements, as you point out yourself, are that for RoHCv2:
> - the _use_ of TBC is optional for the RoHCv2 protocol (same as
> RFC3095) 
> - the _use_ of TBC is conditional to decompressor signalling that TBC
>   can be used via a nonzero clock option (also same as for RFC3095);
> - the _use_ of TBC can be activated by the compressor using
> time_stride!=0,
>   but only once the decompressor has signalled that TBC can be used
>   (also same as for RFC3095)
> 
> In other words:
> - if the decompressor never signals a nonzero clock resolution, OR
> - if the compressor never activates TBC ...
> ... the protocol still works. That is ... it's optional.
> 
> One consequence of the above is that neither the compressor or the
> decompressor is mandated to implement TBC.
> 
> One thing that is NOT a consequence of the above is: "if both
> compressor and decompressor implement TBC, TBC is used". With respect
> to the text, the use of "never required" clarifies that there is no
> requirement on the use of TBC, as per agreements listed above, while
> "signals if supported" would this ambiguous.
> 
> [Haipeng] Again, it is not my intention to say "if both compressor and
> decompressor implement TBC, TBC is used". I think we agree on this
> point. The current wording "the compressor is never required
>    to set the time_stride control field to a non-zero value when it
>    has received a non-zero value for the CLOCK_RESOLUTION option." is
> not correct because the compressor is actually required to set the
> time_stride control field to a non-zero value if the it has received a
> non-zero value for the CLOCK_RESOLUTION and the compressor decides to
> send TS value using TBC compression". As you can see from my

[GHPE] It seems it is rather the above sentence that is erroneous (or at
best confusing). In any case, it seems to go against current agreements,
as listed below by these rules:

1) The decompressor MAY send a non-zero CLOCK_RESOLUTION, as an
_indication_
   that it can handle TBC on this *channel* (i.e. not per flow).
   However, this does not mean that it "wants to do this" or that the
compressor
   shall use it; this is because the decompressor is not expected to
know of what
   flows will arrive on this channel.

2) The compressor receives this (nonzero) CLOCK_RESOLUTION; it know has
   knowledge that it MAY use TBC (i.e. it is possible to use TBC)

3) The compressor implementation MAY be designed following the
assumption
   that TBC is useful; this can be determined for each flow
individually.
   If it determines that TBC can be useful for a specific flow, then it
MAY
   activate TBC by sending a non-zero time_stride. For other flows, it
MAY
   choose not to activate TBC and thus does not have to send any
time_stride.

4) The compressor MAY at any time send time_stride=0 to disable TBC
   for any flow (if it for example finds out that the timestamp does not
   follow the criteria needed for TBC). Or for any other reason.

5) The decompressor MAY "revoke" its announcement of TBC "capability",
   by sending CLOCK_RESOLUTION=0; this forces the compressor to send
   time_stride=0 for context that were previously "TBC-activated".

6) The decompressor SHOULD send a non-zero CLOCK_RESOLUTION if it
receives
   a non-zero time_stride, unless it has previously sent a non-zero
   CLOCK_RESOLUTION for this channel.

If you can still not agree to this mail, it could be useful for us if
you can point out on which point(s) above you do not agree with. 

> alternative text proposal, the intention is to clarify this point.
> Based on your message, I believe you also agree that the compressor
> is required to set non-zero time_stride to activate TBC. So another
> possibility to reword the text is as follows:"
> When it has received a non-zero value for the CLOCK_RESOLUTION option,
> the compressor is never required to set the time_stride control field
> to a non-zero value unless the compressor needs to activate the timer
> based compression.
> "

[GHPE] I do not like this formulation because of "needs to activate
TBC". There is never any need for TBC for this protocol to work, it is
an optional feature.

> Capturing the above is the intent of the draft. I believe that the
> current text captures this very well, and I still think there is no
> reason to change the current text. Especially not to bind the optional
> aspect of a protocol feature to whether it is implemented or not
> (which seems rather moot and would be a dubious praxis IMO).
> 
> o The second aspect of this discussion is the special handling of the
> error case.
> 
> The issue addressed in the specification is related to the clock
> resolution being one of the (unfortunate) few feedback options that
> apply for the entire channel; in case the compressor, for some reason,
> has the wrong value for the clock resolution (e.g. A nonzero value),
> there is no way for all the contexts using the 0x0101 profile to
> recover if the compressor activates TBC for each one of those
> contexts, other than to signal the clock resolution. The only other
> way would be to tear down the channel, and re-establish it.
> 
> Hence we added text stating that if the decompressor receives
> time_stride!=0 while its clock resolution is set to 0 then it should
> send its clock resolution. What value is sent is still up to the
> implementation.
> 
> However, thanks for pointing out the unintended consequence from the
> compressor's perspective. In fact, I believe that for this error case,
> i.e. When the decompressor has never sent its clock resolution, the
> decompressor should be mandated to send its clock resolution with a
> zero value:
> 
> Text proposal:
> 
>   The decompressor SHOULD send the CLOCK_RESOLUTION option with a zero
> value, if:
>   - it receives a non-zero time_stride value, and
>   - it has not previously sent a CLOCK_RESOLUTION feedback with a
> non-zero value.
>   This is to allow compression to recover from the case where a
> compressor erroneously
>   activates timer-based compression.
> 
> [Haipeng] Could you please clarify which text the above proposal
> intends to replace? Are you referring to " Whether the

[GHPE] Please see above resulting text proposal.

> CLOCK_RESOLUTION is set to
> a non-zero value or to a zero value is up to the implementation"? I
> also would like to enhance the text proposal as follows"
> 
>   The decompressor SHOULD send the CLOCK_RESOLUTION option with a zero
> value, if:
>   - it receives a non-zero time_stride value, and
>   - its clock resolution is set to zero.
>   This is to allow compression to recover from the case where a
> compressor erroneously activates timer-based compression.

[GHPE] I do not like this proposal because the only thing that is
relevant to this protocol is whether or not the decompressor has sent
the option and to what value it was set to. See above explanation. The
case where the decompressor's clock resolution is non-zero but not
communicated _first_ before it receives non-zero time_stride is an error
case. The case where the compressor would "poll" the decompressor for
TBC capability is also an error case. Both would go against agreements
listed above, and would depart from how TBC works in RFC3095 as well.
 
> "
> [Haipeng] The reason for the change in the second condition is to
> cover the following case: The decompressor has a non-zero value clock
> resolution and has not sent the value in CLOCK_RESOLUTION feedback. In
> this case, it does not make sense for the decompressor to send a zero
> value.

Yes, it does. Because it is an error case and this is not a mean for the
compressor to activate TBC. A decompressor always have a clock
resolution, may have TBC implemented but might not wish to activate it
(e.g. For a specific radio bearer).

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

---

From: "Jin, Haipeng" <[email-masked]>
Date: Tue, 4 Dec 2007 17:42:53 -0800

Hi, Ghyslain,

Please see some more comments inline. I also hope we can resolve the
comments soon. The email message seems to grow quite long, but really,
there are only two issues here:
1. Whether the compressor is allowed to probe the TBC capability of
decompressor or not. 
2. "never required" wording in compressor part. I would rather see a
condition here such as "unless the compressor activates TBC". "never
required" is too absolute to cover all cases.

Thanks,
Haipeng

-----Original Message-----
From: Ghyslain Pelletier [mailto:[email-masked]] 
Sent: Saturday, December 01, 2007 2:34 AM
To: Jin, Haipeng; Kristofer Sandlund; Carl Knutsson
Cc: rohc
Subject: RE: [rohc] RE: CDRs for

Hello Haipeng,

  

OLD:

NEW:

Cheers,

///Ghyslain

[Haipeng] Agree.

2) The compressor receives this (nonzero) CLOCK_RESOLUTION; it know has
   knowledge that it MAY use TBC (i.e. it is possible to use TBC)
[Haipeng] One problem here is: if the compressor has not received any
CLOCK_RESOLUTION from the decompressor, is the compressor allowed to
send nonzero time_stride to probe the decompressor's TBC capability. I
think our difference with regard to the error case text proposal
reflects that we have different understanding on this issue. My current
proposal allows the probing capability but I am willing to be convinced
on why it is not a good idea.

[Haipeng] Agree.

[Haipeng] Agree.

[Haipeng] Not sure about this. The decompressor either has the TBC
capability or does not have the TBC capability. Rather than revoking, I
would say that the decompressor may "re-iterate" its TBC capability by
sending the corresponding CLOCK_RESOLUTION value (zero for no TBC;
non-zero for TBC). This "re-indication" of its TBC capability is used to
address the error case when the compressor sends non-zero time-stride
but the decompressor has no TBC.

6) The decompressor SHOULD send a non-zero CLOCK_RESOLUTION if it
receives
   a non-zero time_stride, unless it has previously sent a non-zero
   CLOCK_RESOLUTION for this channel.
[Haipeng] Please see comments for bullet 2) and 5). BTW, I think you
mean "SHOULD send a zero CLOCK_RESOLUTION" here.

[Haipeng] How about "unless the compressor activates the timer-based
compression"? 

 

[Haipeng] Please see my comments above. The point is not about whether
the decompressor always have a clock resolution or not. The
CLOCK-RESOLUTION is used to indicate whether it has TBC or not.

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Wed, 5 Dec 2007 05:09:21 +0100

Hi Haipeng,

Ok, so this is not a comment, this is a proposal for something new.

Again, I think that the agreement has always been to support TBC in
RoHCv2 in the same manner as in RFC3095. This means no compressor
probing and a "no requirement" stamp for the compressor wrt to use of
TBC.

Anyway, some questions about your two points below ...
Please provide clear answers.

1. What would be a motivation for compressor probing?
   What would the protocol gain from this?
   A decompressor willing to use TBC would anyway send CLOCK_RES!=0,
right?
   Why probe then? Whether you get CLOCK_RES or not the compressor
always know. 

2. Using wording like "unless the compressor activates TBC"
   invites a clarification on when TBC should be activated
   (that would be my comment at least);
   TBC is optional, so we'd have to explain it's up to implementation
   to determine whether to activate it or not.
   It seems that from a protocol perspective, this means exactly
   what the current text says, "never required", don't you agree?

Frankly, I want to make sure that my compressor and my decompressor,
when used with any other implementation will _never_ have to use TBC
(i.e. It's optional, just like in RFC3095) if I do not intend my
implementation to use TBC. I think this is just fair, the protocol works
very well without TBC, and there are cases where you don't want TBC.

Put bluntly, I wonder whether the proposal here intends to achieve the
opposite, i.e. To move the decision to use TBC to one single endpoint in
case both implement support for it. I get this from previous mails. I
hpoe it is not the case.

The draft has completed last-call. We only have a few small updates to
make. We would like to publish it soon. It is my understanding that
there is nothing broken in the draft with respect to how the agreements
are implemented in text, and that the agreements of the wg are properly
reflected. Do you agree?

Cheers,

///Ghyslain

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 06 Dec 2007 09:22:12 +0100

Haipeng, Ghyslain, all

Let us try to solve this issue quickly.

Comments inline (for both Haipeng and Ghyslain)..

/Calle

> 1. Whether the compressor is allowed to probe the TBC capability of

I can't really see the point in allowing probing. Maybe I have missed
something.

Allowing probing of TBC also breaks the TBC handskake. If the
decompressor have recently sent a feedback with a nonzero resolution and
it receives a packet with time_stride: the decompressor won't know if
the following packets use TBC or not. The compressor is either:
- starting timer-based compression. (using TBC)
- or trying to probe the decompressor (not using TBC)

The decompressor will be in a state were it doesn't know if the
compressor started TBC by misstake or if it is just probing. And there
is a risk that it will use the wrong encoding method for the RTP timestamp.

Even if we change the wording here, it is pretty clear in section 6.7.
that probing is not allowed. rtp() encoding method:

"time_stride_value: The value of this parameter should be set to
         the expected inter-arrival time between consecutive packets for
         the flow, and the selected value is implementation-specific.
         It MUST NOT be set to a non-zero value, unless the compressor
         has received a feedback message with the CLOCK_RESOLUTION
         option set to a non-zero value.  See also Section 6.6.9."

> required" is too absolute to cover all cases.

"The support and usage of timer-based compression is optional for both
 the compressor and the decompressor; the compressor is never required
 to set the time_stride control field to a non-zero value when it has
 received a non-zero value for the CLOCK_RESOLUTION option."

I suggest changing "never required" to "not required". Otherwise I
believe it is clear that sentence we are discussing is a clarification
to the fact that TBC is optional in the compressor too.

---

---

From: "Jin, Haipeng" <[email-masked]>
Date: Thu, 6 Dec 2007 11:55:44 -0800

Hi, Calle and All,

Please see comments inline.

Best,
Haipeng
-----Original Message-----
From: Carl Knutsson [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 12:22 AM
To: Jin, Haipeng; Ghyslain Pelletier; rohc
Subject: Re: [rohc] RE: CDRs for

Haipeng, Ghyslain, all

/Calle

The decompressor will be in a state were it doesn't know if the
compressor started TBC by misstake or if it is just probing. And there
is a risk that it will use the wrong encoding method for the RTP
timestamp.

[Haipeng] You have a good point here. My original understanding with
regard to how TBC is used is that the decompressor will inform the
compressor by non-zero CLOCK_RESOLUTION if it "supports" TBC, so that
the compressor will be able to make an informed decision. This is not to
say that TBC must be used if both compressor and deocompressor support
it. During discussion with Ghyslain, it appears that the current text
was intended to suggest that even if decompressor "supports" TBC, the
decompressor does not need to send the indication. That is why I
suggested probing might be needed since the decompressor may not send
the indication even if TBC is "supported". 

[Haipeng] I know Ghyslain does not like the usage of "support", so just
to further clarify what I mean by "decompressor supports TBC" here:
support = TBC is implemented + decompressor allows TBC to be used on
this particular channel.

[Haipeng] My original understanding is not contradicting with this
wording. If the decompressor supports TBC then it will send non-zero
CLOCK_RESOLUTION. Otherwise, we will have a gap here: the decompressor
supports TBC and it does not send anything, while at the same time the
compressor will not be able to use TBC. My suggestion was simply trying
to fill up this gap. Does everyone believe that we can just leave the
gap open?

[Haipeng] I am ok with your suggested change. 

---

both
required
>    to set the time_stride control field to a non-zero value when it
has
>     to set the time_stride control field to a non-zero value when it
has

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Thu, 6 Dec 2007 21:02:24 +0100

Calle, Haipeng,

> Does everyone believe that we can just leave the gap open?

I do not believe that there is a gap. My understanding is that a
decompressor that fulfills "support = TBC is implemented + decompressor
allows TBC to be used on this particular channel" will send a nonzero
CLOCK_RESOLUTION as soon as possible after the channel is configured. I
fail to conceive a logic whereas the  decision to allow TBC to be used
would come at another point.

I am also find with the change proposed by Calle.

Cheers,

///Ghyslain

Jin, Haipeng wrote:
>> comments soon. The email message seems to grow quite long, but
>> really, there are only two issues here:
> decompressor have recently sent a feedback with a nonzero resolution
> and it receives a packet with time_stride: the decompressor won't
> know if the following packets use TBC or not. The compressor is
> either: 
> the compressor will be able to make an informed decision. This is not
> to say that TBC must be used if both compressor and deocompressor
> support it. During discussion with Ghyslain, it appears that the
> current text was intended to suggest that even if decompressor
> "supports" TBC, the decompressor does not need to send the
> indication. That is why I suggested probing might be needed since the
> decompressor may not send the indication even if TBC is "supported".
> 
> [Haipeng] I know Ghyslain does not like the usage of "support", so
> just to further clarify what I mean by "decompressor supports TBC"
> here: support = TBC is implemented + decompressor allows TBC to be
> used on this particular channel.
> 
> 
> 
>          the expected inter-arrival time between consecutive packets
>          for the flow, and the selected value is
>          implementation-specific. It MUST NOT be set to a non-zero
>          value, unless the compressor has received a feedback message
>          with the CLOCK_RESOLUTION option set to a non-zero value. 
> See also Section 6.6.9." 
> 
> compressor will not be able to use TBC. My suggestion was simply
> trying to fill up this gap. Does everyone believe that we can just
> leave the gap open?
> 
>>   TBC (i.e. Set time_stride!=0). Obviously, the compressor is
>>   coherent with setting time_stride and whether it uses TBC or not,
>>   folliwong the definition of the TBC encoding.
>> 
>>    time_stride value and it has not previously informed the
>>    compressor that it supports timer-based compression using the
>>    CLOCK_RESOLUTION option with a non-zero value.  Whether the
>>    CLOCK_RESOLUTION is set to a non-zero value or to a zero value is
>> up to the implementation. 
>> 
>>    both the compressor and the decompressor; the compressor is never
>>    required to set the time_stride control field to a non-zero value
>>    when it has received a non-zero value for the CLOCK_RESOLUTION
>> option. 
>> 
>> NEW:
>> 
>>     timer_based_lsb method is used in the CO header.  The
>> decompressor .   SHOULD send the CLOCK_RESOLUTION option with a zero
>> value, if: .   - it receives a non-zero time_stride value, and
>> .     non-zero value. .   This is to allow compression to recover
>> from the case where a .   compressor erroneously activates
>> timer-based compression. 
>> 
>>     both the compressor and the decompressor; the compressor is
>>     never required to set the time_stride control field to a
>>     non-zero value when it has received a non-zero value for the
>> CLOCK_RESOLUTION option. 
>> 
>>> Thanks for the detailed response. There might be some
>>> misunderstanding here, but I would like to emphasize again that we
>>> both agree TBC is optional. The confusion here seems to be the
>>> wording used to describe this optional functionality. 
>>> 
>>> - the _use_ of TBC is conditional to decompressor signalling that
>>>   TBC can be used via a nonzero clock option (also same as for
>>> RFC3095); - the _use_ of TBC can be activated by the compressor
>>>   using time_stride!=0, but only once the decompressor has
>>> signalled that TBC can be used   (also same as for RFC3095) 
>>> 
>>> In other words:
>>> compressor and decompressor implement TBC, TBC is used". With
>>> respect to the text, the use of "never required" clarifies that
>>> there is no requirement on the use of TBC, as per agreements listed
>>> above, while "signals if supported" would this ambiguous.
>>> 
>>> [Haipeng] Again, it is not my intention to say "if both compressor
>>> and decompressor implement TBC, TBC is used". I think we agree on
>>> this point. The current wording "the compressor is never required
>>>    has received a non-zero value for the CLOCK_RESOLUTION option."
>>> is not correct because the compressor is actually required to set
>>> the time_stride control field to a non-zero value if the it has
>>> received a non-zero value for the CLOCK_RESOLUTION and the
>>> compressor decides to send TS value using TBC compression". As you
>>> can see from my 
>> 
>> [GHPE] It seems it is rather the above sentence that is erroneous
>> (or at best confusing). In any case, it seems to go against current
>> agreements, as listed below by these rules:
>> 
>>    _indication_ that it can handle TBC on this *channel* (i.e. not
>>    per flow). However, this does not mean that it "wants to do this"
>>    or that the compressor shall use it; this is because the
>>    decompressor is not expected to know of what flows will arrive on
>> this channel. [Haipeng] Agree.
>> 
>> 2) The compressor receives this (nonzero) CLOCK_RESOLUTION; it know
>>    has knowledge that it MAY use TBC (i.e. it is possible to use TBC)
>> send nonzero time_stride to probe the decompressor's TBC capability.
>> I think our difference with regard to the error case text proposal
>> reflects that we have different understanding on this issue. My
>> current proposal allows the probing capability but I am willing to
>> be convinced on why it is not a good idea. 
>> 
>> 
>>    assumption that TBC is useful; this can be determined for each
>>    flow individually. If it determines that TBC can be useful for a
>>    specific flow, then it MAY activate TBC by sending a non-zero
>>    time_stride. For other flows, it MAY choose not to activate TBC
>> and thus does not have to send any time_stride. [Haipeng] Agree.
>> 
>>    for any flow (if it for example finds out that the timestamp does
>>    not follow the criteria needed for TBC). Or for any other reason.
>> [Haipeng] Agree. 
>> 
>> 5) The decompressor MAY "revoke" its announcement of TBC
>>    "capability", by sending CLOCK_RESOLUTION=0; this forces the
>>    compressor to send time_stride=0 for context that were previously
>> "TBC-activated". 
>> 
>> 
>> capability or does not have the TBC capability. Rather than
>> revoking, I would say that the decompressor may "re-iterate" its TBC
>> capability by sending the corresponding CLOCK_RESOLUTION value (zero
>> for no TBC; non-zero for TBC). This "re-indication" of its TBC
>> capability is used to address the error case when the compressor
>> sends non-zero time-stride but the decompressor has no TBC.
>> 
>>    receives a non-zero time_stride, unless it has previously sent a
>>    non-zero CLOCK_RESOLUTION for this channel.
>>> When it has received a non-zero value for the CLOCK_RESOLUTION
>>> option, the compressor is never required to set the time_stride
>>> control field to a non-zero value unless the compressor needs to
>>> activate the timer based compression. "
>> 
>> TBC". There is never any need for TBC for this protocol to work, it
>> is an optional feature. 
>> 
>>> reason to change the current text. Especially not to bind the
>>> optional aspect of a protocol feature to whether it is implemented
>>> or not (which seems rather moot and would be a dubious praxis IMO).
>>> 
>>> o The second aspect of this discussion is the special handling of
>>> the error case. 
>>> 
>>> apply for the entire channel; in case the compressor, for some
>>> reason, has the wrong value for the clock resolution (e.g. A
>>> nonzero value), there is no way for all the contexts using the
>>> 0x0101 profile to recover if the compressor activates TBC for each
>>> one of those contexts, other than to signal the clock resolution.
>>> The only other way would be to tear down the channel, and
>>> re-establish it. 
>>> 
>>> compressor's perspective. In fact, I believe that for this error
>>> case, i.e. When the decompressor has never sent its clock
>>> resolution, the decompressor should be mandated to send its clock
>>> resolution with a zero value: 
>>> 
>>> Text proposal:
>>> 
>>>   The decompressor SHOULD send the CLOCK_RESOLUTION option with a
>>> zero value, if: 
>>>   non-zero value. This is to allow compression to recover from the
>>>   case where a compressor erroneously activates timer-based
>>> compression. 
>>> 
>>>   The decompressor SHOULD send the CLOCK_RESOLUTION option with a
>>> zero value, if: 
>> the option and to what value it was set to. See above explanation.
>> The case where the decompressor's clock resolution is non-zero but
>> not communicated _first_ before it receives non-zero time_stride is
>> an error case. The case where the compressor would "poll" the
>> decompressor for TBC capability is also an error case. Both would go
>> against agreements listed above, and would depart from how TBC works
>> in RFC3095 as well. 
>> 
>>> "
>>> cover the following case: The decompressor has a non-zero value
>>> clock resolution and has not sent the value in CLOCK_RESOLUTION
>>> feedback. In this case, it does not make sense for the decompressor
>>> to send a zero value.
>> 
>> Yes, it does. Because it is an error case and this is not a mean for
>> the compressor to activate TBC. A decompressor always have a clock
>> resolution, may have TBC implemented but might not wish to activate
>> it (e.g. For a specific radio bearer).
>> 
>> [Haipeng] Please see my comments above. The point is not about
>> whether the decompressor always have a clock resolution or not. The

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 07 Dec 2007 13:31:36 +0100

Hi Haipeng

Jin, Haipeng wrote:

> wording. 

To be strict, the probing you suggested is contradicting with the above
statement.

>           If the decompressor supports TBC then it will send non-zero
> compressor will not be able to use TBC. 

This is how we make it optional for the decompressor.

>                                       My suggestion was simply trying

I don't believe there is a gap to fill. TBC usage is a optional. Both
parties must actively agree on TBC for every new ROHC channel created.
The decompressor (with TBC-support) can choose to send or not to send a
feedback with CLOCK_RESOLUTION. It can take the decision not to enable
TBC because of any reason. This means that you cannot force TBC over a
link. This is exactly the same as in RFC3095/RFC4815. No one can force a
decompressor, using the profiles RTPv1 or RTPv2, to send feedback with
CLOCK_RESOLUTION, even if it supports TBC.

> misunderstanding
> and
> current
> not
> option,
> optional
> reason,
> case,
> zero
> zero
> the