Subject: [rohc] RFC 3095 scaled TS - Part I : value(Tsc)=0

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 31 Aug 2006 14:29:32 +0200

ROHCers,

When reviewing the timestamp encoding part of the implementer's guide,
some inconsistencies and confusing details have been identified. This
mail is the first out of two addressing these issues.

Section 4.2 of the implementer's guide (currently revision 19) reviews
(de)compression of TS without transmitted TS bits. The text says that
similar as for the case when TS bits are transmitted, when no TS bits
are transmitted either scaled or unscaled TS can be used. Both are thus
covered by the corrected text, simply inspired by RFC 3095.

However, section 4.5.3 of RFC 3095 explicitly states that "Context(Tsc)
is always 1", which means that the only way to use non-scaled TS when
no TS bits are transmitted would be by forcing the use of an odd packet
format (UOR2-ID, UO-1-ID, R-1-ID) without TS bits but which can carry
extension 3 and thereby set Tsc=0. Doing so would really be a corner
case, not really intended by the protocol design, and neither would it
be useful in any way. One interpretation would be that non-scaled TS can
never happen without transmitted TS bits, and another interpretation
could be that this is indeed allowed by using these odd packet format
combinations. We must clarify which interpretation is correct, and the
former seems to be the clearest, simplest and most reasonable. The
resulting changes to the implementer's guide would then be as follows:

(1): Rewrite of section 4.1 "Encoding used for compressed TS bits"

OLD:

RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in
Extension 3, W-LSB encoded values are sent using the self-describing
variable-length format (section 4.5.6), and this applies to both
scaled and unscaled values.

NEW: 

RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. When no TS bits are
transmitted in a compressed packet, TS is always scaled. If a
compressed packet carries an extension 3 and field(Tsc)=0, the
compressed packet must thus always carry unscaled TS bits. For TS
values sent in Extension 3, W-LSB encoded values are sent using the
self-describing variable-length format (section 4.5.6), and this
applies to both scaled and unscaled values.

(2): Rewrite of section 4.2
        "(De)compression of TS without transmitted TS bits"

 [ first paragraph unchanged ]

OLD: 
-------------------------------------
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.
in SO-state operation. This section specifies how the TS (scaled or
unscaled) is decompressed 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 decompressed assuming a linear
extrapolation from the SN, i.e. delta_TS = delta_SN * default-slope,
where delta_SN and delta_TS are both signed integers. Section 5.7
defines the potential values for default-slope.

INCOMPLETE RFC 3095 TEXT (section 5.7):

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

CORRECTED TEXT:

   "When a compressed header with no TS bits is received, the encoded
    TS value (scaled or unscaled) is decompressed assuming a linear
    extrapolation from the SN, i.e. delta_TS = delta_SN * default-
    slope(TS).

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

NEW:
-------------------------------------
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.
This section specifies how the scaled TS is decompressed when no TS bits
are transmitted in the compressed header.

When no TS bits are transmitted in the compressed header, the scaled TS
value is reconstructed assuming a linear extrapolation from the SN, i.e.
delta_TS = delta_SN * default-slope, where delta_SN and delta_TS are
both signed integers. Section 5.7 defines the potential values for
default-slope.

INCOMPLETE RFC 3095 TEXT (section 5.7):

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

CORRECTED TEXT:

   "When a compressed header with no TS bits is received, the scaled
    TS value is reconstructed assuming a linear extrapolation from the
    SN, i.e. delta_TS = delta_SN * default-slope(TS).

    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). If a packet with no TS bits
    is received with Tsc=0, the decompressor MUST discard the packet."
-------------------------------------

(3): Rewrite of section 4.7 "TS_STRIDE and the Tsc flag in Extension 3"

OLD (second paragraph):

If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
being set, the TS field in the compressed header SHOULD contain unscaled
TS bits, i.e. the Tsc flag SHOULD NOT be set when Tss is set since an
unscaled TS is needed together with TS_STRIDE to recalculate the
TS_OFFSET. If TS_STRIDE is included in a compressed header with scaled
TS, the decompressor must ignore and discard field(TS_STRIDE).

NEW (second paragraph):

If TS_STRIDE is present in Extension 3, as indicated by the Tss flag
being set, the compressed header SHOULD carry unscaled TS bits, i.e.
the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS is
needed together with TS_STRIDE to recalculate the TS_OFFSET. If
TS_STRIDE is included in a compressed header with scaled TS, the
decompressor must ignore and discard field(TS_STRIDE).

Any comments on these changes?
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]                      /"\
Phone: +46 8 404 29 61                                      \ /
Fax: +46 920 996 21               ASCII Ribbon Campaign      X
Home: +46 63 355 24            against HTML email & vCards  / \

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc