Subject: RE: [rohc] Comments on RoHC v2 Draft

From: "Ghyslain Pelletier" <[email-masked]>
Date: Tue, 13 Nov 2007 17:01:48 +0100

Hello,
Thanks Rohit for your review. Sorry for the late reply ...
I have cut out parts that were agreed that were fine with me.
See inline.
Cheers,
///Ghyslain

Kapoor, Rohit wrote:
> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: Mon 10/22/2007 6:53 AM
> Kapoor, Rohit <mailto:[email-masked]> wrote on den 18 oktober
> 2007 19:35 : 

[cut]

>> 2) Section 4.2:

[cut]

>> 
>> "Profiles defined in RFC3095 require that the channel between
>> compressor and decompressor provide in-order delivery between
>> compression endpoints." 
>> 
>> This does not capture the entire picture of RFC 3095.
>> 
>> Replace with: "Profiles defined in RFC3095 require that the
>> channel between compressor and decompressor provide in-order
>> delivery between compression endpoints, however they can handle
>> a limited amount of reordering before the compression point."
>> 
> 
> Sounds like a reasonable change, since prelink is mentioned for v2
> but not for v1. Will update.

[GHPE] The proposed wording is incorrect. The intent seems to adjust the
way both sets of profiles are compared. I think however that the
original text still conveys the appropriate message. The text proposed
above applies only to the smallest compressed format (i.e. PT-0 in 3095)
and only for the RTP and ESP profiles. Obviously, any profile handles
any amount of reordering before the compressor, it is simply a matter of
what compressed format to use. 

[GHPE] My proposal - revert to original text. Alternatively to replace:
"reordering before and after the" with
"reordering after the"
 
[cut]

>> 
>> 4) Section 5.2.2: "A packet
>> for which the CRC succeeds updates the reference values of
>> all header fields, either explicitly (from the information
>> about a field carried within the compressed header) or implicitly
>> (fields that are inferred from other fields)."
>> 
>> This conflicts with text above in point 3, where the
>> decompressor "may refrain from using this packet as the new
>> reference packet".
> 
> Agreed, maybe "usually updates" or "normally updates" instead is
> sufficient to capture this?
> 
> <Rohit> OK. Sounds good.

[GHPE] I would not use the wording "usually" or "normally", because then
we need to define what is abnormal or unusual. I would not change
anything, as I do not see any conflict; the fact is that all packets in
RoHcv2 have a CRC (the wording is "updates" and not "MUST" meaning that
this is the normal outcome), the decompressor is thus always allowed to
update the context after successful deocmpression. But it may do
otherwise if it knows better (may refrain).

[GHPE] My proposal - revert to original text.

>> 
>> 5) Section 5.2.2: "   Validity of the context rather relates
>> to the detection of a problem with the context.  The
>> decompressor first assume that the type of information that
>> most likely caused the failure(s) is the state that
>> normally changes for each packet, i.e. context damage of
>> the dynamic part of the context.  Upon repeated decompression
>> failures and unsuccessful repairs, the decompressor then
>> assumes that the entire context, including the static part,
>> needs to be repaired, i.e. static
>> context damage.  Failure to validate the 3-bit CRC that protects
>> control fields should be treated as a decompression
>> failure when the decompressor asserts the validity of its context."
>> 
>> Though this is in an informative section, this text sounds a
>> bit normative. Can we make it sound a little more
>> informative? How about something on these lines (some minor changes):
>> 
>> "   Validity of the context rather relates to the detection
>> of a problem with the context.  The decompressor ++may++ first
>> assume that the type of information that most likely caused the
>> failure(s) is the state that normally changes for each packet, i.e.
>> context damage of the dynamic part of the context.  Upon repeated
>> decompression failures and unsuccessful repairs, the decompressor
>> ++may++ then -assume-- that the entire context, including the static
>> part, needs to be repaired, i.e. static context damage.  Failure to
>> validate the 3-bit CRC that protects control fields should be
>> treated as a decompression failure when the
>> decompressor asserts the validity of its context."
>> 
> 
> I think the current text is ok, but I can also agree to your
> suggestion. Unless my my co-author objects, I'll change it.
> 
> <Rohit> OK. I don't feel strongly about changing it, but I think it
> would help readability in terms of the intent of the section. 

[GHPE] My proposal is to leave the text unchanged. The reason for this
is that the use of the word "assume", which concept is defined somewhere
else in the document (in a manner that is open to implementations), is
already strongly implying that this is an implementation issue.
 
[cut]

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

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 15 Nov 2007 16:16:19 +0100

Hi,

I have some comments on the suggested text for "Tolerance to reordering"
in section 4.2. See inline..

Cheers,

/Calle

> what compressed format to use. 
I agree with Rohit to some point, but we don't have to capture the
picture of RFC3095. However I agree that you can get the picture that
RFC3095 doesn't support prelink reordering when you read this paragraph.

> "reordering before and after the" with
I am in favor for Ghyslains "alternative" change. But if we change this
we will not mention the improved prelink reordering support that the
adjustable interpretation interval offset for msn gives the ROHCv2 profiles.

I suggest changing the text to something like the following:

     "Profiles defined in RFC3095 require that the channel between
     compressor and decompressor provide in-order delivery between
     compression endpoints. ROHCv2 profiles, however, can handle
     robustly and efficiently a limited amount of reordering ---before
     and--- after the compression point as part of the compression
     algorithm itself. +++In addition, the improved reordering support
     makes the ROHCv2 profiles handles prelink reordering more
     efficiently.+++

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Thu, 15 Nov 2007 17:00:02 +0100

ACK. Looks good.
Cheers,
///Ghyslain

Carl Knutsson wrote:
>>> Sent: Mon 10/22/2007 6:53 AM Kapoor, Rohit
>>> <mailto:[email-masked]> wrote on den 18 oktober 2007 19:35 :
>> 
>> [cut]
>> 
>>>> 2) Section 4.2:
>>>> 
>> 
>> [cut]
>> 
>> [GHPE] The proposed wording is incorrect. The intent seems to adjust
>> the way both sets of profiles are compared. I think however that the
>> original text still conveys the appropriate message. The text
>> proposed above applies only to the smallest compressed format (i.e.
>> PT-0 in 3095) and only for the RTP and ESP profiles. Obviously, any
>> profile handles any amount of reordering before the compressor, it
>> is simply a matter of what compressed format to use.
>> 
>> [GHPE] My proposal - revert to original text. Alternatively to
>> replace: "reordering before and after the" with
>> "reordering after the"
>>

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 20 Nov 2007 17:56:12 -0800

I agree with Carl's suggested change.

Thanks,
Rohit

> From: Carl Knutsson [mailto:[email-masked]]
> Sent: Thursday, November 15, 2007 7:16 AM
> To: Ghyslain Pelletier
> Cc: Kapoor, Rohit; Kristofer Sandlund; rohc
> Subject: Re: [rohc] Comments on RoHC v2 Draft
> 
> >