Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

From: [email-masked]
Date: Wed, 4 Jun 2003 16:56:03 -0500

Hi Gyslain,

The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt):

- Section 3.2.2: What is "OPTIONAL improved forward transition"? I was not able to find any description for this term.

- Section 3.2.2.1 - last two paras: NACK is not sent in response to IR-REPLICATE. Instead, it looks like that it is a general failure information procedure for informing decompression of a subsequent packet not IR-REPLICATE. I think these two paras are irrelevant to context replication. I'd suggest to either take out these paras or explicitly mention that this is a general failure procedure.

- Section 3.3.2 - Third para: Could you please clarify when the compressor will be sending IR-REPLICATE packets as subsequent packets after receiving ACK for successful decompression of the initial IR-REPLICATE. The decompressor after successfully validating IR-REPLICATE will send ACK, which moves the compressor from IR to CO state (taking ROHC-TCP state machine). I think in this state the compressor will be sending compressed packets not IR-REPLICATE. 

- 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. 
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.
The logic would work something like this:
- if 7-bit CRC failed, send STATIC-NACK
- if 8-bit CRC fails, send another NACK (let's call it REP-NACK). 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 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).

Section 3.4.1 - third para: The way I understood this para is that the 8-bit CRC could cover entire IR header but a profile may not do that and the reason is in section 5.2.6 of RFC 3095. I was unable to find the explanation in the reference, could you please explain this limitation. 

Section 3.4.2 - IR-REPLICATE format figure: I think it would be more clear to show 7-bit CRC and Base CID in the figure. These fields are described but are not shown in the figure. 

Appendix A: Is this the intention that the formats mentioned in this Appendix will become standardized format? If that is the case, then I would suggest to put these formats in the main body of the draft not in appendix.

A.1: Why didn't we define a flag for marking Traffic Class as replicable? Is this because adding a bit would mean adding a byte and that would exactly be the saving in the Traffic class case?
A.2: The two spare bits left in the first byte can be used for the replication flags for Type of Service and Identification fields. This will not cause any addition in the packet size. Could you please define the spare bits as the flags.

Regards,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[email-masked]]
Sent: Wednesday, June 04, 2003 3:20 AM
To: [email-masked]
Subject: [rohc] ROHC-TCP: Update and some topics to be discussed

ROHCers,

The discussions regarding the ROHC-TCP profile need to be restarted on
this mailing list. Let me try to kickstart this...

An updated version of the draft describing the ROHC profile of TCP,
<draft-ietf-rohc-tcp-04.txt>, has been submitted. The following has been
updated:

- The normative section on context replication has been removed.
  Instead, the definition of the context replication mechanism
  has been submitted in a separate draft, mainly for clarity.

- A basic structure for the IR/IR-DYN packets has been proposed.
  This structure uses static and dynamic chains. See Section 5.5.1.
  See also issue #3 later in this mail.

- A basic structure for the IR-REPLICATE packet has been proposed.
  It follows the structure suggested in the context replication draft.
  See Section 5.5.3. See also issue #2 later in this mail.

- Feedback format and options for ROHC-TCP has been defined.
  See Section 5.5.4.

- Section 6 - Implementation parameter - has been removed.

Please comment on these changes and the updated version in general.

For the TCP profile to move forward, I have tried to summarize some of
the topics that require further discussions on the mailing list:

1) Packet formats for ROHC-TCP, two alternatives:

  o Use ROHC-FN, and how to include the packet formats in the
    normative part of the TCP draft, or;
  o Use box or list notation with corresponding normative text
    describing how to encode and decode each field in the header,
    as in RFC-3095.

2) Context replication (See the separate draft)

3) IR/IR-DYN format for ROHC-TCP

  The content of Section 5.5.1 is a suggestion from the editor, for
  the purpose of providing grounds for discussions. This section does
  not represent a consensus and the following needs to be addressed:

  o Should we use static and dynamic chains, as in 3095?
  o Compression of TCP options for IR/IR-DYN
  o Compression of other TCP fields in IR/IR-DYN:
    - "data offset" is redundant
    - "IP protocol" can be derived from the profile number
    - "IP version" -> only two possible values, only one
      bit is required.
    - "TTL", particularly when compressing over the first hop
    - "MSN", could be LSB coded
   
4) Master Sequence Number (MSN)
  o initialization of MSN (0?)
  o compression of MSN within the packet format (LSB coded?)

So please feel very welcome to jump into any of these questions. It
would be good to be capable of moving forward rapidly so that a new
update can be generated in time for the Vienna meeting. Thanks!

Regards,

/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) 70 609 27 73
[email-masked]
http://www.ericsson.com
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Ghyslain Pelletier <[email-masked]>
Date: Thu, 05 Jun 2003 16:45:20 +0200

Hi Yousuf,

Thanks for your comments. Some answers in-line. I will get back to some
of the issues I won't address in this mail in a later mail.

Regards,

/Ghyslain

[email-masked] wrote:
> - Section 3.2.2: What is "OPTIONAL improved forward transition"?
> I was not able to find any description for this term.

This is written in the same way as in RFC-3095, section 5.4.1.1.
Basically, what this means is that it is not necessary - the compressor
may still transit to a higher state, but it can help such a transition
to happen faster.

> - Section 3.2.2.1 - last two paras: NACK is not sent in response to
> IR-REPLICATE. Instead, it looks like that it is a general failure
> information procedure for informing decompression of a subsequent
> packet not IR-REPLICATE. I think these two paras are irrelevant to
> context replication. I'd suggest to either take out these paras or
> explicitly mention that this is a general failure procedure.

I am not sure that I understand the first statement in the comment. What
do you mean by "NACK is not sent in response to IR-REPLICATE"? I'd like
you to bring some precisions so I can bring you a better answer. Section
3.3.2. of the draft states that the decompressor can send a NACK in
response to an IR-REPLICATE in some cases.
 
> - Section 3.3.2 - Third para: Could you please clarify when the
> compressor will be sending IR-REPLICATE packets as subsequent packets
> after receiving ACK for successful decompression of the initial
> IR-REPLICATE. The decompressor after successfully validating
> IR-REPLICATE will send ACK, which moves the compressor from IR to CO
> state (taking ROHC-TCP state machine). I think in this state the
> compressor will be sending compressed packets not IR-REPLICATE.

I think that we do not prevent the IR-REPLICATE to be sent and
decompressed in other states than IR state, that is we do not prevent it
(and I don't think we can anyway) to be used as an ordinary packet.

[snip]
[I'll get back on the feedback and failure mechanism.]
[I think this should be taken separately.]

> 
> Section 3.4.1 - third para: The way I understood this para is that
> the 8-bit CRC could cover entire IR header but a profile may not do
> that and the reason is in section 5.2.6 of RFC 3095. I was unable to
> find the explanation in the reference, could you please explain this
> limitation.

Recall point 10) in section 5.2.6. of RFC-3095 states:

 10) If the packet type is IR, the profile indicated in the IR packet
     determines how it is to be processed.  If the CRC fails to verify
     the packet, it MUST be discarded.  If a profile is indicated in
     the context, the logic of that profile determines what, if any,
     feedback is to be sent.  If no profile is noted in the context,
     no further action is taken.

This is framework logic, and the IR-REPLICATE is also an IR packet. The
text in the context replication draft states the consequence of that
point for the IR-REPLICATE regarding the type of CRC, its presence in an
IR packet (thus this applies to the IR-REPLICATE as well) and nature of
what it protects (e.g. it cannot be redefined to cover say the original
uncompressed header instead). Therefore only the extent of the CRC
coverage can be redefined by a profile and it must meet the minimal
coverage required (CID, Profile, etc. - that is at least the initial
part of the packet ending with the Profile field).
 
> Section 3.4.2 - IR-REPLICATE format figure: I think it would be more
> clear to show 7-bit CRC and Base CID in the figure. These fields are
> described but are not shown in the figure.

The 7-bit CRC (always present) and the Base CID (if present) are both
part of the profile specific information. This means that how they are
to be represented in the format depends on the packet format defined by
a specific profile, and this may vary from one profile to another.
Therefore it would not be appropriate in my opinion to show these fields
in the figure. Consider for example a profile that would define two
"sets" of packet formats, one of which includes the Base CID for when
the compressor wants to create a different context and keep the base
context, and one that doesn't for when we want to overwrite the base
context. Another profile might be defined so that the Base CID field is
always present in the format.

Still, it is appropriate for the text to mandate the presence of a 7-bit
CRC in the packet and mention that an identifier to the Base CID may be
present because these belong to the replication mechanism - their
functionality and nature is defined by context replication.
 
> Appendix A: Is this the intention that the formats mentioned in this
> Appendix will become standardized format? If that is the case, then I
> would suggest to put these formats in the main body of the draft not
> in appendix.

The appendix is informative. This is simply a suggestion to exemplify a
possible structure to the IR-REPLICATE packet. Other approaches than
chains (for example) might be taken. As said previously, this part is
profile specific, so I am not sure how/if we can make this part
normative in this document. See also my reply to Richard's comments on
this.
 
> A.1: Why didn't we define a flag for marking Traffic Class as
> replicable? Is this because adding a bit would mean adding a byte and
> that would exactly be the saving in the Traffic class case?

This can be added without requiring another octet. We could use codes
insteads of flags. As Richard pointed out, we could also add hop limit
as well. I can update that.

> A.2: The two spare bits left in the first byte can be used for the
> replication flags for Type of Service and Identification fields. This
> will not cause any addition in the packet size. Could you please
> define the spare bits as the flags.

Yes, I can do that. As Richard pointed out, we could also add TTL as
well.

Thanks for your comment. I will get back on the question I haven't
answered in a later mail.

/Ghyslain

---

From: Ghyslain Pelletier <[email-masked]>
Date: Tue, 17 Jun 2003 11:32:21 +0200

Hi Richard and 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.

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

Mobile: +46 (0) 706 09 27 73