Subject: [rohc] Updating the ROHC impl. guide

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 25 Feb 2003 13:30:37 +0100

Hi all,

The Berlin interop generated a couple of questions on 3095, 
and some new issues have also been raised on the mailing list
since October when we made the last update of the impl. guide.

I've tried to collect these, address the questions and find
answers. My proposals for how to capture these issues in the
implementer's guide can be found below. Please let me know if
something is not clear or if there are ideas for improving the
clarifying texts.

Thanx!
/L-E

NOTE: All section references in this document refer to 3095,
if not explicitly stated otherwise.

1) Section 4.9 should clarify that a UO-1-ID packet with an
   Extension 3 must never be sent with RND flags that changes
   the packet interpretation, i.e. that would violate the base
   condition for UO-1-ID (at least one RND value must be 0).
   The last line of the first paragraph is also redundant and
   unclear.

 * Proposed modified text for the first paragraph of section 4.9:

  "Extension-3 is applied to give values and indicate changes to
   fields other than SN, TS and IP-ID in IP header(s) and RTP
   header.  In case of UO-1-ID packets, it should be noted that
   values provided in extensions do not update the context, with
   an exception for SN, TS and IP-ID fields, which always update
   the context (Section 5.7.3.). It should also be noted that a
   UO-1-ID packet with Extension 3 must never be sent with RND
   flags that changes the packet interpretation, i.e. that would
   violate the base condition for UO-1-ID (at least one RND value
   must be 0)."

2) It should be clarified that W-LSB encoding is used for TS, both
   if it is sent unscaled or scaled. Further, it should be noted
   that TS_OFFSET must be recalculated when an unscaled TS is
   received.

 * Proposed modification of section 4.2:
   - Change 4.2 to become "TS encoding considerations"
   - Renumber current 4.2 to 4.2.2.
   - Add 4.2.1., "Encoding of TS values"
  "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."

   - Add 4.2.4, "Recalculating TS_OFFSET"
  "TS can be sent unscaled if the TS value change does not match
   the established TS_STRIDE, but the TS_STRIDE might still stay
   unchanged. To ensure correct decompression of subsequent packets,
   the decompressor should therefore always recalculate the RTP TS
   modulo, TS_OFFSET, when a packet with an unscaled TS value is
   received."

3) It has been noted that there is an ambiguity about the
   "CC" and "Generic CSRC list" in 5.7.7.6. The question is
   whether CC=0 actually means that there are no CSRC items
   present at all (as the CC field means in RTP), or if an
   "empty" generic compressed CSRC list of at least 1 octet
   must still be present. The former should be the obvious
   interpretation as the CC field would otherwise have no
   meaning at all, and as the latter interpretation would
   just waste useless octets. However, this is not totally
   clear from the text, and it is currently not discussed 
   in the implementer's guide. Another list compression question
   is whether a 7-bit bit mask can be used also when there are
   more than 7 items in the list. 

 * Proposed addition to the impl. guide:
   - Change 4.3 to become "List compression issues"
   - Rename current section 4.5 to "CSRC list items in RTP
     dynamic chain"
   - Renumber current sections 4.3-4.5 to 4.3.1-4.3.3
   - Renumber current section 4.15 to 4.3.4
   - Renumber subsequent sections 4.6-4.14 to 4.4-4.12
   - Rewrite the beginning of current section 4.5. to say:
  "Section 5.7.7.6 defines the static and dynamic parts of
   the RTP header.  In the dynamic part, a 'CC' field indicates
   the number of CSRC items present in the 'Generic CSRC list'.
   It should be noted that when the value of this CC field is
   equal to zero, there is no Generic CSRC list present in the
   dynamic chain, i.e. the field comment should have said
   "variable length, present if CC > 0". A 'CC' field can also
   be found within the 'Generic CSRC list' (when present), and
   these fields would then have the same meaning. In order..."
   - Add subsection 4.3.5, "Bit masks in list compression"
  "A 7-bit or 15-bit mask may be used in the insertion and/or
   removal schemes for compressed lists. It should be noted that
   even if a list has more than 7 items, a 7-bit mask can be
   used as long as changes are only applied in the first part of
   the reference list, and all items with an index not covered
   by the 7-bit mask are then kept unchanged."

4) Section 4.11 seems to be totally incorrect, as RTP SN is only
   16 bits long, and feedback packets can carry 16 bits. I do 
   not know where this section comes from, but it should be removed.

5) For the UDP profile, all formats are the same as for profile 1,
   if not explicitly stated otherwise. However, it is rather unclear
   from section 5.11.3 whether "New format:" for UOR-2 means the
   format is changed for UOR-2-only, or if this new format replaces
   UOR-2, UOR-2-ID, and UOR-2-TS. In fact, it does replace all of
   them.

 * Proposed addition to the impl. guide:
   - Add new section 4.xx, "UOR-2 in profile 2 (UDP)":
  "One single new format is defined for UOR-2 in profile 2, which
   replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from
   profile 1. The same UOR-2 format is thus used independent of if
   there are IP headers with a corresponding RND=1 or not."

6) As suggested by Zhigang and agreed on the list, we should give
   an additional clarification in section 4.7.

 * Proposed additional paragraph in 4.7:
  "An updating packet thus updates the reference values of all
   header fields, either explicitly or implicitly. In UO-mode,
   all packets are updating packets (except for UO-1-ID, which
   only updates TS, SN and IP-ID, see 5.7.3), while in R-mode
   all packets with a CRC are updating packets."

7) As Carsten noted on the list, the logical union of suboptions
   for IPCP and IPV6CP negotiations, as specified by RFC 3241,
   can not be used for the PROFILES suboption, as the whole 
   union must then be considered within each of the two IPCP
   negotiations to avoid getting an ambiguous profile set.

 * Proposed new section 6, "PROFILES suboption in ROHC-over-PPP"
  "The logical union of suboptions for IPCP and IPV6CP
   negotiations, as specified by RFC 3241, can not be used for
   the PROFILES suboption, as the whole union would then have
   to be considered within each of the two IPCP negotiations, to
   avoid getting an ambiguous profile set. An implementation of
   RFC 3241 must therefore make sure the same profile set is
   negotiated for both IPv4 and IPv6 (IPCP and IPV6CP)."

-----------------------------------
Lars-Erik Jonsson, M.Sc
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 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

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

---

From: "Mikael Degermark" <[email-masked]>
Date: Tue, 25 Feb 2003 08:12:25 -0700

Couple of comments below.

----- Original Message ----- 
From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
To: "Rohc (E-mail)" <[email-masked]>
Sent: Tuesday, February 25, 2003 5:30 AM
Subject: [rohc] Updating the ROHC impl. guide

<snip>

>    not know where this section comes from, but it should be removed.

I don't have the document in front of me, but the ESP SN is 32 bits, 
so that may explain it.