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

From: "Ghyslain Pelletier" <[email-masked]>
Date: Wed, 21 Nov 2007 12:28:49 +0100

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
ts_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.

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
ts_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.

A simpler approach would be to specify only that the decompressor can
send at any time a zero value for CLOCK_RESOLUTION, especially for the
error case. This would also allow the decompressor to disable TBC on the
fly.

Obviously, the intent here is to describe decompressor behavior, which
in this case is the receiver of ts_stride, and not compressor behavior
aiming to force the decompressor to send its clock resolution.

A side note: it is perfectly acceptable for a RoHC endpoint to not
signal support for a profile that it implements; for example, in case
the profile is not applicable to the link (or radio bearer) for which
the RoHC implementation is instantiated for.

Cheers,

///Ghyslain

Quoting "Jin, Haipeng" <[email-masked]>:

> Hi, Ghyslain,
> 
> Thanks for the response, I removed all the agreed ones and have some
> comments on the remaining two items.
> 
> Best Regards,
> Haipeng
> 
> >    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.---
> > +++If the decompressor supports timer-based compression, then the
> > decompressor includes a non-zero value when sending the
> > CLOCK_RESOLUTION option. Otherwise, if the decompressor does not
> > support timer-based compression, the decompressor sets the value of
> > CLOCK_RESOLUTION option to zero. +++
> 
> [GHPE] Not Ok. TBC is optional to implement, and it is optional to
use.
> This was agreed on the list, and is no different than for RFC3095.
There
> is thus no reason to bind the use of TBC based on whether is it
> implemented or not. Furthermore, from a pure protocol design
> perspective, such a statement would not make sense.
> 
> [Haipeng] We both agree that TBC is optional to implement and use. The
> rewording I provided is simply to clarify that if the decompressor
> supports TBC, then it includes non-zero value. Note that this is
> different from bind the use of TBC to whether it is implemented or
not,
> the non-zero value is just an indication that the decompressor
supports
> TBC. Whether TBC is used or not is decided by the compressor. 
> 
> [Haipeng] I am not sure what you mean by protocol design issue. We use
> the term "support" in RFC4995 and RFC3241 plenty of times. For
example,
> the RFC talks about "Define the set of profiles supported by the
> decompressor" instead of saying "whether the decompressor includes a
> certain profile id or not is up to the implementation".  If the end
> point "supports" (if you allow me to use the term :-)) a profile, why
> wouldn't it indicate the support of the profile? Similarly, if an end
> point supports TBC, why wouldn't it indicate the support of this
> capability? Again, this does not mean that the end point needs to make
> use of TBC even if it supports the capability.
> 
> [GHPE] My proposal is to leave the text unchanged.
> 
> >    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.---
> > +++The compressor only sets the time_stride control field to a
> > non-zero value when it supports timer-based compression and wants to
> > compress the timestamp value based on this mechanism. +++
> > "
> 
> [GHPE] Not Ok. Same reasons as above. In addition, the wording
> "supports" and "wants" does not have a meaning from a protocol
> perspective, these are implementation-related choices.
> 
> [Haipeng] I think this is the same issue as above. Does "never
required"
> have more meaning than "support" from a protocol design perspective? A
> different way of stating the sentence based on the existing text you
> used on the compressor side is: "
> The compressor sets the time_stride control field to a non-zero value
to
> request CLOCK_RESOLUTION feedback from the decompressor if it has not
> previously received any CLOCK_RESOLUTION option from the decompresor"
> 
> So that we have some corresponding text to "
> >    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.
> ".
> 
> 
> [GHPE] My proposal is to leave the text unchanged.
>  
> 
> _______________________________________________
> 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: "Jin, Haipeng" <[email-masked]>
Date: Sat, 24 Nov 2007 11:15:16 -0800

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,

In other words:

[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 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.
"

Text proposal:

[Haipeng] Could you please clarify which text the above proposal intends
to replace? Are you referring to " Whether the 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.

"
[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.

Cheers,

///Ghyslain

compressor
CLOCK_RESOLUTION
implementation.---
use.
There
not,
supports
example,
required"
to
compressor
CLOCK_RESOLUTION