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

[[e-mail]]

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:[e-mail]]
Sent: Wednesday, June 04, 2003 3:20 AM
To: [e-mail]
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 : [phone] 
Mobile: [phone]
[e-mail]
http://www.ericsson.com
_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc