Subject: RE: TS clarification (was: [rohc] The discussion on slope(s) (red ux))

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 12 Jan 2005 17:41:55 -0000

Hi Lars-Erik, all,

Happy New Year!  Apologies for the delay.  Mark and I agree with the text
proposed.  We've word-smithed it a bit below to make some of the sentences
clearer.  One other comment:
- use default-slope instead of default_slope to be consistent with RFC 3095
(we've changed as many as we spotted :-))

Best regards, 

Abbie

4.2. (De)compression of TS without transmitted TS bits

RFC 3095 explains that SO-state provides the most efficient compression
within ROHC RTP.  In this state, apart from packet type identification and
the error detection CRC, RTP compressed headers carry only RTP sequence
number (SN) bits.

All other fields are then omitted either because they are unchanged or
because they can be reconstructed through a function from the SN (i.e. by
combining the transmitted SN bits with state information from the context).

> Although it is 
> never spelled out explicitly what fields are inferred from 
> the SN in this way, one should be able to figure out that 
> this principle applies to the IP Identification (IP-ID) field 
> and the RTP Timestamp (TS) field.
> 

IP-ID compression and decompression, both with and without transmitted IP-ID
bits in the compressed header, are well defined in section 4.5.5 (see
section 8.2 of this document). 

> However, for TS it is only defined how to 
> decompress based on actual TS bits in the compressed header, 
> either scaled or unscaled, but not how to infer the TS from 
> the SN, i.e. the SO-state operation. Although the general 
> idea is simple, the actual operation must be clearly defined 
> to ensure interoperability. There are also inconsistent text 
> pieces that might confuse an implementer and result in 
> non-interoperable implementations. This section therefore 
> provides the necessary clarifications to SN-to-TS 
> decompression, i.e. decompression of TS (scaled or unscaled) 
> when no TS bits are transmitted in the compressed header.
> 
> When no TS bits are transmitted in the compressed header, the 
> encoded TS value (scaled or unscaled) is to be decompressed 
> assuming a linear extrapolation from the SN, i.e. delta_TS = 
> delta_SN * default-slope. 
> 
> Section 5.7 defines the potential values for default-slope as:
> 
>   If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
>   compression (see section 4.5.3), and default-slope(TS) = 1.
> 
>   If value(Tsc) = 0, the Timestamp value is compressed as-is, and
>   default-slope(TS) = value(TS_STRIDE).
> 

What must be noted here is that no slope value is used other than the
default-slope value, as defined in section 5.7. 

> There is confusing text in 
> section 5.5.1.2 that might mistakenly be interpreted as if 
> the slope can have different values and be "learned", which 
> is incorrect. The default-slope from 5.7 is always the value 
> used when decompressing TS based on SN.
> 
> 
> 4.4. TS_STRIDE for scaled timestamp encoding
> 
> The timestamp stride (TS_STRIDE) is defined as the expected 
> increase in the timestamp value between two RTP packets with 
> consecutive sequence numbers. TS_STRIDE is set by the 
> compressor and explicitly communicated to the decompressor, 
> and it is used either as the scaling factor for scaled TS 
> encoding, or constitutes the default-slope used when 
> decompressing an unscaled TS through a linear extrapolation 
> from the SN (see also section 4.2 above).
> 
> The relation between TS and TS_SCALED, given by the following 
> equality in section 4.5.3, defines the mathematical meaning 
> of TS_STRIDE:
> 
>    TS = TS_SCALED * TS_STRIDE + TS_OFFSET
> 
> In the compression step explained following this core 
> equality of section 4.5.3, TS_SCALED is incorrectly written 
> as TS / TS_STRIDE. This formula is incorrect both because it 
> excludes TS_OFFSET, and because it would prevent a TS_STRIDE 
> value of 0. 

If "/" were a generally unambiguously defined operation meaning "the
integral part of the result from dividing X by Y", the absence of TS_OFFSET
could be explained, but the formula still lacks a proper output for
TS_STRIDE equal to 0. As the core equality above does not prevent setting
TS_STRIDE to 0, and there is no reason not to allow a compressor to do that,
the formula of "2. Compression" should not be read as having any formal
meaning.

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

---

From: [email-masked]
Date: Mon, 17 Jan 2005 19:58:01 -0500

I'm amazed. I haven't seen a "clarification" that has so many 
logic holes in it. I may be alone on this (it seems so at this moment),
but it in worst case will break RFC 3095, and at the best will make 
text of RFC 3095 inconsistent. 

Just a few examples below.

> > TS_SCALED is incorrectly written 
> > excludes TS_OFFSET, 

No, it does NOT. Did anyone read the following text from section 
4.5.3 in RFC 3095? Or it simply doesn't matter, as people can now 
freely change RFC 3095 in whichever way they like?

   1. Initialization: The compressor sends to the decompressor the value
      of TS_STRIDE and the absolute value of one or several TS fields.
      The latter are used by the decompressor to initialize TS_OFFSET to
      (absolute value) modulo TS_STRIDE.

> > and because it would prevent a TS_STRIDE value of 0. 

That's how it is intended to be. TS_STRIDE is a scale factor, not slope.
Therefore, it is supposed to be non-zero.

Isn't that obvious from section 4.5.3???

> integral part of the result from dividing X by Y", 

That *is* the meaning of "/". Otherwise, what else could it mean here?
Or in the following appearances throughout RFC 3095? Are all of them
going be to be called "ambiguous" as well?

Section 4.5.3:
- the TS will increase by n * 3000 (= n * 90000 / 30) between video frames.
- 0xFFFFFFFF / TS_STRIDE

Section 4.5.4:
- (a_n - a_j) / TIME_STRIDE
- T_approx = T_ref + (a_n - a_ref) / TIME_STRIDE

(Section 4.5.4 even goes extra mile to note: "Integer arithmetic is used in all 
equations above." Now it seems this should also be put in section 4.5.3. Well,
I don't believe even that can prevent the twisting of words ...)

Section 5.7.6.8:
- (a_i - a_j) / TIME_STRIDE

> the absence of TS_OFFSET could be explained, 

What absence??? Isn't the TS_OFFSET clearly specified (see above)?

BR, Zhigang

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 19 Jan 2005 17:14:25 -0000

Hi All,

How about rephrasing the final paragraph to:

"In the compression step explained following this core equality of
   section 4.5.3, TS_SCALED is written as TS / TS_STRIDE.
   This formula assumes (as in the rest of the RFC) that "/"  means 
   "the integral part of the result from dividing X by Y", however, 
   this is clearly undefined if TS_STRIDE has a value of 0.  As the
   core equality above does not prevent setting TS_STRIDE to 0 
   (leaving TS = TS_OFFSET), and there is no reason not to allow a 
   compressor to do that, the formula of "2. Compression" should be 
   seen as a possible way for RoHC instances to calculate TS_SCALED 
   and TS_OFFSET, however, it is not to be used if TS_STRIDE = 0."
?

I agree that "/" is generally accepted to mean "the integral part of the
result from dividing X by Y" so we shouldn't write text that implies this
might not be the case.

Best regards,

Abbie

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 20 Jan 2005 10:04:06 +0100

Folks,

Let me make a few observations related to the "/" discussion:

1) In 3095, "/" is used for integral division ONLY for TS scaling,
   so it is plain wrong(tm) to claim that it is generally used in
   this way in 3095.

2) In general, I strongly disagree that "/" is normally used for 
   integral division. In all sophisticated programming languages,
   integral division has its own operands, while "/" is the operand
   generating a decimal result. "mod" is often defined to generate
   the reminder from integral division, while an operand with names
   such as "div", "floor", etc are defined and used for the integral
   division itself. None of these can be claimed to be generally
   accepted and understood, but point being that integral division
   is special and usually handled with care. In this case, it had
   of course been enough if section 4.5.3 had made clear what was
   meant. 

3) Even assuming "/" means the integral part of the division result,
   the formula in "2." can only be used to calculate TS_SCALED, not
   TS_OFFSET.

I therefore question this reformulation, as I do not see what is
actually wrong with the previous text. I could accept the suggested
text if we removed "(as in the rest of the RFC)", as well as "and TS_OFFSET" (due to reasons above), but still I can not see what
would be the point of changing what is currently there.

BR
/L-E

> -----Original Message-----
> From: Surtees, Abigail [mailto:[email-masked]]
> Sent: den 19 januari 2005 18:14
> To: [email-masked]'; Lars-Erik Jonsson (LU/EAB); 
> [email-masked]
> Cc: West, Mark; [email-masked]
> Subject: RE: TS clarification (was: [rohc] The discussion on slope(s)
> (red ux))
> 
> 
> Hi All,
> 
> -- 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is proprietary to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>

---

From: [email-masked]
Date: Fri, 21 Jan 2005 20:19:31 -0500

Hi,

Again, below is my proposal on the clarification of TS encoding.
It's essentially the same proposal I sent out back in April 2004.
I made some updates based on comments/questions from Carsten and
Kristofer (thanks). 

I also added an example on AMR SID frames. Pawel mentioned SID
frames also back in April last year, but the message was ignored:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02138.html

The text is a bit lengthy. But I think it's important to make it
as clear as possible, so that people can really look into the 
bottom of the issue.

As always, your comments/questions are welcome.

BR, Zhigang

=================================================================
As it is described clearly in section 4.5.3 and other places 
in RFC 3095 (4.5.4, 4.5.7, 5.7, 5.7.5, 5.7.5.2), TS_STRIDE is the 
factor by which an RTP Timestamp is downscaled before compression. 
Specifically, when scaling is used for TS, two steps are 
performed by the compressor: 1) downscale of the original 
TS to TS_SCALED; and 2) compression of TS_SCALED. 

Another way to look at this: instead of compressing a sequence 
of original TS, the compressor will compress (i.e. going through 
FO/SO states, etc.) a sequence of TS_SCALED as if they were unscaled. 
The only difference is that the compressor "pre-processes"
the original TS as specified in Step 2 in section 4.5.3 and 
the decompressor derives the original unscaled TS as specified in 
Step 3. Of course, both the compressor and decompressor must also
handle the wraparound case as described in Step 4 and 5.

It should be therefore clear that TS_STRIDE and slope are two
separate and independent ROHC parameters. In short, TS_STRIDE is 
for scaling and slope is for SO state. To elaborate further:

- TS_STRIDE is a parameter independent of states, i.e., it applies
all the time regardless of FO or SO state. To the contrary, slope(TS)
or slope(TS_SCALED) is a parameter only used for SO state, as part
of the linear function from SN to TS or TS_SCALED.

- TS_STRIDE is meaningful only for the original unscaled TS, while 
slope applies to both scaled and unscaled TS.

- TS_STRIDE cannot be 0 (see section 4.5.3) while slope(TS) or
slope(TS_SCALED) can.

- Although in certain scenario (see Example 1 below), TS_STRIDE
and the slope of unscaled TS may have the same value, it is not 
always the case. 

- One example is the TS for a video stream, where TS_STRIDE can 
be set to 3000 while slope(TS_SCALED) can be set to 0 (see 
Example 3 below). 

- Another example is Adaptive Multi-rate (AMR) speech codec
(see Example 2 below). AMR is a mandatory codec by 3GPP for 3G 
cellar systems, which is the main driver for and application 
target of ROHC. During a silence period, AMR codec will generate 
Silence Descriptor (SID) frames every 8*20=160 ms, instead of 20 ms
for regular speech frames in a talkspurt period. That means the TS 
change between two RTP packets with consecutive SN will be 
160 (=8000KHz*0.020sec) for talkspurt periods and 1280(=8000KHz*0.160sec)
for silence periods. In this case, the compressor can set 
TS_STRIDE = 160 all the time to allow TS scaling, while set 
slope(TS_SCALED) to 1 during talkspurt periods and 8 during 
silence periods. This enables the compressor to enter SO states 
during both types of periods without having to establish a new 
TS_STRIDE value (which means sending the original unscaled TS together
with the new TS_STRIDE value in Extension 3, see section 4.5.7
and 5.7.5). Note that an AMR audio stream generated in a typical 
voice conversation usually alternates between talkspurt and silence 
periods since only one party speaks at any time.

The major source of confusion on this subject is the definition 
of TS_STRIDE in section 2, which is inaccurate and contradicts the
text of section 4.5.3. It may be interpreted as TS_STRIDE is _always_ 
equal to the increase in TS value between two RTP packets with 
consecutive sequence number, i.e., TS_STRIDE is the slope of TS.
This is incorrect and not the intent of the specification, as 
evidenced by the description and usage of TS_STRIDE in section 4.5.3
and other sections. Unfortunately, this interpretation went uncaught
both on paper and in past interoperability tests because the 
TS_STRIDE and slope(TS) do have the same value in case of certain 
RTP packet streams (see above).

Another source of confusion is that although slope is described 
in section 5.5.1.2 and 5.7, the text is not as clear as it should
be in terms of implementation. (One reason is that the authors of 
RFC 3095 were under pressure to make the document concise, which 
unfortunately left out some useful details in retrospect.) To clarify, 
slope has the general meaning in mathematics. Namely, slope(X) equals 
the change of a non-SN field X between two packets divided by the 
change of SN field between the same two packets. It is one of the 
two parameters (the other one being offset) that define a linear 
function from SN to a header field X. The function can also be 
visualized as line segments, with SN being the horizontal coordinate
and the field X being the vertical coordinate. In the case of RTP 
timestamp compression, field X can be either TS or TS_SCALED.

Following is the decompressor logic on how to calculate the
slope(TS). Obviously, integer arithmetic is used here.
Note that the exact implementation may be different as long 
as it generates the same result. Also note that the same logic
applies to the scaled TS, by simply replacing TS with TS_SCALED.

1) Initialize slope(TS) as specified in section 5.7. 

  Note: for the case of scaled TS, the default-slope(TS) below 
        means default-slope(TS_SCALED). It should be understood
        that RFC 3095 uses TS to mean either unscaled or scaled 
        RTP Timestamp as it is clear based on the context. 

2a) When receiving more than one update packets that carry TS bits 
before receiving Type 0 packets, calculate slope(TS) and offset(TS)
as follows:

    slope(TS) = (TS2 - TS1) / (SN2 - SN1)

    offset(TS) = TS2 - SN2 * slope(TS)

where {SN1, TS1} and {SN2, TS2} are the SN and TS values of the last 
two context-update packets it has received (and ACKed if in R-mode).

2b) When receiving only one update packet that carries TS before
receiving Type 0 packets, slope(TS) is unchanged. Note that if this
is the first time the decompressor receives a Type 0 packet after
context initialization, this means slope(TS) = default-slope(TS).

3) The decompression of TS for a Type 0 packet N is straightforward as
described in RFC 3095, i.e., TS(N) = SN(N) * slope(TS) + offset(TS). 
Or equivalently, TS(N) = (SN(N) - SN(U)) * slope(TS) + TS(U), where
U denotes the last received context-update packet. Note that for the
latter approach, the decompressor does not need to calculate offset(TS)
as shown above.

The compressor simply follows the logic described in RFC 3095.
Namely, it must ensure the decompressor has acquired the function
from SN to TS (or TS_SCALED in case of scaled TS) for current string
before sending any Type 0 packets.

To help implementers, following are some examples to illustrate how 
TS encoding works exactly. A "X" mark in the CU-PKT row means the 
corresponding packet is a context-update packet. All other packets
can be Type 0 packets. Note that for simplicity, the examples assume 
no packet loss between the source and ROHC compressor, and between
the ROHC compressor and decompressor. For the same reason, the examples
assume TS_STRIDE has already been synchronized. Also, R-mode is assumed
here but the same examples apply to UO-mode with only minor changes.

Example 1: 
(an audio stream with TS_STRIDE = 160 and TS_OFFSET = 40; no packets
transmitted during silence periods. String 1 and String 2 correspond to 
two talkspurts. String 1 is the first string for this context.)

           <----- String 1 ------>    <----- String 2 ------->
SN         11  12  13  14 ...   60    61    62    63    64 ...
CU-PKT      x                          x     
TS        200 360 520 680 ... 8040 16040 16200 16360 16520 ...
TS_SCALED   1   2   3   4 ...   50   100   101   102   103 ...
slope     <---------- 1 --------->    <---------- 1 --------->
offset    <-------- (-10) ------->    <--------- (39) ------->

  Note: only 1 context-update packet is needed for each of String 1
        and String 2, because the slope(TS_SCALED) is same as
        default-slope(TS_SCALED).

  Note: to give an example, packet 61 can be an UOR-2-TS with 
        Extension 0, which is 4 bytes in total excluding CID. Its 
        TS field (in both base and extension) carries 01100100,
        i.e., the 8 LSBs of 100.

Example 2: 
(an AMR audio stream with TS_STRIDE = 160 and TS_OFFSET = 40; SID 
frames transmitted during silence periods. String 1 corresponds 
to a talkspurt while String 2 corresponds to a silence period 
following the talkspurt. String 1 is the first string for this
context.)

           <----- String 1 ------>   <---- String 2 ------->
SN         11  12  13  14 ...   60   61   62    63    64 ...
CU-PKT      x                         x    x 
TS        200 360 520 680 ... 8040 8520 9800 11080 12360 ...
TS_SCALED   1   2   3   4 ...   50   53   61    69    77 ...
slope     <---------- 1 --------->   <--------- 8 --------->
offset    <-------- (-10) ------->   <------ (-435) ------->

  Note: two context-update packets are needed for String 2
        since the slope(TS_SCALED) changes from 1 to 8. Packet
        61 and 62 can be UOR-2-TS with Extension 0.

Example 3: 
(a video stream with TS_STRIDE = 3000 and TS_OFFSET = 1000;
String 1 is the first string for this context. )

          <------ String 1 ------>  <--- String 2 -->
SN          11   12   13 ...   25    26   27   28 ...
CU-PKT       x    x                   x
TS        4000 4000 4000 ... 4000  7000 7000 7000 ... 
TS_SCALED    1    1    1 ...    1     2    2    2 ...
slope     <--------  0 --------->  <------ 0 ------->
offset    <--------- 1 --------->  <------ 2 ------->

  Note: two context-update packets are needed for String 1 
        because the slope(TS_SCALED) is different from the 
        default-slope(TS_SCALED). 

  Note: packet 26 can be a UOR-2-TS (3 bytes).

One concern has been raised about a possible worst case scenario,
in which a loss of synchronization on slope may remain undetected
across multiple strings - essentially a damage propagation. For
instance, if packet 11 in Example 3 contains a residual error 
(i.e. error not detected by link layer) and that error is not 
detected by ROHC CRC either, it will result in an incorrect SN or
TS or both on the decompressor side. That in turn will likely 
(but not necessarily) lead to an incorrect slope when packet 11 
is used during the calculation (see decompressor logic above). 
If the compressor does not update the slope in subsequent strings
by sending two context-update packets AND the strings are too 
short to force the compressor to send R-0-CRC packets, the 
decompressor may keep using the incorrect slope in those strings
to decompress R-0 packets and thus cause damage propagation. 

At a first glance, this is a perfect disaster scenario which
may mean (in theory) all of subsequent R-0 packets in the entire
ROHC session will be damaged. However, a deeper look turns
out that it is very unlikely to happen because it has to survive 
through a series of defense lines and the very cause why it 
was started in the first place:

1) The expected residual error rate is low. It is recommended 
that lower layers deploy error detection for ROHC headers 
and do not deliver ROHC headers with high residual error 
rates. Although no hard limit on the rates was given, 
1E-5 was referred to as the ROHC design target.

2) UOR-2 packets carry stronger 7-bit CRC (instead of weaker 3
bits). So the chance of a residual error not being detected by 
ROHC CRC is very low (< 1/128).

3) Even if the error escaped the CRC, an incorrect (SN, TS) 
does not necessarily lead to an incorrect slope. For example,
if SN of packet 11 in Example 3 is incorrectly decompressed
as 10, the decompressor will still derive slope = 0.

4) The residual error that planted the incorrect slope into 
decompressor context will face 7-bit CRC validation in the
subsequent UOR-2 packets . In the above example, decompression 
of packet 12 will use packet 11 as reference. Therefore, the 
CRC in packet 12 will likely to catch the errors in (SN, TS) of
packet 11. Similarly, packet 26 will check on packet 12, and 
so on. Therefore, it is very likely that the decompressor will
detect context damage (which injected incorrect slope) and start
a context recovery procedure which will stop damage propagation.

5) Going back to the root, the problem is significant only if 
the residual error rate at the link layer is high. However, if
that is the case, a residual error will likely to happen again on 
a UOR-2 packet after the one that introduced the incorrect slope. 
When that happens, it is very likely (probability > 127:1) that 
the new error will be caught by ROHC CRC. Again, this will 
trigger a context recovery procedure and stop damage propagation.

Above analysis shows that the probability of damage propagation
across multiple strings caused by incorrect slope is extremely low.
Nevertheless, there are a few options available if an implementation
is really concerned about any possibility of that being happening:

- The compressor sends a R-0-CRC packet during SO state even if 
it does not have to.

- The compressor updates the slope(TS) or slope(TS_SCALED) even
if the slope does not change. In fact, an implementation probably
need to do this anyway, for the robustness against packet loss.
For example, the compressor may send 2 UOR-2 packets even though 
only 1 UOR-2 packet is needed by the decompressor. The extra 
packet introduce redundancy against possible packet loss.
=============================================================

---

From: [email-masked]
Date: Fri, 21 Jan 2005 20:55:49 -0500

Hi Abbie,

The problem is not really about the definition of "/". It becomes
a problem only because the text below attempts to deny what section 
4.5.3 of RFC3095 says clearly. That is, TS_STRIDE is a scale factor, 
not slope. It is so clear that one has to redefine "/" to work around it.

And even redefining "/" is not enough. What about the "modulo" 
operation used to calculate TS_OFFSET (see below)? Are you going to 
redefine it as well to twist the meaning of section 4.5.3?

  TS_OFFSET = (absolute value) modulo TS_STRIDE

It just doesn't hold together.

BR, Zhigang

> From: ext Surtees, Abigail [mailto:[email-masked]]
> Sent: 19 January, 2005 11:14 AM
> To: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked];
> [email-masked]

---

From: [email-masked]
Date: Fri, 21 Jan 2005 21:21:51 -0500

>    generating a decimal result. 

Lars-Erik,

Have you ever written code in C/C++? I don't know if they are qualified
as "sophisticated programming languages" you mentioned above, but 
"/" below generates an integer. 

   unsigned int i = 10 / 3;

BR, Zhigang

PS. Please keep me on the CC list if you reply an email to me. Thanks.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 24 Jan 2005 10:13:18 +0100

> Have you ever written code in C/C++? I don't know if they are 
> qualified as "sophisticated programming languages" you mentioned
> above, but "/" below generates an integer. 
> 
>    unsigned int i = 10 / 3;
> 
> BR, Zhigang

Sure, I have written lots of C code, and no, C/C++ does not qualify
as sophisticated languages in my mind, especially not when it comes
to type handling. 

Anyway, this is just a minor side issue and a detail in the exact
wording of the TS encoding clarification. Unfortunately, I have to
agree with you that you seem to be all alone with your opinion on
this subject, and I am sorry to say that we will thus not be able
to get complete WG agreement on the issue. However, we do have rough
consensus to go with the resolution now present in the implementer's
guide (although we might adjust details in the wording).

Rgds,
/L-E

---

From: [email-masked]
Date: Tue, 25 Jan 2005 18:19:04 -0500

Lars-Erik,

Just a few points/questions:

- Which "sophisticated programming language" did you use when implementing
RFC 3095?

- RE the hair-splitting on "/", it reflects the awkward attempt of changing
section 4.5.3 of 3095 without admitting it. And I guess you will have to 
redefine the meaning of "modulo" in section 4.5.3 as well? Of course, you
want call these as minor issues now ...

- Do you still remember the "direct appeal" you sent me in December 2004,
to identify "text parts of RFC that you say would have to be twisted
hard if there was no slope". Well, this is one of them.

- I wasn't alone on my opinion in March/April 2004. Pawel Szymanski and 
Kamal Deep Singh agreed with me. Not surprisingly, the discussion stopped
at that point.

- If I hadn't insisted on looking into the technical issues (especially 
with examples I provided), this discussion would have been buried 
sometime ago. It's obvious that some people are inventing new solutions
as they see my examples (e.g. the 0 slope for video). However, they never 
care to look at the existing solution I presented with the examples, 
which by-the-way has been discussed in detail during the development
of 3095 and which doesn't contradict 4.5.3. Why people do that? Don't ask me.

- Please read my updated proposal and give your technical comments.

BR, Zhigang

> From: ext Lars-Erik Jonsson (LU/EAB)
> [mailto:[email-masked]]
> Sent: 24 January, 2005 03:13 AM
> To: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked]

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 26 Jan 2005 11:35:23 +0100

Zhigang, ROHCers, 

This discussion has been going on for a very long time now. It started
in March and got stalled in April since we were not able to get to a
conclusion at that point, discussions were lengthy and sometimes rather
aggressive but there was no progress. Since the issue had to be resolved,
I restarted the discussion after the Washington meeting, where this had
been brought up as a problem we must tackle. At this point, we were 
lucky to get constructive opinions from more people, and the discussion
actually progressed towards a rough WG consensus. 

The reasons for going with the solution now captured in the implementer's
guide were mainly these:

1) A solution with an implicitly updated slope is not defined in 3095.
   This was captured already in the original posting by Pawel in March:
     "The mechanism is not described in the standard. Only 
      default_slope values are defined."
   The solution is also consistent with this, making clear that there
   is no implicitly updated slope(s), but there are default-slope values
   used for decompression when no bits are transmitted in the compressed
   header.

2) Since this issue is a true flaw in 3095 with normative consequences,
   any resolution would imply changes with normative meaning. However, 
   to actually define a fully working and interoperable solution with
   implicitly updated slope(s) would require much more changes to 3095
   than to rule out any possibility to interpret 3095 as if there were
   implicitly updated slope(s). 

3) When looking at potential ways to actually define an implicit slope
   mechanism, people got really concerned about the synchronization 
   problems associated with it, and even yourself noticed that:
     "I have to be honest: there might be, but I'm not sure yet."
   Examples of when it would fail could be identified, and those were met
   by case-by-case fixes, as we did not seem to be able to see a way to
   define this that would prove to be safe. Also, it was noticed that the
   flexibility of the compressor would be significantly affected if it were
   forced to always consider the need to properly update the slope(s), as 
   well as the need to avoid unintended updates. Mark noted that if
   slope(s) were ever to be updated, it should had been by explicit means.
   This exercise just made argument 2) above even stronger.

4) The technical argument for having dynamic slope(s) at all was seen
   as rather insignificant, as the compression gain for the realistic
   cases considered would be minimal (if any). This motivation is of less
   relevance than 1), 2), and 3), but it is still worth mentioning as this
   was the argument raised in favour of dynamic slope(s) back in March.

To summarize: The WG has concluded that the resolution to capture in the
implementer's guide is to make clear that there are no implicitly updated
slopes, and also clarify the meaning of default-slope(s), etc. The chairs
thus consider the core question on which way to go with slopes closed,
but comments on the exact wording for that resolution in the implementer's
guide are of course very welcome.

BR
/Lars-Erik

---

From: [email-masked]
Date: Wed, 26 Jan 2005 12:30:38 -0500

>       default_slope values are defined."

But Pawel agreed with me later (April 2004) that TS_STRIDE and slope are 
two different things. He also gave another reason (AMR SID frames) in
addition to what I provided. 
http://www1.ietf.org/mail-archive/web/rohc/current/msg02138.html

Did you read it?

Also, did you read email Kamal who also agreed with me also in April 2004?
http://www1.ietf.org/mail-archive/web/rohc/current/msg02100.html

>      "I have to be honest: there might be, but I'm not sure yet."

First, here is what I said in full context:

  "This is still being discussed. I have to be honest: there might 
   be, but I'm not sure yet. Either way, I don't think it's a 
   problem serious enough to kill implicit slope."

Second, being honest and straightforward is what I believe a 
constructive way for technical work. So, above was my state of mind 
back in December last year. I don't make conclusion before I do my own
homework. Later I had time to do more analysis on the concern, which 
shows it is insignificant. Please read my updated proposal and tell
me if you agree or not, and why.

>    as rather insignificant, 

Why did you reach this conclusion? Have you read above emails from
Pawel and Kamal? Have you sent out any technical analysis to backup
your opinion?

BR, Zhigang