Subject: Re: TS clarification (was: [rohc] The discussion on slope(s) (redux))

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 10 Jan 2005 14:27:33 +0100

Hi!
Sorry for the late response.

I think Lars-Erik's text provides the clarification that most people seem to 
agree on.
My personal opinion is that this also makes the least possible change to the 
spec to resolve this issue. If we were to somehow try to come up with a 
_working_ and _interoperable_ version with some kind of implicit learned slopes, 
the changes to the specification will have to be far more substantial than this, 
so there's no doubt in my mind that L-E's proposal is the right way to go.

/Kristofer Sandlund, Effnet AB

Lars-Erik Jonsson (LU/EAB) wrote:
> To capture the findings of this discussion, I propose to add the
> following two sections to the implementer's guide.
> 
> BR
> /L-E 
> 
> 
> 4.2. (De)compression of TS without transmitted TS bits
> 
> RFC 3095 briefly explains that ROHC RTP in its most efficient compression operation, conceptually described as the SO-state, apart from packet type identification and the error detection CRC, compressed headers only carry RTP sequence number (SN) bits. All other fields are then either omitted because they are unchanged, or 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.
> 
> For 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 there is no other slope value used than the default_slope value, as defined in section 5.7, and it can never be changed. 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 with 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 to not allow a compressor to do that, the formula of "2. Compression" should not be read as having any formal meaning.
> 
> 
> 
> 
>>-----Original Message-----
>>From: Carsten Bormann [mailto:[email-masked]]
>>Sent: den 9 december 2004 14:15
>>To: Lars-Erik Jonsson (LU/EAB)
>>Cc: West, Mark; Surtees, Abigail; Carsten Bormann; [email-masked]
>>Subject: Re: [rohc] The discussion on slope(s) (redux)
>>
>>
>>
>>On Dec 09 2004, at 13:57 Uhr, Lars-Erik Jonsson (LU/EAB) wrote:
>>
>>
>>>Folks,
>>>
>>>
>>>>>So in the IP-ID case the non-encoded field grows with SN 
>>
>>and in the
>>
>>>>>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!).
>>>
>>>Which could also be expressed as:
>>>With TS, if it is not encoded in the header, its scaled
>>>representation grows in parallel with TS_STRIDE.
>>
>>s/scaled/unscaled/
>>
>>(The scaled representation grows in parallel with SN.)
>>
>>
>>
>>>TS can thus be communicated in three ways:
>>>1) Unscaled
>>
>>...and sent with WLSB
>>
>>
>>>2) SCALED and sent with WLSB
>>>3) SCALED, inferred from SN
>>
>>Yes.
>>
>>
>>>It seems like 1) and 2) are "clear" from 3095, while what is really
>>>missing is a defined decompression (and thus compression)
>>>logic for 3).
>>
>>Well, at least 3095 says that Tsc is 1 in the context, so 
>>SCALED is the 
>>more likely interpretation, I'd say.
>>
>>
>>>The "default slope" value would be an important
>>>part of that logic, and I guess most implementers have actually
>>>used that value for the simple function
>>>TS_SCALED=(SN-SN_OLD)*default_slope + TS_SCALED(SN_OLD)
>>>for decompression of TS_SCALED when no TS bits are sent.
>>>
>>>Q: Would default_slope be used when decompressing based
>>>   on TS bits actually sent?
>>
>>No.  4.5.3 is quite clear on what to do.
>>
>>
>>>Q: Can default_slope be anything but 1?
>>
>>(If Tsc is 1:) No.  See 5.7.
>>
>>
>>>Q: Can TS bits ever be omitted when sent unscaled?
>>
>>Yes, with an ext3 if Tsc is 0, R-TS is 0, and no TS bits are in the 
>>base (i.e., UOR-2-ID) header carrying the ext3.
>>
>>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