Subject: RE: [rohc] Context repairs, TS_STRIDE and TIME_STRIDE

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

Since there have been no objections to this, I've updated
the draft with a new section 8.11, as suggested.

/L-E

----Original Message----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]]
Sent: den 14 juni 2006 17:52
To: [email-masked]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: [rohc] Context repairs, TS_STRIDE and TIME_STRIDE

> RoHCers,
> 
> We (Kristofer and myself) had an offline mail discussion with
> Carl Knutsson to sort out a potential problem in RFC3095.
> 
> A brief description of the issue is as follow:
> 
> When TS_STRIDE and/or TIME_STRIDE are updated by UOR-2
> extension 3, they are not used for decompression of the UOR-2
> packet in which they appear. This means that the update to
> these fields is not verified, either implicitely (from the
> verification of an uncompressed field that is dependant on
> those fields) nor explicitely (from the CRC itself).
> 
> And then the decompressor may ACK this packet (SN=X), so the
> compressor assumes that the update for TS_STRIDE and
> TIME_STRIDE has succeeded. Would a subsequent packet fail
> decompression, and would it be because of the TS_STRIDE or
> the TIME_STRIDE being faultily updated, the decompressor
> can't find out. It would then send feedback with SN=X. The
> compressor can't know either that TS_STRIDE and/or
> TIME_STRIDE is the problem, since SN=X has been updated. And
> then it would attempt the repair with a header (IR, IR-DYN or
> UOR-2) without sending TS_STRIDE and/or TIME_STRIDE. Until it
> receives a static-NACK, in which case it sends an IR ... for
> which there is no reason to send TS_STRIDE and/or TIME_STRIDE either.
> 
> ... and so on, without repairing the deocmpressor context!
> 
> Ok, this is a very dark picture, but it could occur and it
> would be perfectly acceptable behavior from both the
> compressor and the decompressor according to RFC3095 + current IG.
> 
> Therefore, we'd like to propose the following text to the
> Implementer's guide. 
> 
> Comments welcome.
> 
> ///Ghyslain
> 
> Proposed text:
> --------------
> 
> 8.11.  Context repairs, TS_STRIDE and TIME_STRIDE
> 
>   The 7-bit CRC used to verify the outcome of the decompression
>   attempt covers the original uncompressed header. The CRC
>   verification thus excludes TS_STRIDE and TIME_STRIDE, as these
>   fields are not part of the original uncompressed header.
> 
>   The UOR-2 packet type can be used to update the value of the
>   TS_STRIDE and/or the TIME_STRIDE, with the extension 3. However,
>   these fields are not used for decompression of the RTP TS field
>   for this packet type and their respective value is thus not
>   verified, either implicitely or explicitely.
> 
>   When the compressor receives a negative acknowledgement, it
>   can thus not determine if the failure may be caused by an
>   unsuccessful update to the TS_STRIDE and/or the TIME_STRIDE
>   field(s), for which a previous header that last attempted to
>   update their value had previously been acknowledged.
> 
>    FORMAL ADDITION TO RFC 3095:
> 
>       "When the compressor receives a NACK and uses the UOR-2 header
>        type to repair the decompressor context, it SHOULD include
>        fields that update the value of both the TS_STRIDE and the
>        TIME_STRIDE whose value it has updated at least once since the
>        establishment of that context, i.e. since the CID was first
>        associated with its current profile.
> 
>        When the compressor receives a static-NACK, it MUST include in
>        the IR header fields for both the TS_STRIDE and the TIME_STRIDE
>        whose value it has updated at least once since the
>        establishment of that context, i.e. since the CID was first
> associated with its
>        current profile."
> 
> ///Ghyslain

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