Subject: RE: [rohc] The discussion on slope(s) (redux)

From: "West, Mark" <[email-masked]>
Date: Thu, 9 Dec 2004 01:50:49 +0000 (GMT)

Hi All,

We decided it was about time we put our two penn'orth / Eurocent / Kronor
/ cents / whatever (or more) into this discussion.  This is going to be
quite a long mail so we'll put a summary first with detail to support it
below:

Firstly, and as no great surpise, we agree that the concept of slope in
3095 is confused and not properly defined. :-)

In particular, we agree that the concept of implicit slope has potential
synchronisation problems; and we don't believe has been actually
implemented / tested.

However, we do think that the concept of slope is useful for compressing
timestamp efficiently (particularly in the case of video).  It could also,
perhaps, have been used to solve the linux-zero-ip-id-problem..!

Consequently, it seems best for the implementers' guide to clarify that,
although the concept of slope exists in 3095, it is confused and either:
- should not be considered at all; or
- (if it is 'used') that there is no way to change the default slope.

As we'll explain below, though, it is possible to define and use slope to
compress 'video'-style RTP headers efficiently; we just think that is
should be done with explicit signalling of slope.  (As to 'how': well,
that's a separate thread!)  We'd certainly support more discussion on this
approach!

Without further ado, here's the gory detail:

First of all, from reading the quoted sections of 3095, the concept of
slope is confused.  Before thinking about timestamp, let's consider IP-ID.

IP-ID is a non SN field so according to 5.1.2.2 it should follow the rule:

  non-SN-field = SN * slope + offset           [1]

Fine.  But section 4.5.5 states that for the IP-ID the offset should be
compressed with LSB encoding and the offset is given by:

  Offset_i = ID_i - SN_i,                      [2]

To make these equations compatible, the slope for IP-ID is fixed and equal
to 1.

First "Question to implementers": do you solely rely on equation [2] for
compressing IP-ID or do you include the concept of slope?  (I assume by
the fact that we have interoperable implementations, that we actually all
just use equation [2].)

Section 5.7 makes no mention of default-slope(IP-ID) but it does say that
the default-slope(IP_ID_offset) is 0.  Referring to the default-slope
(IP_ID_offset) implies that IP_ID_offset can fit into equation [1].  If
you put it into equation [1] you either stick with the default-slope
(IP_ID_offset) = 0 and equation [1] is the identity OR you allow the slope
to change and equation [1] becomes recursive :-( We assume, therefore,
that this has to indicate a mistake, somewhere along the line...

If we do consider the possibility of using equation [1] for IP-ID, then,
with a slope of zero, the linux-zero-ip-id-behaviour (for which there is a
completely different and new solution in the ip-only profile) could be
handled.  However, there is no way to change the slope of IP-ID within
3095 and we would hazard a guess that none of the implementers, at least,
considered slope with respect to IP-ID.

Another question is: what is the expected behaviour in the case where the
source IP stack is sending two flows which happen to be alternating
packets?  This may lead to the IP-ID for each flow incrementing in regular
steps of 2.  From what's in the rfc and what we *assume* folks have
implemented, we believe that LSBs of IP-ID-offset would be sent in every
packet and you'd never reach SO state.  Any comments..?

Why are we waffling on about IP-ID, I hear you ask?

Because it's all related in the dingy soup of RFC 3095!

But, OK, let's consider timestamp.  Again it is a non-SN-field so it can
be expressed using equation [1].  However, 4.5.3 also defines scaling
using the equation:

  TS = TS_SCALED * TS_STRIDE + TS_OFFSET		[3]

Point 2 of this section states that TS_SCALED can be compressed using
either W-LSB encoding or timer-based encoding.  Obviously in this
discussion we are focussing on W-LSB encoding.  Consider the audio case:

> Example 1 (audio stream with TS_STRIDE = 160):
>
>             <------ String 1 ------>    <-- String 2 --->
> SN           11  12  13  14 ...   60    61    62    63    64 ...
> TS          200 360 420 580 ... 8040 16040 16200 16360 16520 ...
> TS_SCALED     1   2   3   4 ...   50   100   101   102   103 ...
> TS_OFFSET    40  40  40  40       40    40    40    40    40 ...

If you compress TS_SCALED using W-LSB encoding, then in the same way as
for SN you will need to send LSBs on *EVERY* packet (so you'll never get
to SO state).  4.5.3 says nothing about relating TS_SCALED to SN.

So when _we_ (at least) implemented 3095 we assumed that once you had
scaled the TS you offset it from the SN in the same way as for IP-ID.
That is, you get extra lines in the above table:

TS_SC_offset -10 -10 -10 -10 ...   -10    39    39    39    39 ...
send (LSB)   -10 -10 -10  -  ...    -     39    39    39     - ...

We send the LSBs of the TS_SC_offset value rather than of the TS_SCALED
value.  Question to other implementers: do you do the same?  (We assume
so, otherwise we don't see how we interoperated - which we did last time
we came out to play [which was a couple of interops ago, but...])

If this assumption is correct, then we are all using the equations:

  TS = (SN + TS_SC_offset) * TS_STRIDE + TS_OFFSET	[4]

Which assumes:

  TS_SCALED = SN + TS_SC_offset 				[5]

Therefore we are actually considering TS_SCALED as a non-SN-field that
follows equation [1] with a fixed slope of 1.

Note that if this assumption is *NOT* correct, then the LSBs can only be
applied to TS_SCALED.  But that, we believe, would assume a fixed
TS_SC_offset (i.e. a slope of 1...)

The main problem comes when we consider video:

If we set TS_STRIDE to 3000, as suggested by Zhigang, we get:

              <------ String 1 ---------->  <-- String 2 --->
SN              11    12    13  ...    25    26    27    28    29    30...
TS            4000  4000  4000  ...  4000  7000  7000  7000  7000  7000...
TS_SCALED        1     1     1  ...     1     2     2     2     2     2...
TS_OFFSET     1000  1000  1000  ...  1000  1000  1000  1000  1000  1000...
TS_SC_OFFSET   -10   -11    -12 ...   -24   -24   -25   -26   -27   -28...
send (LSB)     -10   -11    -12 ...   -24   -24   -25   -26   -27   -28...

We are, once again, having to send LSBs of a timestamp related field on
*EVERY* packet.

Does setting TS_STRIDE to zero (and restating the equations to avoid
division by zero), as suggested by Kristofer and Lars-Erik help?  No,
because we get:

              <------ String 1 ---------->  <-- String 2 --->
SN              11    12    13  ...    25    26    27    28    29    30...
TS            4000  4000  4000  ...  4000  7000  7000  7000  7000  7000...
TS_SCALED        -     -     -  ...     -     -     -     -     -     -...
TS_OFFSET     4000  4000  4000  ...  4000  7000  7000  7000  7000  7000...
TS_SC_OFFSET -3989 -3988  -3987 ... -3975 -6974 -6973 -6972 -6971 -6970...
send (LSB)   -3989 -3988  -3987 ... -3975 -6974 -6973 -6972 -6971 -6970...

We're still sending LSBs of a timestamp related field on EVERY packet.

Consequently, we think the "real" equation required for timestamp (and,
in fact, any 'non-SN-field') is:

  TS = (a * SN + off_a) * b + off_b		[6]

where we might refer to 'a' as 'slope' and 'b' as 'scale' and 'off_b' is
in the range 0 .. off_b - 1.

Thus, setting a (slope) to 1 and b (scale) to 1 (eliminating off_b), we
get:

  x = (SN + off_a)				[7]

which is exactly the IP-ID case.

Setting a (slope) to 1, off_a to TS_SC_offset,  b (scale) to TS_STRIDE,
and off_b to TS_OFFSET, we get:

  TS = (SN + TS_SC_offset) * TS_STRIDE + TS_OFFSET		[8]

But allowing the slope to vary gives:

  TS = (a * SN + TS_SC_offset) * TS_STRIDE + TS_OFFSET		[9]

This assumes:

  TS_SCALED = a * SN + TS_SC_offset			[10]

Which, [9], is in exactly the form of equation [1].  In the audio case a =
1, in the video case a = 0.

Thus, we think that the concept of slope (= a) is useful to state
explicitly and use explicitly for the most efficient compression of
timestamp in the widest set of cases.

*BUT*, it's a bit of a mess in 3095, as it stands.

We also agree with Kristofer, that the idea of *implicit* slope could lead
to incorrectly decompressed R-mode packets being passed up the stack
without detection (see
http://www.ietf.org/mail-archive/web/rohc/current/msg03067.html).

Zhigang's latest mail answers this in part: but we haven't thought through
the implications of "change of slope" fully -- i.e. how to re-evaluate 'a'
whilst sending TS_SC_offset for 'a != 1'.  Frankly, though, it seems
complex and error prone.  (The derivation of TS_OFFSET, in contrast,
requires only the use of the fact that a/b gives a quotiant and remainder
such that a=b*q+r, with 0<=r<q).

Also, if the implementers' guide were to state that there was implicit
slope for timestamp, then why would this not apply to IP ID?  (Although it
appears that the application of this to IP ID is internally
contradictory...)

Anyway, for slope to be useful, we think that it's best if it is:

- Clearly defined;
- Applicable in all modes;
- Explicitly transmitted; and
- Explicitly applied (or not) to each applicable 'non-SN-field'.

Therefore, with respect to the implementers' guide, our proposal is that
it should either:

- indicate that the concept of slope exists; but that there is no way to
change the 'default' slope and that the slope for both IP-ID and TS_SCALED
is 1; or

- that the concept of slope is ill-defined and should not be used, at all.

We prefer the former, as this opens the way to make use of an explicitly
signalled slope to make the compression (at least of TS) more flexible.
As to how such explicit signalling could be done (new control field;
random abuse of the existing control fields; ...), well that's a different
discussion!

There may be a couple of other points that we intended to make, but this
feels like a reasonable summary of our opinion(s).  And if you've actually
read this far, then we're really quite impressed..!

Cheers,

Abbie and Mark

PS -- Abbie did most of the serious thinking; any random errors are
probably mine!

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Dec 2004 08:12:22 +0100

Mark,

I believe 4.5.3 is quite explicit about what we send if we *do* send a 
(scaled) timestamp.
So I think your proposal to explicitly send an offset (TS_scaled - SN) 
instead of just the timestamp is not supported by the text.

The issue we have, I think, is that 3095 is not very explicit about 
what we do when we *don't* send a field.
Indeed, my assumption here is that this is the place where the 
default-slope values come in.
What 5.7 tells me is that for IP-ID-offset, default-slope is 0, and for 
TS-scaled, default-slope is 1.
Both mean the same: the default value for a non-encoded field is 
growing with the SN, both IP-ID slope and TS-scaled slope are set to 1.

(Note that defining a default-slope for Tsc=0 is just covering for the 
special case of an ext3 with Tsc==0 and R-TS==0 -- we can live with a 
variable slope here because it is explicitly signaled as TS_STRIDE, but 
I have no idea why you would use this combination in the first place, 
except that you can.)

In summary, I believe the text of 3095 supports your proposal 1.

Gruesse, Carsten