Subject: [rohc] ROHC Updation

From: Biplab Sarkar <[email-masked]>
Date: Wed, 09 May 2007 14:29:48 +0530

All,

I have some queries.

[1] Why do we have the selective updation of attributes to the context
for Type-1 packets?
[2] What is the updation rule for the RTP header flags (e.g Mode) when
sent in UO-1-ID Ext3 pkt?

------------------------ RFC4815
---------------------------------------------
6.2.  Updating Properties of UO-1*

   RFC 3095-Section 5.7.3 states that the values provided in extensions
   carried by a UO-1-ID packet do not update the context, except for SN,
   TS, or IP-ID fields.  However, RFC 3095-Section 5.8.1 correctly
   states that the translation table in the context is updated whenever
   an (Index, item) pair is received, something that is contradicted by
   the statement in RFC 3095-5.7.3 because the UO-1-ID packet can carry
   Extension 3 with (Index, item) pair items within the 'Compressed CSRC
   list' field.  In addition to this contradiction, the text does not
   mention what to do with the other sequence numbers inferred from the
   SN, which are also to be implicitly updated.  The updating properties
   of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete.

   INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3):

      "Values provided in extensions, except those in other SN, TS, or
       IP-ID fields, do not update the context."

   CORRECTED TEXT:

      "UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers
       of IP extension headers.  Other values provided in extensions do
       not update the context.

       The decompressor MUST update its translation table whenever an
       (Index, item) pair is received, as per RFC 3095-Section 5.8.1,
       and this rule applies also to UO-1-ID packets."
-------------------------------------------------------------------

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 9 May 2007 11:36:50 +0200

Hi,

comments inline.

Biplab Sarkar <mailto:[email-masked]> wrote on den 9 maj
2007 11:00 :

> All,
> 
> I have some queries.
> 
> [1] Why do we have the selective updation of attributes to
> the context for Type-1 packets?

For U/O-mode, it was a clear design flaw to make partially updating
packet
with the UO-1-ID packet which will not happen again in ROHCv2. For
RFC4815,
we were unable to change too much behavior from 3095, so we had to
settle
with clarifying how it was initially supposed to work even though this
is quite
a silly feature (why would anyone want to have the case that things are 
partially updating, but only when we have an IP-ID and it is sequential?
If this would be a good feature, it should have applied to all types of
input,
but I'd say it isn't even a good feature).

The reason for that being in the spec is *probably* that there was an
empty bit
that could be used for extensions and no one really stopped to consider
the
large impact it has on decompressor implementations to be forced to
handle
the UO-1-ID-ext3.

> [2] What is the updation rule for the RTP header flags (e.g
> Mode) when sent in UO-1-ID Ext3 pkt?

Those are not updated. I think the text you quote below is quite clear
on that it is only SN-dependent fields and some list compression stuff
that are updated.

BR,
  Kristofer

>    RFC 3095-Section 5.7.3 states that the values provided in
>    extensions carried by a UO-1-ID packet do not update the context,
> except for SN,
>    Extension 3 with (Index, item) pair items within the 'Compressed
>    CSRC list' field.  In addition to this contradiction, the text
>    does not mention what to do with the other sequence numbers
> inferred from the
>    SN, which are also to be implicitly updated.  The updating
>    properties of UO-1* as stated by RFC 3095-Section 5.7.3 are thus
> incomplete. 
>