Subject: [rohc] Context repairs, TS_STRIDE and TIME_STRIDE

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 14 Jun 2006 17:52:18 +0200

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

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 Ghyslain.Pelletier at ericsson.com
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------

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

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 15 Jun 2006 11:51:50 +0200

Hi Ghyslain and ROHCers,

I don't have anything to add to the suggested addition to the 
implementer's guide or to the problem description regarding this issue.

I it have already acknowledged addition to the to Ghyslain offline. I 
thought it would be a good idea to do it on the list too.

rgds,

//Calle