Subject: [rohc] ROHC Mode transitions questions

From: Remi Pelland <[email-masked]>
Date: Tue, 24 Sep 2002 15:52:10 -0400

Hi,

I have the following questions about the mode transitions documented in
section 5.6 of RFC3095:

1) Section 5.6.1 says that "While D_TRANS is I, the decompressor sends a
NACK or ACK carrying a CRC option for each received packet".  Does this
include packets that do not normally update the decompressor context (i.e.
R0 and R-1-*)?  Also, NACKs are normally sent only when K1 out of the last
N1 packets received failed the CRC check - which is then followed by a state
transition to SC.  What happens to the K1/N1 mechanism during mode
transition?  Is it that all CRC errors generate a NACK, but a state change
only occurs after K1 out of the last N1 packets failed the CRC check?

2) Section 5.6.2 (transition from U to O) says: "Any feedback packet
carrying a CRC can be used with the mode set to O".  I understand that this
means ACK(O), NACK(O) and STATIC-NACK(O).  Is this correct?

3) Sections 5.6.3 and 5.6.4 (any to R) mention that ACK(R) or NACK(R) can be
used to initiate the transition.  I understand that we can't use
STATIC-NACK(R), which is consistent with the fact that the decompressor
needs to have the static context established prior to initiating the
transition.  The same rule seems to apply in section 5.6.5 for transitions
from R to O.  Is this correct?  

4) I realize that state and mode transitions are independent from one
another.  However, in the mechanisms described in 5.6.3-4, what happens if
the decompressor that initiated a mode transition has to send a STATIC-NACK
to the compressor due to repeated CRC errors?  (i.e. when D_TRANS=I what
mode should be specified in STATIC-NACK, the current mode or the destination
mode?)  Can the mode transition procedure continue after the decompressor
reached the NC state?  If not, what would be the proper way to recover?

Thanks in advance,
Rémi

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

---

From: "Ashok Kumar" <[email-masked]>
Date: Wed, 25 Sep 2002 11:43:43 +0530

Hi Remi,

Please see my comments inline. Hope that will be helpful.

R0 or R-1-* do not carry a CRC and the header without CRC are never Acked (or Nacked). How you deal with K1/N1 at mode transition may be an implementation issue. I feel that it is better to treat K1/N1 mechanism independent of mode transition. A CRC error that will cause a downword state transition will trigger a NACK/S-NACK.

Yes, you can use any feedback packet with CRC. Infact even if compressor, when working in U Mode, receives a feedback packet without CRC, it will transit to O-Mode.

I feel when you want to initiate mode transition can be an implementation issue. But I dont see any problem in initiating a mode transition with STATIC-NACK.

Once decompressor has initiated a mode transition, it will have to use new mode (to which transition has been initiated) in feedback packets.

Regards,
Ashok

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 09:44:39 +0200

Remi & Ashok,
 
>> 2) Section 5.6.2 (transition from U to O) says: "Any feedback
>> packet carrying a CRC can be used with the mode set to O".  I
>> understand that this means ACK(O), NACK(O) and STATIC-NACK(O).
>>  Is this correct?
> 
> Yes, you can use any feedback packet with CRC. Infact even if 
> compressor, when working in U Mode, receives a feedback 
> packet without CRC, it will transit to O-Mode.

This is not completely correct. According to section 5.6.2, a CRC
must be present and successfully verified before the compressor
is allowed to transit. Further, it will not transit to O-mode
if the mode flag in feedback is not set to O. Feedback does not
implicitly mean transition to bi-directional operation in ROHC RTP
(which it will do in e.g. ROHC TCP). It is dangerous if a compressor
mistakenly transits to a bi-directional mode.

>> 3) Sections 5.6.3 and 5.6.4 (any to R) mention that ACK(R) or 
>> NACK(R) can be used to initiate the transition.  I understand
>> that we can't use STATIC-NACK(R), which is consistent with the
>> fact that the decompressor needs to have the static context 
>> established prior to initiating the transition.  The same rule
>> seems to apply in section 5.6.5 for transitions from R to O.
>> Is this correct? 
> 
> I feel when you want to initiate mode transition can be an 
> implementation issue. But I dont see any problem in initiating
> a mode transition with STATIC-NACK.

The Implementer's guide, <draft-ietf-rohc-rtp-impl-guide-01.txt>,
has some discussions related to mode transitions that might be
worth reading. Please see section 4.12 and chapter 3.

>> 4) I realize that state and mode transitions are independent
>> from one another.  However, in the mechanisms described in
>> 5.6.3-4, what happens if the decompressor that initiated a
>> mode transition has to send a STATIC-NACK to the compressor
>> due to repeated CRC errors?  (i.e. when D_TRANS=I what mode
>> should be specified in STATIC-NACK, the current mode or the
>> destination mode?) Can the mode transition procedure continue
>> after the decompressor reached the NC state?  If not, what
>> would be the proper way to recover?
> 
> Once decompressor has initiated a mode transition, it will 
> have to use new mode (to which transition has been initiated) 
> in feedback packets.

Right, the decompressor will just continue to indicate the
destination mode in all feedback packets.

BR
/L-E

---

From: "Ashok Kumar" <[email-masked]>
Date: Wed, 25 Sep 2002 14:21:50 +0530

Hi Lars-Erik,

Section 5.6.2 states
" If the feedback packet is lost, the compressor will continue to work in Unidirectional mode, but as soon as any feedback packet reaches the compressor it will transit to Optimistic mode."
Here how should "any feedback packet" be interpreted? I agree that in case compressor recieves a feedback packet with CRC with Mode parameter set to R-Mode should be ignored by compressor.

But What should be done in case compressor receives a FEEDBACK-1 type packet? It does not have mode information.
Also decompressor when operating in U-Mode may send only ACK(U) feedbacks (RFC 3095, sect 5.3.1.3)
So if compressor is operating in U-Mode and it recieves a FEEDBACK-1, is not it safe to assume that decompressor has transited to some other mode? Since Transition from O to R is through Handshake mechanism  only other option is that decompressor have transited to O-Mode and feedback packet which indicated that mode transition might have lost.

Btw as far as interpreting the packet data is concerned, since U and O modes have same packet type it may be possible to interoperate between U and O Mode.

Regards,
Ashok

-----Original Message-----
From: Lars-Erik Jonsson (EAB) [mailto:[email-masked]]
Sent: Wednesday, September 25, 2002 1:15 PM
To: Ashok Kumar; Remi Pelland; [email-masked]
Subject: RE: [rohc] ROHC Mode transitions questions

Remi & Ashok,

BR
/L-E

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 11:57:41 +0200

Ashok,

> Section 5.6.2 states
> " If the feedback packet is lost, the compressor will 
> continue to work in Unidirectional mode, but as soon as any 
> feedback packet reaches the compressor it will transit to 
> Optimistic mode."
> Here how should "any feedback packet" be interpreted? 

It should be interpreted as a feedback packet continuing to
request a mode transfer (Mode-bit=O, CRC option). When the
above text was written, the CRC option requirement and the
feedback packet design were not settled, and that made the
wording unclear.

> So if compressor is operating in U-Mode and it receives a 
> FEEDBACK-1, is not it safe to assume that decompressor has 
> transited to some other mode? Since Transition from O to R is 
> through Handshake mechanism  only other option is that 
> decompressor have transited to O-Mode and feedback packet 
> which indicated that mode transition might have lost.

All transitions except U->O are through handshakes. U->O 
transitions are completely safe as long as the compressor do
not transit to O-mode by mistake, i.e. stop sending periodic
updates. It might be worth clarifying that a decompressor should
try to make sure the compressor has really completed transition 
to O-mode, by repeating feedback with the O-mode parameter set
and the CRC option included. "Useless" periodic updates from the
compressor can be observed by the decompressor, and used for the
purpose of detecting transition failure.

> Btw as far as interpreting the packet data is concerned, 
> since U and O modes have same packet type it may be possible 
> to interoperate between U and O Mode.

As pointed out above, this works fine as long as the compressor
do not transit to O mode by mistake. If it do, it will assume
negative feedback from a decompressor that is not necessarily
sending negative feedback upon error. That might cause 
never-ending loss propagation (no periodic refreshes and no
negative acknowledgements to trigger repair).

Cheers,
/L-E