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

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 9 Dec 2004 10:14:26 -0000

Hi Carsten, all,
> 
> 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.

I've just double-checked our code and you are right.  We have an
interoperable implementation that does send bits of TS_SCALED not bits of
TS_SC_offset.  (Sorry for causing (even more) confusion.)
 
However, we use the concept of TS_SC_offset to work out whether to send any
bits of TS_SCALED.

Section 4.5.3 says 'compression method could be either W-LSB encoding or
Timer-based...' which makes no mention of slopes.  Consequently, I think
that 4.5.3 says if you don't use timer based compression then you use W-LSB
(in the same way as for SN), thereby sending LSBs in every packet for an
increasing field.
> 
> The issue we have, I think, is that 3095 is not very explicit about 
> what we do when we *don't* send a field.

I think that 3095 is not very explicit about *whether/when* we don't send a
field, as well as what we do when we don't send it.

> Indeed, my assumption here is that this is the place where the 
> default-slope values come in.

That would make sense.  However, it's too subtle in the RFC for me ;-) it's
certainly not something I considered when implementing it.

> What 5.7 tells me is that for IP-ID-offset, default-slope is 
> 0, and for 
> TS-scaled, default-slope is 1.

5.7 says that the default-slope for TS is 1.  I assume that in this case, TS
is actually referring to TS_SCALED?  Otherwise you've got an equation like:

TS = slope * SN x+ offset and the concept of TS_STRIDE has disappeared?

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

I'm a bit confused here.  In the IP-ID case we have:

Non-encoded field = IP-ID
Encoded field = IP-ID-offset
Default slope of encoded field stated = 0 (as stated in 5.7)
Implies slope of non-encoded field = 1

In the Timestamp case we have:

Non-encoded field = TS
Encoded field = TS_SCALED
Default slope of encoded field stated = 1 (assuming TS in 5.7 is TS_SCALED)
Which says nothing about the non-encoded field.

So in the IP-ID case the non-encoded field grows with SN and in the
Timestamp case the encoded field grows with SN.

When doing our implementation, and in a (possibly vain) attempt to harmonise
the handling of TS/IP_ID, we *conceptually* treat it as:

'Non-encoded' field = TS_SCALED
'Encoded' field = TS_SC_OFFSET
Assumed default slope of encoded field = 0
Implies slope of non-encoded field = 1
*BUT* when bits are required for 'encoded' field, actually *send* bits of
'non-encoded' field (and hope that the other end will interpret it
correctly..!)

> 
> (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.)
> 
Agreed.  This highlights the fact that there are two concepts - scale
(TS_STRIDE) and slope.

So, normally:
- you use slope = 1 you set scale = TS_STRIDE
- in the 'ext3 Tsc==0...' case you set slope to TS_STRIDE (and scale is 1)
  giving (assuming TS_STRIDE of 160):

    TS = (160 * SN + offset) * 1 + 0

In the case where no bits are sent, which you do makes no difference (a
change in SN gives the same change in TS either way).  In the case where
bits are sent, the bits sent and the interpretation that should be put on
them depends on which way round you have defined scale and slope.

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

I'm not sure which you're referring to as proposal 1?

Best regards,

Abbie

> 
> Gruesse, Carsten
> 
> 
> _______________________________________________
> 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: Carsten Bormann <[email-masked]>
Date: Thu, 9 Dec 2004 12:49:24 +0100

> However, we use the concept of TS_SC_offset to work out whether to 

Right, since this is about whether you send it at all.

> (in the same way as for SN), thereby sending LSBs in every packet for 

Again, 4.5 has this problem in that it describes what you send if you 
do send.

> field, as well as what we do when we don't send it.

Well, that rule is simple: You can only "not send" if the decompressor 
will regenerate the right header!
So the rule is implictly created from the rule that says what the 
decompressor will do if a field is not encoded in the header.

> certainly not something I considered when implementing it.

Yes, I think we all agree that's a bug in the RFC.

> 5.7 says that the default-slope for TS is 1.

Well, it says this in a somewhat disambiguating context:

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

> I assume that in this case, TS
> is actually referring to TS_SCALED?

Yes, this is how I read it.
The problem is that a lot of other places also just say "TS" and really 
mean "the thing that you get out of section 4.5 to encode TS".

> Implies slope of non-encoded field = 1

Yes.

> Which says nothing about the non-encoded field.

No.  Neither did I, above?

> Timestamp case the encoded field grows with SN.

That's my conclusion, which I would put slightly differently:
With IP-ID, if it is not encoded in the header, it grows in parallel SN.
With TS, if it is not encoded in the header, it grows in parallel with 
TS_STRIDE*SN (independent of Tsc!).

> 'non-encoded' field (and hope that the other end will interpret it

You lost me.
Maybe "non-encoded" and "encoded" mean something different here than in 
my mind...

The first one of:

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

I would maybe word it slightly differently, as the text explicitly says 
that "default-slope(IP-ID offset) = 0", which of course *is* equivalent 
to "default-slope(IP-ID) = 1".

Gruesse, Carsten