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

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 17 Jun 2003 17:15:04 +0200

Richard, Yousouf,

I have combined your questions regarding feedback with ROHC-CR in a
single mail. Look for my comments in-line. Hopefully it helps
clarifiying this part of the ROHC-CR draft.

"Price, Richard" wrote:

> Page 6: "otherwise the base context is overwritten with the new
> context by the replication process."
> 
> If we set the base context equal to the current context, is it
> still the case that we need to acknowledge the base context using
> a feedback packet?

Not unless the overwritten context is to be used later as the base
context for another replication. Since in the feedback section it is
said the the decompressor should ACK a successful decompression of one
or more IR-REPLICATE (including the initial sequence of IR-REPLICATE
that initially overwrite the base context), then it should anyway have
been acknowledged at one point and be possible to reuse later. 

> It might be useful to offer the IR-REPLICATE
> packet as an ordinary packet format, which can be used to send
> compressed headers even in the unidirectional case.

I see this as a different issue than the previous comment. I think that
at least the *initial sequence* (i.e. "one or more initial" in the
draft) of IR-REPLICATE used to replicate a base context to initialize
the context for a new flow should be acknowledged in some way. Once this
is done, I don't think (I belive this is in-line with the current text)
that it prevents the decompressor to request to the compressor to
continue in unidirectional operation even considering the initial ACK,
and that the IR-REPLICATE may still be used after that without the
*need* to acknowledge it when it is received (currently a "SHOULD" in
the draft).

So, unless I am mistaking, the draft currently allows what your comment
mentions.
 
> Page 6: "Upon reception of a STATIC-NACK, the compressor MUST
> transit back to its initial no context state and SHOULD refrain
> from sending IR-REPLICATE packets using the same base context."
> 
> How does the above interact with the robustness mechanisms of the
> base context itself? For example, if the compressor continues to
> use the base context and continues to receive positive ACKs in
> the normal manner, is it ok to assume that the base context is
> actually valid (and hence that the IR-REPLICATE packet itself is
> where the error occurred)?

Yes, it is ok. This is tied to the decompressor logic when using the
STATIC-NACK. In the case of the IR-REPLICATE, the text in the draft
means that STATIC-NACK would not be sent because of a CRC-8 failure
(which verifies the integrity of the IR-REPLICATE packet itself), but
because a number of consecutive decompression failures (CRC-7, used to
validate the context) for IR-REPLICATE packets would have occurred.

> Conversely, would it be possible for the compressor to take a
> STATIC-NACK for the newly replicated context as evidence that
> something is wrong with the base context? It could use this
> information to influence the state machine of the base context,
> e.g. by causing it to transit to a lower state.

Yes, this is actually what the text in the draft says. I.e., the second
paragraph in section 3.3.2 says that the decompressor invalidates a
context and should send STATIC-NACK when an attempt to replicate the
context fails, while the third paragraph says that if the context has
been replicated successfully but IR-REPLICATE(s) are later received and
failed decompression, then NACK should be sent. 

Or maybe I misunderstood your comment?

[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.

> > 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. 

> > 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.

"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.
 
> Page 7: "The decompressor SHOULD send an ACK when it succeeds to
> validate the context as a result of the decompression of one or
> more IR-REPLICATE packets."
> 
> For R-mode, the above logic needs to be much more precisely
> defined (taking into account the "Sparse ACK" mechanism).

This is a profile-specific consideration, which I don't think should be
elaborated in this draft if it is to remain generic or alternatively if
it is to be defined for the TCP profile only. I believe a document
defining revisions of profiles implementing context replication is where
this should be precised, if necessary, and this is not the scope of this
document. Furthermore, I consider this particular point as a general
recommendation that in my understanding (R-mode experts - please correct
me if I am wrong) is not in contradiction with the sparse ACK mechanism
- it would fall into the "or more IR-REPLICATE packets" (first 2 or
first N of a sequence, then each k packets). For a profile having
R-mode, it do however agree that it would be useful to add precisions
for the IR-REPLICATE with the Sparse ACK mechanism.
 
[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 

This is actually an incorrect interpretation of the text in the draft.
Maybe I should try to clarify the text. The draft actually states in the
second paragraph in section 3.3.2 says that the decompressor invalidates
a context and should send STATIC-NACK when an attempt to replicate the
context fails (first N of a sequence of IR-REPLICATE for a new flow,
where N is one or more), while the third paragraph says that if the
context has been replicated successfully but IR-REPLICATE(s) are later
received and failed decompression, then NACK should be sent. Thus if the
decompression of IR-REPLICATE fails, the decompressor may a STATIC-NACK
or a NACK depending on the case.

> 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.

> 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.

> 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.

> - 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.

> 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.

> NACK such that a NACK in response to IR-REPLICATE would ask 
> compressor to resend IR-REPLICATE. But it seems like that the 
> draft has a different use of this NACK (section 3.3.2).
> 

Let me know if you still see a potential issues with the above. Thanks!

/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

** My apologies if you have received this email twice **
** I resend it because I have been having problems    **  
** with my mail server all day and some mails have    **
** disapeared - so I don't know if this mail made it  **
** already to the mailing list or not :-(             **
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 19 Jun 2003 19:14:09 +0100

> 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.

I guess this means me ;-)

> See further comments inline.
> 
> /Ghyslain
> 
> > 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.

I don't see any reason *not* to specify the CRC-8 coverage in the context
replication draft, as we're already specifying features that are far more
profile-specific than this (which is by no means a bad thing!).

> 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.

Another possible action upon receiving an IR packet which fails the
8-bit CRC is to send a STATIC-NACK (e.g. O-mode from RFC 3095 does this).
It's not 100% guaranteed that the STATIC-NACK will refer to the correct CID,
but this is no different from the case where a CRC over the decompressed
header fails.

> > 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.

It's not the case that a bad base context will cause N-1 unnecessary
transmissions of an IR-REPLICATE packet. Instead the CRC-7 will fail,
causing the decompressor to send a STATIC-NACK and the compressor to
transit back to sending vanilla IR 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).

There are definitely some cases where the base context can get corrupted
and still be used for replicating other contexts (for example, it might
become corrupted after being ACKed). However, I think that the existing
NACK and STATIC-NACK mechanisms are sufficient to detect these cases
(in particular, the CRC-7 would catch the faulty base context and cause
a NACK or STATIC-NACK to be sent).

> > 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
> > 
> > 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.

I think that the compressor can stop using a bad base context and switch
to IR packets, using the NACK and STATIC-NACK mechanisms that are already
available. If the compressor receives a NACK or STATIC-NACK then it knows
that something is wrong with the context, so it must be refreshed using an
IR(-DYN) packet.

> 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"
> > This would be changed to:
> > "MUST cover the IR packet excluding payload"
> 
> See Q1) above. This is exactly the same question.
>  
> > 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.
> 
> I don't think there is a contradiction here either.
> 
> 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.

In general, the different compressor states are just special cases of a
more general rule - "don't use any information in the decompressor context
until you're confident that it's arrived". The motivation for having
specific states is therefore to document particular instances of this rule:
how to determine the context is valid (optimistic approach, ACKS), how to
determine that it's corrupt (NACKs, timeouts) and so on.

We should therefore add a new state if we've introduced any new compressor
logic that operates differently for "IR-REP" state than for the vanilla
"IR" state. It's not clear to me whether we have done so or not - does the
"selection of a base context" count as defining some state transition logic,
in the sense that it defines when it's ok to move from the "IR" to "IR-REP"
states?

> 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 not necessarily a problem, as we should be focusing on the U/B-mode
state machine used in ROHC-TCP. It would be a mistake to make the draft too
generic, as we would then need to redefine the state transition logic all
over again for each specific profile.

> > 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.

In theory, the "mode" could be replicated like any other field in the
context. In practice, I can't see why this would buy us anything...

> > > this would not conflict with respect to R-mode.

However, if you interpret the context replication draft as meaning "don't
send a STATIC-NACK if the CRC-8 fails", then this is the same logic that is
used in R-mode, but different from the logic used in O-mode. From RFC 3095:

   NC:  - When an IR packet passes the CRC check, send an ACK(O).
        - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR
          packet has failed the CRC check, send a STATIC-NACK(O),
          subject to the considerations at the beginning of section
          5.7.6.

O-mode and R-mode take opposite approaches here, so whichever approach
we select for ROHC-CR, we'll contradict at least one of these modes.

> > > 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.

In cases such as the above, where different modes have different behaviours,
I fully agree that we should not spend significant effort on covering the
various behaviours of all possible modes. We should rather concentrate on
the modes needed for ROHC-TCP, as this is still the main motivation for
context replication.

> > 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 agree with all of the above apart from the very last line. It's certainly
the case that the current context replication draft is written assuming
U-mode and B-mode, which are the modes used in ROHC-TCP. Moreover, it
would be a very bad idea to try and make the draft applicable to arbitrary
modes (even ones that have not yet been designed), as the draft would end
up basically not saying anything at all.

However, this doesn't necessarily imply that we need to expand the draft
to include modes other than U/B-mode. The main motivation for context
replication is still ROHC-TCP, so we should avoid doing extra work to
accommodate modes that aren't used by this profile. If it turns out that
context replication is needed for other modes, we can always add them at
a later stage.

> 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.

The formal notation has nothing to say on the number of format sets used
by a particular profile - you can use it to describe a single set only,
or you can offer more than one set of packet formats. For the specific
case of ROHC-TCP however, we don't currently have a reason to provide
more than one set of 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.

I agree that the draft should focus on U/B-mode at this stage. In fact, I'd
prefer it if we made this explicit  - currently the draft gives the impression
that it defines context replication for arbitrary profiles and modes, whereas
the majority of the normative text is actually specific to U/B-mode (and would
need to be modified or extended to accommodate different modes such as R-mode).

> > 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.

Note however that the CR draft itself shouldn't be generic to all profiles
(otherwise we'd have to cater for modes other than U/B-mode). I think that
the CRC-8 coverage is a state machine issue (which may have some influence
on the compressor and decompressor logic), so it would be ok to define the
coverage in the ROHC-CR draft.

> > 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.
> 
> 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!

I think that Yousuf's suggestion makes theoretical sense if you consider
the REP-NACK to be a particular type of STATIC-NACK (i.e. an option in
the FEEDBACK-2 format). What the REP-NACK essentially does is to say that
the static context is not valid or not established (same as the STATIC-NACK),
but gives a particular reason for why this is the case: namely that there
has been a transmission error. This information may potentially be useful
to the compressor - if it knows that the context is invalid because of
a transmission error rather than an error in the base context, it can take
the appropriate actions (e.g. sending more IR-REPLICATE packets, rather
than giving up and sending a basic IR packet).

In practice however, we need to weigh up the potential benefits of
introducing a new feedback option relative to the extra effort required.
In the case of ROHC-TCP, will transmission errors be sufficiently common
to make this extra feedback option worthwhile?

---

From: [email-masked]
Date: Thu, 19 Jun 2003 17:59:10 -0500

Hi Ghyslain and Richard,
Thanks for the discussion. Please see my comments below. 

The lines prefixed by "> >" are from Ghyslain, and by ">" are from Richard.

Cheers,
Yousuf

> -----Original Message-----
> From: ext Price, Richard [mailto:[email-masked]]
> Sent: Thursday, June 19, 2003 1:14 PM
> To: 'Ghyslain Pelletier'; Saifullah Yousuf (NRC/Dallas)
> Cc: [email-masked]
> Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and
> some topics to be discussed)
> 
> 

I have the same opinion, specify what CRC-8 covers.

> but this is no different from the case where a CRC over the 
I am sorry if I was not clear earlier. Action on 8-bit CRC (coverage complete IR-REPLICATE header) is taken after decompressor fails 7-bit CRC (coverage original header) test. If 7-bit CRC failed but 8-bit CRC passed, the decompressor sends STATIC-NACK. It is sure now that the base context is bad. If 7-bit CRC failed and 8-bit CRC also fails, then send a NACK (R-mode) or ignore it and wait for subsequent IR-RELICATE (U/O-mode). 8-bit CRC by itself is not considered for decision. Please see my next comment also. 

> > Thus, case A is not triggering the sending of IRs, case B does.
I agree with you for items 1) and 2). The case B is the one I want to differ. The decompression failure doesn't always mean "bad context". Let me explain, we have 7-bit CRC that covers original header and 8-bit CRC that covers the IR-REPLICATE packet header excluding payload (this is with the proposed modification). A decompressor receives an initial IR-REPLICATE. It decompresses the packet by using the referred base context and the static/dynamic replication chains provided in the IR-REPLICATE message. After decompression it calculates 7-bit CRC and fails the 7-bit CRC test. There are two sources of error, either the referred base context is bad (case B-1) or the static/dynamic replication chain provided in the IR-REPLICATE is bad (case B-2). Let's say if the static/dynamic chain is bad, then there is no justification for labeling this context as the "bad context". Here the 8-bit CRC comes handy, if it passes CRC check then the decompressor knows that the static/dynamic chains are fine but the context is bad, and sends STATIC NACK. The mechanism I proposed substracts out case B-2 from case B.  

> a NACK or STATIC-NACK to be sent).
CRC-7 by itself can't differentiate whether the error is in the base context or the static/dynamic chains of IR-REPLICATE. It is on the original header and can catch error in the new replicated context, which is formed by the aggregation of the base context and the received static/dynamic chains. If we only use CRC-7 we'd be discarding base contexts unnecessarily, and causing transmission of IR for case B-2. Please see my previous comment.

> that something is wrong with the context, so it must be 

The use of only 7-bit CRC for triggering IR(-DYN) is not good, please see my earlier comment. 

> > This is useful for the compressor to determine the cause of 

For the feedback message, the request for another NACK is mode specific and is for R mode. For U/O mode we don't need to send explicit NACK. The confusion is that we try to do profile independent CR discussion using a draft which is profile dependent.

> > regarding the CRCs that is not already addressed in the 

My proposal for CRC is mentioned in the next four lines.

> in the sense that it defines when it's ok to move from the 

I think we have introduced a new logic with context replication for IR-REP then IR. It uses a base context that has been acknowledged. It uses a unique packet format for encoding. It may send STATIC-NACK.
 
> over again for each specific profile.

I have used ROHC-TCP diagram to draw it. My main point is that should we add an "IR-REP" state or not? I have given my comments on this above. I also think that keeping this ROHC-CR document too generic so it won't have any substance in it to depict a meaningful picture is not a good idea.   

> > another state. The question is:

The relation is this, we can't send STATIC-NACK in IR state but we can send STATIC-NACK in IR-REP state. So by adding IR-REP state, we are keeping whatever ROHC has decided about IR state. Any new function or logic is executed from IR-REP state. 

> > specific to R-mode in it.

After reading the complete response from both of you, I think it would be better if we don't keep ROHC-CR generic, and make it specific for ROHC-TCP. How about changing it to ROHC-TCP-CR? In this way we will be able to put enough details and avoid unnecessary abstraction and confusion resulting from it. We agree that we need to do CR for ROHC-TCP first, so let's do this. IMO it is dangerous if we write this ROHC-CR implicitly assuming TCP and then try to mandate it as a generic CR solution for all the profiles. 

> context. In practice, I can't see why this would buy us anything...

The issue behind above disscussion is not about replicating a "mode", but the issue is that are we going to document how context replication would work in different modes? If yes, then where? in ROHC-CR or individual profiles. I have already suggested to have ROHC-TCP-CR and documenting in it whatever mode is relevant to TCP.

> > more specific in your comment.

I have explained the improvement by using case B-1 and case B-2 earlier. My first few comments in this response have all the specifics. 

> context replication is needed for other modes, we can always 

I agree with you. But also, change ROHC-CR draft to ROHC-TCP-CR draft. 

> need to be modified or extended to accommodate different 

I have no problem with this. The document should explicity say that it is applicable to ROHC-TCP and its modes. 

> to make this extra feedback option worthwhile?

The transmission errors are common in lossy links. That's where ROHC solutions will be used most.

Let me also repeat that this feedback is not needed for U/O-mode. It would be needed for R-mode. In U/O-mode the compressor may continue to send IR-REPLICATE. 

> --
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 
>

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 20 Jun 2003 17:31:42 +0100

> I am sorry if I was not clear earlier. Action on 8-bit CRC 
> (coverage complete IR-REPLICATE header) is taken after 
> decompressor fails 7-bit CRC (coverage original header) test. 
> If 7-bit CRC failed but 8-bit CRC passed, the decompressor 
> sends STATIC-NACK. It is sure now that the base context is 
> bad. If 7-bit CRC failed and 8-bit CRC also fails, then send 
> a NACK (R-mode) or ignore it and wait for subsequent 
> IR-RELICATE (U/O-mode). 8-bit CRC by itself is not considered 
> for decision. Please see my next comment also. 

Hi Yousuf,

From reading Ghyslain's last email, I think that the current actions taken
by the context replication draft are intended to be as follows:

i) If the 8-bit CRC succeeds but the 7-bit CRC fails then send a
STATIC-NACK.

ii) If the 8-bit CRC fails (and hence the 7-bit CRC fails implicitly as
    the packet can't be decompressed) then ignore the packet and wait for
    the next IR-REPLICATE.

This logic is fine for U/B-mode, and agrees with the logic you propose
above.
We might need different logic for different modes such as R-mode, but since
we should focus only on U/B-mode at this stage, the above logic is ok.

> I agree with you for items 1) and 2). The case B is the one I 
> want to differ. The decompression failure doesn't always mean 
> "bad context". Let me explain, we have 7-bit CRC that covers 
> original header and 8-bit CRC that covers the IR-REPLICATE 
> packet header excluding payload (this is with the proposed 
> modification). A decompressor receives an initial 
> IR-REPLICATE. It decompresses the packet by using the 
> referred base context and the static/dynamic replication 
> chains provided in the IR-REPLICATE message. After 
> decompression it calculates 7-bit CRC and fails the 7-bit CRC 
> test. There are two sources of error, either the referred 
> base context is bad (case B-1) or the static/dynamic 
> replication chain provided in the IR-REPLICATE is bad (case 
> B-2). Let's say if the static/dynamic chain is bad, then 
> there is no justification for labeling this context as the 
> "bad context". Here the 8-bit CRC comes handy, if it passes 
> CRC check then the decompressor knows that the static/dynamic 
> chains are fine but the context is bad, and sends STATIC 
> NACK. The mechanism I proposed substracts out case B-2 from case B.  

I agree that if the CRC-8 fails then no STATIC-NACK should be sent
(at least for U/B-mode). This isn't clear from the current draft, so
let's clarify it in the next version...

> CRC-7 by itself can't differentiate whether the error is in 
> the base context or the static/dynamic chains of 
> IR-REPLICATE. It is on the original header and can catch 
> error in the new replicated context, which is formed by the 
> aggregation of the base context and the received 
> static/dynamic chains. If we only use CRC-7 we'd be 
> discarding base contexts unnecessarily, and causing 
> transmission of IR for case B-2. Please see my previous comment.

Yes. If CRC-8 fails then no STATIC-NACK should be sent.

> For the feedback message, the request for another NACK is 
> mode specific and is for R mode. For U/O mode we don't need 
> to send explicit NACK. The confusion is that we try to do 
> profile independent CR discussion using a draft which is 
> profile dependent.

I agree that it isn't currently clear whether the draft is trying to
be applicable to all modes, or just to U/B-mode. My opinion is that
we should stick to U/B-mode for now, as this is the mode used by
ROHC-TCP.

> I think we have introduced a new logic with context 
> replication for IR-REP then IR. It uses a base context that 
> has been acknowledged. It uses a unique packet format for 
> encoding. It may send STATIC-NACK.

Note that the IR-REP state would be at the compressor rather than the
decompressor, so its logic would dictate the actions upon *receiving*
a STATIC-NACK rather than *sending* a STATIC-NACK.

However, I tend to agree that the IR-REPLICATE packet introduces new
logic which is different from the basic IR state. Therefore, it might
be clearer to introduce a new IR-REP state into the state machine.

> I have used ROHC-TCP diagram to draw it. My main point is 
> that should we add an "IR-REP" state or not? I have given my 
> comments on this above. I also think that keeping this 
> ROHC-CR document too generic so it won't have any substance 
> in it to depict a meaningful picture is not a good idea.   

Agreed!

> The relation is this, we can't send STATIC-NACK in IR state 
> but we can send STATIC-NACK in IR-REP state. So by adding 
> IR-REP state, we are keeping whatever ROHC has decided about 
> IR state. Any new function or logic is executed from IR-REP state. 

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).

> After reading the complete response from both of you, I think 
> it would be better if we don't keep ROHC-CR generic, and make 
> it specific for ROHC-TCP. How about changing it to 
> ROHC-TCP-CR? In this way we will be able to put enough 
> details and avoid unnecessary abstraction and confusion 
> resulting from it. We agree that we need to do CR for 
> ROHC-TCP first, so let's do this. IMO it is dangerous if we 
> write this ROHC-CR implicitly assuming TCP and then try to 
> mandate it as a generic CR solution for all the profiles. 

Would it be ok to make the draft specific to U/B-mode (which is used
in ROHC-TCP)? This would be more generic than making the draft
specific to ROHC-TCP, as we could then apply context replication to
other ROHC profiles that also use U/B-mode.

> The issue behind above disscussion is not about replicating a 
> "mode", but the issue is that are we going to document how 
> context replication would work in different modes? If yes, 
> then where? in ROHC-CR or individual profiles. I have already 
> suggested to have ROHC-TCP-CR and documenting in it whatever 
> mode is relevant to TCP.

I think it's clear that we can't produce a context replication draft
which is generic to all ROHC modes, as the draft would essentially
end up saying nothing. If we keep the draft specific to U/B-mode for
now then it will be much easier to define the compressor and
decompressor logic for context replication.

I still think it's worth keeping the context replication material
separate from the genuinely TCP-specific material such as the packet
formats. Even if context replication only applies to U/B-mode, it
can still be reused for other ROHC profiles that also use this mode.

> Let me also repeat that this feedback is not needed for 
> U/O-mode. It would be needed for R-mode. In U/O-mode the 
> compressor may continue to send IR-REPLICATE. 

I agree with the above. The suggestion to introduce a new feedback
option might make sense for certain ROHC modes, but not for U/B-mode
as used in ROHC-TCP. Let's focus on this mode for now...

Regards,

Richard

---

From: [email-masked]
Date: Fri, 20 Jun 2003 12:31:53 -0500

Hi Richard,
After reading your response, I think the only issue we need to resolve is the definition of 8-bit CRC. Please see my first comment below.

BR,
Yousuf

> Sent: Friday, June 20, 2003 11:32 AM
> To: Saifullah Yousuf (NRC/Dallas); [email-masked]
> Cc: [email-masked]

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. 

> > > state machine used in ROHC-TCP. It would be a mistake to 
> make the draft
> too
> > > generic, as we would then need to redefine the state 
> transition logic
> all

I agree.

> other ROHC profiles that also use U/B-mode.

Agreed! We should also explicitly state that in the draft for clarification.

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 23 Jun 2003 18:50:08 +0100

> 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.

This seems like a sensible way to proceed. We should keep the ROHC-CR
mechanism applicable to more profiles than just ROHC-TCP, but not at
the expense of significant extra work (since ROHC-TCP is still the
primary motivation for context replication). Same approach as we're
taking for the formal notation.

> 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.

Yes. With any luck, the only profile-specific part of ROHC-CR will be
the IR-REPLICATE packet formats.

> 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.

Yes.

> 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. 

Agreed.

> 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).

We also need to specify that if the CRC-8 fails then a STATIC-NACK
is not sent (Section 5.2.6 of RFC 3095 does not mandate whether to
do this or not, and in fact O-mode *does* send a STATIC-NACK if the
CRC-8 fails).

> 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

In general, I believe that the purpose of the compressor state machine
is to provide information needed by a context to decide which packet
format to use when compressing a header. Different states allow a
different range of packet formats to be used. Transitions between the
states occur as a result of feedback from the decompressor, or due to
compressor-local mechanisms (e.g. optimistic approach, timeouts etc.).

Context replication provides an additional factor to take into account
when choosing a suitable packet format - namely whether a base context
is available or not. This factor works in exactly the same way as the
existing states in the compressor state machine. It determines the
range of packet formats that can be used, and it is changed as a
result of feedback from the decompressor or due to compressor-local
mechanisms (i.e. discovering that a suitable base context is available).

It therefore makes sense to introduce a new "REPLICATE" state into the
compressor state machine. The only alternative would be to introduce
context replication as a "sub-state" to one of the existing states,
e.g. dividing the IR state into an IR-ORDINARY and an IR-REP sub-state.
However, to me this is much more confusing. It's not at all clear that
context replication is a particular instance of the IR state - on the
contrary, I think that it has more in common with the CO state than the
IR state. In particular, both IR-REP and CO states allow packet formats
to use window-based encoding methods, which is explicitly banned in the
RFC 3095 definition of the IR state.

>   and because ROHC-CR does not define a complete state machine.

However, ROHC-TCP itself will certainly have to define a state machine
for the compressor, and this state machine will need to take context
replication into account. I don't see any advantage in creating a basic
ROHC-TCP state machine and then trying to add context replication as an
extra feature on top. Why not just build support for context replication
into the state machine from the beginning?

>   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).

There's more to a state machine than just the state transition logic. We
also need to define the range of packet formats that can be used for a
given state, and any context entries needed to retain the state of the
state machine between successive packets.

For context replication we're introducing two new pieces of information
that must be stored in the compressor context: the identifier for the base
context, and some kind of indicator that the base context is valid. I
think it makes sense for this indicator to be stored as an extra state
for the state machine (i.e. as an extra value for the context entry
C_STATE), which says that the base context is valid and can be used.

>   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.

I think that the text will be much less confusing if we treat IR-REP as
a new state, rather than trying to shoehorn it into the existing IR state,
where it doesn't really fit.

>   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. 

I don't see how we can avoid adding a new state for context replication,
except by making it a sub-state of the existing IR state or the CO state.
I think that this latter approach would be much more confusing...

Moreover, are there any real advantages in *not* introducing a new state
for context replication?

> 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.

Agreed.

> Let me know if I have missed something. Thanks again.
> 
> /Ghyslain
>

---

From: [email-masked]
Date: Mon, 23 Jun 2003 16:52:57 -0500

Hi Ghyslain and Richard,
Please see my response below.

Thanks,
Yousuf

> Sent: Monday, June 23, 2003 12:50 PM
> To: 'Ghyslain Pelletier'; Saifullah Yousuf (NRC/Dallas); [email-masked]

Agreed, but all the assumptions need to be documented in the draft. This would help in case there is a need for extending the protocol to the other profiles. 

Agreed.

Agreed.
Agreed.
> do this or not, and in fact O-mode *does* send a STATIC-NACK if the

I agree with Richard's comment.

> Moreover, are there any real advantages in *not* introducing 

On this "IR-REP" discussion, I support Richard's comments. I have given my reasons and I don't have anything else to add.   

Agreed.