Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed)

From: "Price, Richard" <[email-masked]>
Date: Mon, 23 Jun 2003 11:03:51 +0100

> The main thing we need to agree on is the definition of 8-bit 
> CRC. It should cover static/dynamic chain in the IR REPLICATE 
> packet for finding out bad base context problem. With the 
> 8-bit CRC definition as in the CR draft (excluding 
> static/dynamic chains in IR-REPLICATE), point i) above will 
> be sending STATIC-NACK even if the problem is in the received 
> static/dynamic chains. 

Hi Yousuf,

In the current ROHC-CR draft, the coverage of the 8-bit CRC is
left as a choice for the individual profiles. Depending on the
particular profile, the 8-bit CRC may or may not cover the
static/dynamic chains in the IR-REPLICATE packet.

However, I agree that if the CRC-8 *doesn't* cover the static/
dynamic chains, then there may be a potential conflict with the
logic used at the decompressor. If the CRC-8 succeeds but the
CRC-7 fails then the decompressor assumes that the problem lies
in the context rather than in the IR-REPLICATE packet, and sends
a STATIC-NACK to indicate that the context is bad. So the
decompressor logic only works properly if the CRC-8 checks all
of the fields in the IR-REPLICATE packet.

I think that the best way to resolve this potential problem is
just to specify that the 8-bit CRC must cover the entire
IR-REPLICATE packet (except for the payload).

Regards,

Richard

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Mon, 23 Jun 2003 15:42:10 +0200

Richard and Yousuf,

Thanks for your review and comments. I think it's best at this time to
extract some points of that discussion rather than commenting on
specifics. I'd thus like to summarize my understanding of the result of
that thread regarding ROHC-CR:

o ROHC-CR is a generic ROHC mechanism:
  CR is profile independent, it is not specific to ROHC-TCP but the
  draft will make assumptions coherent with the ROHC-TCP profile -
  while ensuring that as little work as possible would be necessary
  for other profiles to implement CR.

o Profile-specific part of ROHC-CR:
  Profile-specific part of ROHC-CR will be specified in the document
  where support for ROHC-CR is added, such as in a draft describing
  a new ROHC profile (e.g. the ROHC-TCP draft) and potentially
  updated revisions of existing profiles. Hopefully, this will be
  as little work as possible.

o ROHC-CR and modes:
  ROHC-CR should not attempt to be applicable to arbitrary modes,
  and we should not spend significant effort on covering the various
  behaviors for all possible modes. The draft will instead assume a
  U/B-mode type of operation. This is how the draft is currently
  written, but the approach will be further clarified in the next
  version. This is motivated by the ROHC-TCP profile being the
  main motivation behind ROHC-CR.

o 8-bit CRC in IR-REPLICATE:
  The coverage will be made profile-independent. The CRC will cover
  the entire IR-REPLICATE packet, except the payload. This will be
  changed in the next version. 

o Actions upon CRC-8 failure
  The draft currently relies on text in rfc-3095 for this. It has
  been suggested that this may create some unclarity. This will be
  adjusted in the next version with text similar to rfc-3095
  section 5.2.6 (item #10).

o New state for IR-REPLICATE

  Richard summarized this potential new state as follow:

  "I think that IR-REP state would be at the compressor, so the
  logic would dictate what to do when receiving a STATIC-NACK
  (namely transit to IR state), and conversely how to transit from
  IR state to IR-REP state (find a base context that has been
  successfully ACKed)."

  The first part of the above sentence basically corresponds to
  section 3.2.2.1/3.2.2.2 and the second part corresponds to section
  3.2.1 of the ROHC-CR draft.

  I find motivations to add an additional state for CR somewhat thin,
  also in relation to the limited amount of logic attached to it and
  because ROHC-CR does not define a complete state machine. This issue
  in my opinion is only a matter of how to document logic to support
  the IR-REPLICATE, it is not about the logic itself (for which we
  seem to have agreement). I'd prefer instead that we make an attempt
  in ensuring that the text for both the compressor and decompressor
  logic is clear when using the IR-REPLICATE. It seems that the part
  related to the compressor logic is the bit that could be better.
  
  This should be clearer in the next version. If this is not possible,
  then we might want to consider document this logic using a more
  pedagogical representation, like adding such a new state. But right
  now I don't see any compelling need/reason for this. Hopefully we
  can agree on this for now. 

o Feedback with ROHC-CR:
  It seems that current feedback options from rfc-3095 are sufficient
  for ROHC-CR and with respect to the U/B-mode assumption. No new
  options are needed with this assumption.

Let me know if I have missed something. Thanks again.

/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