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

[[e-mail]]

Hi Ghyslain,
Thanks for providing clarification. Few inline comments below.

Regards,
Yousuf

-----Original Message-----
From: ext Ghyslain Pelletier [mailto:[e-mail]]
Sent: Thursday, June 05, 2003 9:45 AM
To: Saifullah Yousuf (NRC/Dallas)
Cc: [e-mail]
Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed


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

[e-mail] wrote:
> 
> 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.

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.

[Yousuf] Your answer under the following comment has provided the clarification. Thanks!
 
> - 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).

[Yousuf] The above text is clearer than the text in the draft. You may 
like to use the above clarification in the draft.
 
> 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.

[Yousuf] At this moment the draft is suggesting it. But, eventually
the format of IR-REPLICATE packet per profile needs to be standardized. If not this document
then may be the per profile document would be the place to put this format as
normative text.
 
> 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.

[Yousuf] That would be good. I would also support using codes and add all 
the fields.

> 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

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