Subject: RE: [rohc] Compressed lists in UO-1-ID packets

From: Remi Pelland <[email-masked]>
Date: Thu, 11 Sep 2003 11:13:08 -0400

I agree with the proposed clarifications.

Remi.

-----Original Message-----
From: Ghyslain Pelletier [mailto:[email-masked]]
Sent: Wednesday, August 27, 2003 11:31 AM
To: [email-masked]
Cc: [email-masked]; Ghyslain Pelletier
Subject: [rohc] Compressed lists in UO-1-ID packets

Hi all,

I have received two comments from Kristofer regarding the implementer's
guide, section 4.3.4 - "CSRC lists in UO-1-ID packets":

1) Section 4.3.4 state that even if UO-1-ID packets are not context
   updating, when carrying a CSRC list the translation table should be
   updated anyway. The comment is that this should apply to extension
   headers compressed using list compression as well. We note here
   that (RFC3095 section 5.8.6) the format is the same for CSRC lists
   and header lists, so this seems a correct observation to me.

   Thus it seems that the text in the implementer's guide should be
   rephrased so that it applies to the type of encoding, not the type
   of list, e.g. something like "Compressed list in UO-1-ID packets"
   instead of "CSRC lists in UO-1-ID packets" plus other rephrasing as
   needed in the section.

2) In rfc3095, regarding the context updating properties of UO-1*:
   the text in section 5.7.3 states:
   "Values provided in extensions, except those in other SN, TS, or
   IP-ID fields, do not update the context".
   
   Quoting the comment:

   > For example with AH-SN, if
   >
   > - no compressed list is sent in an extension 3 and
   > - the AH-SN field is not present
   >
   > then the AH-SN is assumed to be incremented by:
   > "delta_(RTP)SN * normal-AH-SN-delta".
   >
   > Therefore such "other" sequence number will be fully dependent
   > on the RTP SN (for the RTP profile) when the AH-SN is not being
   > sent.
   >
   > If the table value for this sequence number is not updated while
   > the RTP SN is updated in the context, it will be necessary to
   > either:
   >
   > a) a mapping will have to be saved for that RTP SN from which this
   >    AH-SN was derived from, so that the delta can be applied from
   >    this SN instead of from the one that will be calculated for
   >    the next packet.
   >
   > b) send at least the LSBs of the AH-SN in the next packet, since
   >    applying delta_sn from the updated RTP SN will not produce the
   >    correct result for AH-SN. This seems to be a waste of
   >    compression efficiency.

   It thus seems pointless to not update the other sequence number
   when updating the "master SN" that it is depending upon.

   As the fields SN, TS and IP-ID refer to (and only to) the fields
   as defined at the beginning of section 5.7, a clarification seems
   to be needed along the following lines:

   "The only values provided in extensions that upate the context are
   the additional bits for the SN, TS, or IP-ID fields and the sequence
   number fields of extension headers. Other values provided in
   extensions do not update the context."

Are these proper clarifications to bring into the implementer's guide?

/Ghyslain

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

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
[email-masked]
http://www.ericsson.com

I have a new mail address: [email-masked]
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

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

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