Subject: [rohc] ROHCv2 profiles - IR-DYN: to be or not to be?

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 Oct 2006 16:32:25 +0200

Hi all,

in the ongoing discussion of state machine etc in ROHCv2, we have come to a stage where we seem to agree that the IR-DYN packet is troublesome and something should be done. Ghyslains mail sums up what the problems
are so read that for a more in-depth explanation.
The text below presents what options we have to choose from. It also
talks a bit about the IR packet and how the different choices impact
the choice of decompressor state machine. This mail is not intended to
make a decision on the state machine, so reply to this only with what
you think we should do with the IR-DYN packet. After we have some idea
of what we want to do with this, we can discuss the resulting state
machine and if any changes to the IR are wanted.

1) We "fix" the IR-DYN:
  This means
  - we add a CRC-7 to the format

    and either

  - 1a) Change the dynamic chain so that control fields cannot be 
    optional and instead will always update the context, no matter if 
    they are explicitly present or not. This would probably mean that
    ts_stride is changed from "optional_stride" encoding to 
    "zero_or_sdvl" so that if no bits are sent, the value is always 
    reverted to zero. If we do this type of change, the IR packet
    also becomes more robust and can be used to transit directly to
    FC state. Downside of this is more overhead in some cases,
    especially when both ts_stride and time_stride (to be added) are
    set to non-zero values (this can mean up to 8 bytes extra overhead).

    or

  - 1b) Also add a control_crc3 as is done in co_common that verifies
    the UVALUE of the affected control fields so that when these fields
    are not present in the packet, they still get verified to avoid 
    "bad ACKs" (i.e. undetected context damage)
    If we go for this, we should probably add the same type of CRC to
    the IR packet for consistency reasons.
    The overhead is less than in 1a), but this means that the
    IR-DYN has 3 different CRCs (which is ridiculous), and IR has two.

  For both of the above, a 2-step transition is not a must, but we
  can choose to keep that or we can go to a 1-step state upgrade.

2) We don't define an IR-DYN packet format for the v2 profiles, which 
   removes this troublesome packet format from the profiles and instead 
   make sure that IR or co_common will be used for context repair.
   A concequence of this would be that we remove "profile downgrade"
   option. In the v1 profiles, this defined downgrades are:
    - RTP -> UDP
    - UDP -> IP
    - any containing ESP NULL -> ESP
    - UDP-Lite/RTP -> UDP-Lite
   I feel that these transitions are quite rare and my feeling is 
   that it is fine for ROHCv2 to make these downgrades happen via full
   reinitialization (using IR)
   Advantages of this approach is that it would allow simpler 
   implementations and the state transitions can be made more robust 
   without having to resort to adding lots of CRCs.
   If we choose this option, we can either keep the 2-step state upgrade
   from NC->IC->FC for IR, or we have to reinforce the IR as described
   in 1) to allow for a simple 1-step transition. Both of these 
   alternatives are viable if we remove the IR-DYN.

3) We keep the IR-DYN as-is. We must then keep the 2-step state upgrade

I would prefer to go with option 2, i.e. remove the IR-DYN altogether,
since that closes some of the situations that bad implementations can
cause, and we don't have to patch up either the state machine or
this packet format just to do that.
What does the rest of the list think?

/Kristofer

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

---

From: "Jin, Haipeng" <[email-masked]>
Date: Fri, 13 Oct 2006 15:03:06 -0700

I also prefer "removing IR-DYN". As Kristofer pointed out below, the
downgrade operation can be performed using IR. 

Removing IR-DYN also makes the spec simpler and thus avoids the
unnecessary confusions.

Thanks,
Haipeng

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 7:32 AM
To: [email-masked]
Subject: [rohc] ROHCv2 profiles - IR-DYN: to be or not to be?

Hi all,

in the ongoing discussion of state machine etc in ROHCv2, we have come
to a stage where we seem to agree that the IR-DYN packet is troublesome
and something should be done. Ghyslains mail sums up what the problems
are so read that for a more in-depth explanation.
The text below presents what options we have to choose from. It also
talks a bit about the IR packet and how the different choices impact
the choice of decompressor state machine. This mail is not intended to
make a decision on the state machine, so reply to this only with what
you think we should do with the IR-DYN packet. After we have some idea
of what we want to do with this, we can discuss the resulting state
machine and if any changes to the IR are wanted.

1) We "fix" the IR-DYN:
  This means

    and either

    or

/Kristofer