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

From: [email-masked]
Date: Wed, 18 Jun 2003 12:52:13 -0500

Hi Gyslain,

In summary, your comments are related to the modifications I proposed for the ROHC-CR feedback. I understand that you are not favoring the proposed modifications, but I do not understand the justification for it. 

The proposed modifications doesn't add any bits in the IR-REPLICATE packet, it only changes the 8-bit CRC coverage. It provides mechanism for detecting bad base context, only for the initial IR-REPLICATE packets and not after successful validation of the context (please see my 2nd last embedded comment below). If we don't incorporate the proposed modifications, in case of a bad context:

1) the compressor would continue to send N IR-REPLICATE packets and eventually send IR packet. There will be N-1 unnecessary transmission of IR-REPLICATE packets.

2) when a base context gets corrupted, it may continue to be used for the other context replications, and each of those would fail N IR-REPLICATE packets. There will be (num of bad base contexts)* (N-1) unnecessary transmission of IR-REPLICATE packets

Thus, with proposed modifications we add robustness and compression efficiency. Could you tell me why you think the proposed modifications for feedback is unnecessary?

Also, please find my specific comments below. 

Regards,
Yousuf

> [email-masked] wrote:
> 
> > > [Yousuf] I think it is possible to use STATIC-NACK for 
> > > indicating corruption in the base context, and another NACK 
> > > for indicating transmission error in IR-REPLICATE packet. We 
> 
> In my understanding, ACKs and NACKs are used to transmit information
> regarding the state of the context (potentially at a specific 
> packet in
> the SN space), not to provide information regarding the state of the
> transmission. Therefore I do not really understand why there 
> would be a
> need to define a new feedback option to indicate transmission error in
> the IR-REPLICATE packet.
>
The need is to identify why the state of the context can't be changed? If the state of the context can't be changed because the base context is bad, the compressor could stop using the bad base context and start sending the IR packet. This helps in adding robustness and compression efficiency on the CR procedure, please also see my earlier comment. 
  
> > > have two CRCs. 7-bit CRC covers the original uncompressed 
> > > header and the 8-bit CRC covers the IR packet including 
> > > static and dynamic chain (this is with the change proposed in 
> > > my last email). If 8-bit CRC verifies integrity of IR-
> 
> The extent of the coverage of the 8-bit CRC (other than the minimal
> coverage required by RFC-3095) is profile dependent. It would be
> unappropriate to define it as to include chains in this 
> draft, unless we
> make context replication profile-specific. This is also in 
> line with one
> of Richard's previous comment on this thread. 
> 
The mechanism I am suggesting for these two CRCs to provide, i.e. detection of error in the base context, is generic and applicable to all the profiles. Even though, 8-bit CRC is defined as a profile dependent parameter, this mechanism is general and is appropriate to capture it in the CR draft. Moreover, the CR draft does mention coverage of CRC, the following is a quote from 8-bit CRC section:
"MUST cover at least the initial part of the packet ending with the Profile field and if present, the Base CID field"
This would be changed to:
"MUST cover the IR packet excluding payload"

If we can put the former text in the draft, then we can also put the later text in the draft. 

There are also other examples in the CR draft where those profile-specific information which are generic to multiple profiles are mentioned, e.g. use of a different CID than the Base CID, and mentioning of 7-bit CRC under Profile Specific Information. I am not asking to take this out. I think it is good to put these text, so the CR draft would serve as a better base document for the profile dependent documents.

> > > REPLICATE packet header, but the 7-bit CRC failed after 
> > > decompression, then this implies that we have a problem in 
> > > the base context. In this case only the decompressor will 
> > > send a STATIC-NACK indicating that the decompression failed 
> > > due to the problem in the base context. The compressor would 
> > > discard that base context and send IR packet.
> 
> Only for the "one or more initial IR-REPLICATE packets", as currently
> stated in the draft.
> 
> "Price, Richard" wrote:
> 
> > Page 6: "Upon reception of a NACK, the compressor may assume
> > that the static part of the decompressor context is valid but
> > that the dynamic part is invalid, and take actions accordingly."
> > 
> > Again, could this also be used by the compressor as evidence
> > that something is wrong with the base context?
> 
> Not in this case. See previous comment.
> 
> [email-masked] wrote:
> 
> > > [Yousuf] Can we solve this concern by adding IR-REPLICATE 
> > > state between IR and CO state in the compressor state machine 
> > > as shown below.
> > >
> > >        Optimistic approach / ACK                 ACK
> > >      +------>-------->------>------>---------+  +->-+
> > >      |  Base Ctxt Avail          ACK         |  |   |
> > >      | +----------+     +---->---->---------||  |   |
> > >      | |          V     |                   vv  |   v
> > >  +----------+    +--------------+         +----------+
> > >  | IR State |    | IR-REP State |         | CO State |
> > >  +----------+    +--------------+         +----------+
> > >      ^  ^         |    ^   |                  |
> > >      |  +---<-----+    +-<-+                  |
> > >      |    STATIC-NACK  Timeout/NACK           |
> > >      |                                        |
> > >      |  Timeout / NACK / STATIC-NACK          |
> > >      +-------<-------<-------<-------<--------+
> > > 
> > > I think this is also what context context replication is 
> > > doing.
> 
> Replication is a complement to the context initialization. I do not
> really see the relevance of adding a new state for context 
> replication.
>
This is in response to the Richard's comment you quoted below. His concern regarding not sending STATIC-NACK in IR state for R-mode is solved by the above diagram. Please also see my next comment. 
 
> "Price, Richard" wrote:
>  
> > Page 7: "Specifically, when the decompressor fails to validate
> > the context following the decompression of one or more initial
> > IR-REPLICATE packets, it MUST invalidate the context and remain
> > in its initial state. In addition, the decompressor SHOULD send
> > a STATIC-NACK."
> > 
> > This logic is fine for O-mode and B-mode, but I think that
> > different logic is required in the case of R-mode. From RFC 3095:
> > 
> >     "The decompressor SHOULD NOT send STATIC-NACK(R) when
> >      receiving an IR packet that fails the CRC check, as the
> >      compressor will stay in IR state and thus continue sending
> >      IR packets until a valid ACK is received"
> > 
> > The above also applies to an IR-REPLICATE packet, so the
> > decompressor SHOULD NOT send a STATIC-NACK in this case.
> 
> In my understanding, if the CRC fails for the IR we cannot deduce
> anything as to the validity of the context, as the 8-bit CRC is
> calculated over information contained in the packet only. Thus in my
> understanding the text in the draft still means that in this case the
> decompressor would not send STATIC-NACK anyway, so in my understanding
> this would not conflict with respect to R-mode. Furthermore, modes are
> actually profile dependent, not generic to all profiles, so this draft
> should not go in more details regarding this in my opinion.
>
The decompressor can deduce the validity of the context using two CRCs in the IR-REPLICATE packet. If the context is bad, it can send STATIC-NACK right away as mentioned earlier. This is different from the text in the draft but improves the overall procedure. 

Regarding documenting R-mode specific text in CR draft. If something is anticipated to be generic for R-modes and also for multiple profiles, then instead of repeating the common text in the multiple profile specific drafts it would be better to document the common text in the CR draft. The text from the draft implies U and B mode, that's where the confusion has arised. If we try to abstract the text too much we would loose information and cause confusion, therefore it is better to expand and put the R-mode also. 

> [email-masked] wrote:
> 
> > - I think we can improve on failure mechanism mentioned in the
> > above two sections. The draft mentions that if the 
> > decompression of IR-REPLICATE fails, the decompressor will send 
> > STATIC NACK and the compressor MUST refrain from IR-REPLICATE, 
> > in other words use IR packets. Moving to IR means sending more 
> 
> 
> > bytes compared to IR-REPLICATE, hence degrading compression 
> > efficiency. If the decompression has failed due to transmission 
> > error of IR-REPLICATE (case-1), then the decompressor is 
> > unnecessarily asking for IR. It is better to ask for the 
> > retransmission of IR-REPLICATE and gain more compression 
> > efficiency. Not to mention, retransmitting an already encoded 
> > packet would be faster for the compressor. It is also possible 
> > that the decompression has failed because of the corruption in 
> > the base context (case-2). In case-2 we definitely want to move 
> > to the IR packet, since there is no way to fix it without 
> > sending full header.
> 
> Case-1 would normally not trigger feedback. Case-2 would normally
> trigger a NACK. An additional case is when N IR-REPLICATE received
> (where k out of N succeed 8-bit CRC validation) would not succeed into
> replicating a context (7-bit CRC fails for k); this would trigger
> STATIC-NACK.
> 
Your comment is only based on the CR daft. My above comment has suggested an improvement and that improvement sends feedback in case-1. Could you please comment on the proposed improvement.
 
> > I'd propose that the decompressor should differentiate between 
> > the two cases. It can be done if we increase the coverage of 8-
> > bit CRC (section 3.4.1.2)to cover static and dynamic chain 
> > also. The CRC of an IR or IR-DYN covers the whole IR packet, 
> > excluding payload (section 5.9.2 of RFC 3095). The proposed 
> > change in 8-bit CRC is more in line with the IR and IR-DYN CRC.
> 
> This would correspond to a requirement on something that is actually
> profile specific. The draft only put requirements on the 
> minimal extent
> of the coverage for the 8-bit CRC.

Please see my an earlier comment on profile specifics.

> 
> > The logic would work something like this:
> > - if 7-bit CRC failed, send STATIC-NACK
> 
> This would prevent the IR-REPLICATE to be used like any other 
> compressed
> packet. A failure to decompress one such packet does not necessarily
> means that the static part in invalid.
> 
I think I see your concern, we need to handle two cases as mentioned in section 3.3.2 of the CR draft:

Case-1: 2nd para -Upon failures of one ore more initial IR-REPLICATE, the CR draft also sends STATIC-NACK  which in turn triggers IR. It doesn't provides a mechanism for validating and using the static part, so the proposed modification doesn't have any issue with this.

Case -2: 3rd para - After successful validation of the replicated context, there is no need for sending STATIC-NACK, and a NACK as suggested in the CR draft can be used. In this way static part can be used, if desired. This has no issue with the proposed modification, as the base context has been successfully validated and the proposed modification won't be sending STATIC-NACK.
 
> > - if 8-bit CRC fails, send another NACK (let's call it REP-
> >   NACK).
> 
> The 8-bit CRC protects the integrity of the IR packet itself. while
> feedback is used to convey information regarding the state of the
> context. In my opinion, it would be not be proper to define a new
> feedback type to report a transmission error instead of 
> considering the
> state of the context.
> 

I think that is an incorrect description of the purpose of the new feedback type. The feedback is not reporting a transmission error. It is reporting why the state of the context can't be changed. The information is used for increasing robustness and improving compression efficiency, as mentioned earlier in this email. 

> > We could differentiate a REP-NACK from a regular NACK by using 
> > feedback options in the FEEDBACK-2 format and make this option 
> > available to other profiles besides TCP. We could have used 
> 
> In my opinion, this is not necessary. Also, I would be reluctant to
> define a new feedback option if I can avoid it.
> 
> 

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

---

From: Ghyslain Pelletier <[email-masked]>
Date: Thu, 19 Jun 2003 13:05:08 +0200

Yousouf,

I appreciate your comments. Those suggestions that I do not favor are
because I do not see (or understand) their motivations. Obviously in
such case it would be useful if someone else on the list joins in to
help us out.

See further comments inline.

/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

[email-masked] wrote:
> 
> Hi Ghyslain,
> 
> In summary, your comments are related to the modifications I 
> proposed for the ROHC-CR feedback. I understand that you are not
> favoring the proposed modifications, but I do not understand the
> justification for it.
>
> The proposed modifications doesn't add any bits in the IR-REPLICATE
> packet, it only changes the 8-bit CRC coverage.

The draft is currently written to be generic and reused by any profiles.
Because the IR-REPLICATE is a ROHC IR packet, the minimal coverage of
this CRC must follow RFC-3095. RFC-3095 also states that this coverage
may be extended to cover more (such as including any information that
initializes the context), but that this should be defined on a
per-profile basis. I cannot think of any specific reason why this was
specified like this, however I have chosen to do the same when writing
ROHC-CR. So, trying to clarify your comments and if I understand
correctly, your question regarding the CRC-8 is thus:

Q1) should we mandate that every profile supporting ROHC-CR calculates
  the CRC-8 over the entire IR-REPLICATE packet, excluding the
  payload?

Regarding this, I still favor that each profile specify this itself.
However, I have no strong feelings about this, as ultimately I suspect
that any profile would do just that.

The coverage of the 8-bit CRC in the IR-REPLICATE 

> It provides
> mechanism for detecting bad base context, only for the initial
> IR-REPLICATE packets and not after successful validation of the
> context (please see my 2nd last embedded comment below).

This is were I fail to follow you. In my understanding, the 8-bit CRC -
calculated over information contained in the IR packet - is not what
provides the "mechanism for detecting a bad base context". This CRC will
only allow you to detect that there has been an error in the received
packet (transmission error), and since the information covered by this
CRC includes CID it is difficult to take proper action more than to
discard the packet.

> If we don't
> incorporate the proposed modifications, in case of a bad context:
> 
> 1) the compressor would continue to send N IR-REPLICATE packets and
> eventually send IR packet. There will be N-1 unnecessary
> transmission of IR-REPLICATE packets.
> 

When the CRC-8 of the IR-REPLICATE fails to verify, the decompressor
does not take any different actions than those stated in RFC-3095,
section 5.2.6 (see item #10). Maybe this needs to be clarified? I could
add a section "initial decompressor processing", that would add a
paragraph identical to item #10?

The CRC that is used for detecting a faulty context is the 7-bit CRC for
which ROHC-CR states that its presence is mandatory within the "profile
specific information" of the IR-REPLICATE packet. The CRC-7 is
calculated over the original, uncompressed header and thus verifies
decompressor (validity of the context).

In summary, the CRC-8 is present to make sure that an IR-REPLICATE
initializing a new context using replication has had its CID and profile
validated, and that the information that initializes the context was
received without error. Since with replication some of this information
is sent compressed already within the first IR-REPLICATE, the CRC-7 is
necessary to verify the decompression - thus in turn to verifying that
replication was successful (i.e. the base context used was ok!). See
ROHC-CR section 3.1.

Now, when the CRC-7 in the IR-REPLICATE fails to verify the decompressed
header, this is when the decompressor might generate feedback. Section
3.3.2 states that:

1) ACK should be sent when one or more IR-REPLICATE succeeds CRC-7
   validation, i.e. decompression succeeded -> context is ok.

2) NACK should be sent when one or more IR-REPLICATE fails CRC-7
   validation in the following case:
   o a context had been successfully established prior to the packet(s)
     for which decompression failed
   I.e. case A:
   A valid context had been successfully established for that
   flow, but decompression failed for one or more packets -> context
   went from ok to not ok and is now a "bad context".

3) STATIC-NACK should be sent when one or more IR-REPLICATE fails
   CRC-7 validation in the following case:
   o no context has yet been established for this flow prior to the
     packet(s) for which decompression failed.
   I.e. case B:
   No valid context has been established for that flow, and
   decompression fails for one or more packets -> context never
   established and is not suited to be a base context
   (is a "bad context" for replication).

Thus, case A is not triggering the sending of IRs, case B does.

> 2) when a base context gets corrupted, it may continue to be used
> for the other context replications, and each of those would fail N
> IR-REPLICATE packets. There will be (num of bad base contexts)*
> (N-1) unnecessary transmission of IR-REPLICATE packets

Here I fail to understand how this could be. A base context that gets
corrupted will not be used for replicating other context, as it would
have been NACKed and thus fails the requirements for the selection of a
base context (i.e. must have been ACKed and valid at the compressor at
the time of replication).

> Thus, with proposed modifications we add robustness and compression
> efficiency. Could you tell me why you think the proposed
> modifications for feedback is unnecessary?
> 
> The need is to identify why the state of the context can't be
> changed? If the state of the context can't be changed because the
> base context is bad, the compressor could stop using the bad base
> context and start sending the IR packet. This helps in adding
> robustness and compression efficiency on the CR procedure, please
> also see my earlier comment.

What do you mean "why the state of the context can't be changed"? Do you
mean that it failed to validate the decompression (CRC-7) and thus the
packet can't update the context?

Your original request is to add "another NACK for indicating
transmission error in IR-REPLICATE packet". This is what I fail to see a
justification for. As I previously explained, my understanding is that
feedback with ROHC is meant to carry information regarding the state of
the decompressor context back to the compressor, not to carry
information about transmission errors. Identifying why a context becomes
invalid and which of STATIC-NACK or NACK should be sent is explained
above. Recall that both FEEDBACK-1 and FEEDBACK-2 carries SN bits that
corresponds to the sequence number of the header (e.g. IR-REPLICATE)
that caused the feedback information to be sent. If no sequence number
can be determined, then the feedback carries the SN-NOT-VALID option.
This is useful for the compressor to determine the cause of the problem.
 
> The mechanism I am suggesting for these two CRCs to provide, i.e.
> detection of error in the base context, is generic and applicable to
> all the profiles. Even though, 8-bit CRC is defined as a profile
> dependent parameter, this mechanism is general and is appropriate to
> capture it in the CR draft. Moreover, the CR draft does mention
> coverage of CRC, the following is a quote from 8-bit CRC section:

Up to here, I do not understand what it is that you are proposing
regarding the CRCs that is not already addressed in the ROHC-CR draft.

> "MUST cover at least the initial part of the packet ending with the
> Profile field and if present, the Base CID field"

See Q1) above. This is exactly the same question.
 
> There are also other examples in the CR draft where those
> profile-specific information which are generic to multiple profiles
> are mentioned, e.g. use of a different CID than the Base CID, and
> mentioning of 7-bit CRC under Profile Specific Information. I am not
> asking to take this out. I think it is good to put these text, so the
> CR draft would serve as a better base document for the profile
> dependent documents.

I don't think there is a contradiction here either.
 
> > really see the relevance of adding a new state for context

Your original question was:

Q2) Should we add an additional state called IR-REP?

I fail to understand how in general this new state would be motivated. I
don't see that this is needed. For me, the IR-REPLICATE corresponds to
the IR state just like the IR does.

Furthermore, states a profile specific and the ROHC-CR is not. Your
drawing seems to have the state machine of ROHC-TCP in mind. 

> This is in response to the Richard's comment you quoted below. His
> concern regarding not sending STATIC-NACK in IR state for R-mode is
> solved by the above diagram. Please also see my next comment.

This is a different issue and I fail to see its relation with adding yet
another state. The question is:

Q3) Can the mode be replicated?

First, note that modes are profile specific. My opinion is that if the
ROHC-CR draft is to stay generic, than there shouldn't be anything
specific to R-mode in it.

Second, my opinion is that the mode can't be replicated. It is nothing
that is necessary to replicate. Inaddition, this also would cause
problems with inter-profile replication. A replicated context should
start in its initial mode after replication, and the initial feedback to
the IR-REPLICATE may be used to make a mode change (FEEDBACK-2 only in
this case when ACKing) , if applicable. Wouldn't this be the simplest
thing to do? I think replicating the mode does not make sense.

> The decompressor can deduce the validity of the context using two
> CRCs in the IR-REPLICATE packet. If the context is bad, it can send
> STATIC-NACK right away as mentioned earlier. This is different from
> the text in the draft but improves the overall procedure.

I don't see that the consequence of the text in the draft is any
different from this result, and thus I can't see the improvement from
the text in the draft either. Refer to the above explanation of the text
in the draft. If you still feel that there is improvement, please be
more specific in your comment.
 
> Regarding documenting R-mode specific text in CR draft. If something
> is anticipated to be generic for R-modes and also for multiple
> profiles, then instead of repeating the common text in the multiple
> profile specific drafts it would be better to document the common
> text in the CR draft. The text from the draft implies U and B mode,
> that's where the confusion has arised. If we try to abstract the text
> too much we would loose information and cause confusion, therefore it
> is better to expand and put the R-mode also.

I strongly disagree. R-mode is not a part of the generic ROHC framework,
it is rather specific to certain profiles only. This is not something
that all ROHC profiles needs to have or support. Note that R-mode also
has its own set of packet format and modes are useful to ensure that
packet type identifiers common to U/O-mode and R-mode will not be
misinterpreted, in addition to having a different feedback logic.

However for ROHC-TCP in particular, and possibly future compression
profiles, we should hopefully limit ourselves to one set of packet
formats for the lifetime of a context. This is the path taken with
ROHC-TCP, and I believe this is also in-line with the use of the formal
notation as a tool to help us generate packet formats.

Thus, and I hope others will agree with me, let's not discuss R-mode and
context replication further at this point we should not write any text
specific to R-mode in the ROHC-CR draft. I believe that the more generic
approach is to focus on a U and B mode type of operation.
 
> Your comment is only based on the CR daft. My above comment has
> suggested an improvement and that improvement sends feedback in
> case-1. Could you please comment on the proposed improvement.

My comments address the ROHC-CR draft only. Also see explanations above
regarding feedack.
 
> Please see my an earlier comment on profile specifics.

Your proposed change is in-line with the profile-specific part of the
CRC in IR and IR-DYN. The text in the ROHC-CR draft is aligned with the
profile independant part of the CRC in IR and IR-DYN (see RFC-3095
section 5.2.3.). See Q1) above.

> Case-1: 2nd para -Upon failures of one ore more initial IR-REPLICATE,
> the CR draft also sends STATIC-NACK  which in turn triggers IR. It
> doesn't provides a mechanism for validating and using the static
> part, so the proposed modification doesn't have any issue with this.

This case is only about the decompressor sending STATIC-NACK when it
could not establish a context following a number (one or more) of
_initial_ IR-REPLICATE packets - because of a faulty base context (i.e.
the static part is not known to be usable). Thus as a result it is
accurate for the compressor to start sending IRs instead.
 
> Case -2: 3rd para - After successful validation of the replicated
> context, there is no need for sending STATIC-NACK, and a NACK as
> suggested in the CR draft can be used. In this way static part can be
> used, if desired. This has no issue with the proposed modification,
> as the base context has been successfully validated and the proposed
> modification won't be sending STATIC-NACK.

In this case the draft states is also correct, right?
 
> I think that is an incorrect description of the purpose of the new
> feedback type. The feedback is not reporting a transmission error. It
> is reporting why the state of the context can't be changed. The
> information is used for increasing robustness and improving
> compression efficiency, as mentioned earlier in this email.

If I rephrase your comment, you mean that the new feedback type would
convey information regarding why the context could not be updated,
correct? A context is updated when decompression succeeds (i.e. when the
CRC validates the decompressed header - in this case when the CRC-7 of
the IR-REPLICATE succeeds). When the CRC-8 of the IR-REPLICATE fails, it
does not provide the decompressor with any other information that there
has been a transmission error. Specifically, decompression is not even
attempted, and the error might even be on the CID field, base CID field
or profile field of the IR-REPLICATE - thus in this case what this
option would transmit cannot relate to the state of the context (neither
to the state of the base context). And I don't believe that a new
feedback option that carries information that does not relate to the
state of the context is justified.

If I misunderstand your comment, please clarify it. Thanks!