Subject: RE: [rohc] Update of ROHCv2 profiles draft

From: "Kapoor, Rohit" <[email-masked]>
Date: Mon, 11 Jun 2007 19:01:39 -0700

Kristofer, Ghyslain,

Thanks for the updated draft. Pls find few comments below:

1) Regarding use of timer-based compression in pt_1_seq_ts, I had
brought up this issue earlier, but haven't seen any resolution for it in
the current draft. The issue was that timer-based will require 5 bits to
handle a reasonable amount of jitter, but the pt_1_seq_ts packet in the
current draft only has 4 bits. Also, if the number of bits for TS in
pt_1_seq_ts is increased from 4 to 5, it would still be good for the
packet size to stay as 2 octets (so that performance of RoHC v2 for
VoIP-like applications is not worse than that of RFC 3095). For this, we
had also proposed the solution below.

Quoting from earlier email:

"The addition of Timer-Based compression (for which TS will require at
least 5 bits to handle a reasonable amount of jitter) should not cause
the pt_1_seq_ts packet to exceed 2 octets. To allow this packet to fit
within 2 octets, I am providing below a suggestion of what packet
discriminators can look like (if timer-based and pt_0_crc7 are both
added).
 
pt_0_crc3: "0"
pt_1_rnd: "10" (1 extra bit for use; TS can have 1 extra bit)
pt_1_seq_id: "100" (1 extra bit for use; either MSN or IP-ID can have 1
more bit)
pt_1_seq_ts: "101" (now this has 1 extra bit for TS, making a total of 5
TS bits).
pt_0_crc7: "1100" (this has 1 less bit now; so maybe MSN can be reduced
to 5 bits, which is still very robust).
pt_2_rnd: "1101" (1 fewer bit for use; MSN can be reduced from 7 to 6
bits)
pt_2_seq_ts: "11011" (1 fewer bit for use; MSN can be reduced from 7 to
6 bits)
pt_2_seq_id: "110100" (2 fewer bits for use, 1 of them due to the
addition of pt_2_seq_both; both MSN and IP-ID can be reduced by 1 bit
each)
pt_2_seq_both: "110101"

Note that this is just an example of a solution. Any proposal which
handles this issue would be OK for me.

2) Section 6.8.3.1 says the following:   "The following packet formats
exist **exclusively** for profiles 0x101 and 0x107" and then later also
"The following packet formats exist **exclusively** for profiles
0x102,0x103, 0x104 and 0x108". But, some of the packet formats (such as
pt_1_seq_id) are defined under both of these sentences.

3) ts_stride_value and time_stride_value are defined as:

         ts_stride_value: This parameter is set to a user-selected value
         that is the expected increase in the RTP Timestamp between
         consecutive sequence numbers.  See also Section 6.6.8.

         time_stride_value: This parameter is set to a user-selected
         value that is the expected inter-arrival time between
         consecutive packets for this flow.  See also Section 6.6.9.

Are these intended to be user-selected values?

Thanks,
Rohit

> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]]
> Sent: Thursday, May 24, 2007 11:48 PM
> To: [email-masked]
> Cc: Ghyslain Pelletier (LU/EAB)
> Subject: [rohc] Update of ROHCv2 profiles draft
> 
> Hi all,
> 
> we have just sent in an update of the profiles draft which
> mostly contains the changes discussed on the list towards the end of
> last year. The draft should be announced within the next couple of
days
> as usual.
> Here is a list of changes since the previous revision.
> 
> Changes in the FN code (packet formats):
> - Lots of minor typos and smaller bug fixes related to FN syntax
> - Fixes to scaled encoding and MSN handling
> - Style-related cleanup to make the code more consistent
> - Addition of many ENFORCE-statements to make the code more formally
>   correct
> - Added a co_repair format for all profiles which is bitwaise very
>   similar to co_common (so it should be very easy to implement), but
>   has the possibility of sending all LSB-fields as
>   uncompressed (should be seen as an IR-DYN replacement)
> - Repair-specific irregular chain items added in order to make context
>   repair for outer headers, including extension headers, but have LSB
>   encoded fields sent uncompressed
> - Optimized the co_common formats with "meta-discriminators" in order
to
>   reduce the flag overhead
> - Added timer-based compression (this still needs to be added to the
> text
>   where we just have a placeholder section for now)
> - Fixed ESP static chain so encrypted and null-encrypted static chains
> can
>   be discriminated from each other
> - LSB-offsets are made much more consistent throughput the formats
> - Header chain termination for IP-only profile (different static chain
>   items if this is the terminating IP header)
> 
> Changes to the text:
> - Text on scaled encoding re-written and improved
> - External arguments to the FN code section added
> - Design rationale for the packet formats section added
> - Text on state logic improved
> - Clarifications around the unidirectional/bidirectional operation
> - Added new feedback option for requesting update of control fields
>   (to be used with NACKs)
> - Update of Appendix A (field classifications) which was previously
>   imported from RFC3095 and contained a bunch of errors
> - Removed Appendix A.3
> - CRC algorithm and demo are now in framework, so it is removed from
>   this draft
> - Added section about handling reordering
> - Removal of the IR-DYN packet format from all these profiles
> 
> The draft still needs some more work in a few areas, but we are
getting
> closer to finalizing this work now, so we would be very grateful
> if you read and comment on this draft so that it contains what you
> expect it to.
> 
> Thanks to all the people who contributed on the list to the
discussions
> on this draft!
> 
> /Kristofer & Ghyslain
> 
> _______________________________________________
> 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: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Tue, 12 Jun 2007 08:44:06 +0200

Hi Rohit,

thanks for your comments. My answers inline.

Kapoor, Rohit <mailto:[email-masked]> wrote on den 12 juni 2007
04:02 :

> the current draft.

Since we hadn't decided what to do on that last time we discussed it, I
left the following TODO in the draft:

// TODO:
// - PT_0/PT_1 packets? Use "tbc-optimized" or "msn-optimized"

So it was not forgotten, we just preferred to get out a new revision of
the
draft as soon as we could and let us continue the discussion later.

I will give a more detailed answer on this issue later this week or next
week

> The issue was that timer-based will
> require 5 bits to
> bits) pt_2_seq_ts: "11011" (1 fewer bit for use; MSN can be reduced
> from 7 to
> 6 bits)
> each) pt_2_seq_both: "110101"
> 
> 

Ok, I can agree the text could use some polishing :)
The point of the text is that the RTP-based profiles contain different
fields
then the others, but I could have phrased it better. Will think of
something
for the next revision.

> Are these intended to be user-selected values?

Yes, they are "user-selected" the same way they are that in 3095 in the
sense that they can be set to any value independent of what is in the
packet
stream (of course, there are just a couple of values that would make for
efficient compression). But maybe the word "user" is not the best word
to
use here, since it might be interpreted by some as if it is set up
during
configuration while it is *usually* set by inspecting the flow over
time.

Do you have any suggestion for a better phrasing?

/Kristofer

>> days as usual. Here is a list of changes since the previous revision.
>> 
>> - Repair-specific irregular chain items added in order to make
>>   context repair for outer headers, including extension headers, but
>>   have LSB encoded fields sent uncompressed
>>   text where we just have a placeholder section for now)
>> - Fixed ESP static chain so encrypted and null-encrypted static
>>   chains can be discriminated from each other
>> - Header chain termination for IP-only profile (different static
>>   chain items if this is the terminating IP header)
>> 
>> Changes to the text:
>> getting closer to finalizing this work now, so we would be very
>> grateful 
>> discussions on this draft! 
>> 
>> /Kristofer & Ghyslain
>>

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 13 Jun 2007 09:44:34 -0700

Kristofer,

Thanks for the reply. Pls see some comments below.

> Sent: Monday, June 11, 2007 11:44 PM
> To: Kapoor, Rohit; [email-masked]
> Subject: RE: [rohc] Update of ROHCv2 profiles draft
> 
> Hi Rohit,
> 

<Rohit> OK, look forward to your answer.

> configuration while it is *usually* set by inspecting the flow over

<Rohit> How about using RFC 3095-like language?

      TS_STRIDE: Predicted increment/decrement of the RTP Timestamp
      field when it changes.
 
      TIME_STRIDE: Predicted time interval in milliseconds between
      changes in the RTP Timestamp.

Thanks,
Rohit

---

From: "Jin, Haipeng" <[email-masked]>
Date: Thu, 14 Jun 2007 22:05:04 -0700

Hi, Kristofer and Ghyslain,

Great effort in updating the profile draft!

I have the following comments:
1. Decompressor state:
I remember we had some discussion on the state diagram in section 5.3.1.
It is not possible to transit from NC to FC directly. The main reason is
that IR-DYN carries CRC-8 but does not verify the entire context so a
CRC-7 packet such as co-common or p0-crc7 is needed as an intermediate
step. Now that IR-DYN is removed, I would propose to change the stage
diagram to allow direct transition from NC to FC with CRC-8
verification. I still don't see how the two-step upward transition helps
to make the decompression process more robust. Actually, it may make
things worse in some cases, for example, if the compressor sends a
couple of IRs, followed by a couple of p0-crc7 and then a number of crc3
packets. If the p0-crc7 packets are erases and the decompressor stays in
IC, all the subsequent crc3 packets will be dropped even without
decompression attempt when those packets can actually be decompressed
successfully. This is even worse if the compressor is working in
non-feedback mode.

Another question I have regards decompressor state is: in section
5.3.1.3, the text says "The decompressor moves back to the IC state if
it assumes context damage, and back to the NC state if it assumes static
context damage." about downward transition, this is not consistent with
the diagram. So what is the real intend here? Are you thinking to allow
direct transition back from FC to NC?

2. IP-ID behavior

The new profile only allows sequential behavior to inner IP-ID. For all
outer headers, IP-IDs are assumed to be either constant or random. This
means that in two-level IP headers (e.g. MIP) case which may be a common
use case in wireless networks, the compressor may not be able to
compress the packet as efficiently as in RFC3095. It would be great if
you can add an sequential indicator for the outer header to handle at
least this case.

3. Packet formats

I have similar concerns as Rohit on the packet formats and bit number
allocations and will try to follow your response on the existing thread.

That is for now. 

Best Regards,
Haipeng

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Fri, 15 Jun 2007 10:25:33 +0200

Hi Haipeng,

comments inline as usual.

Jin, Haipeng <mailto:[email-masked]> wrote on den 15 juni 2007
07:05 :

> verification.

The IR packet has the same potential issue as the IR-DYN packet, i.e.
that it may omit control fields from the packet and these do not get
verified by the CRC-8. Therefore, I think the 2-step transition is still
a valid choice. 
The alternative is still to try to beef up the IR
by either adding an extra CRC or mandating the presence of control
fields
etc, but I think that's going to be a lot more "patch-work" (and more
overhead) than having a 2-step transition which is simple. And the cost
is quite minimal since you're not going to be in NC state very often.

I would have liked to change the coverage of the existing CRC-8 for
the IR, but since that is defined by the framework, that's not an
option,
unfortunately.

Anyway, note that section 5 is informative, so if an implementation
wants to do something else such as a one-step approach, that would not
be illegal, although it is not the main recommendation of this spec

> I still don't see how the two-step upward
> transition helps

As stated above, there's a larger chance of things going wrong with
the one-step approach. And since we're using the optimistic approach,
the chance of losing all pt-0-crc7 (as in your example above) that you
send should be very small, otherwise the compressor has chosen a bad 
optimistic approach value.

> direct transition back from FC to NC?

Agreed, the text and the picture are inconsistent. I would probably
prefer adding an extra arrow to the picture, but I think the other
option is also viable. What's you opinion?

> you can add an sequential indicator for the outer header to handle at

Here, I refer to the motivations in the now-expired requirements draft
that this WG agreed on for ROHCv2, see section 2.6 of this one:
http://tools.ietf.org/html/draft-ietf-rohc-rfc3095bis-improvements-03

So I would be very much against changing this since that adds a lot
of complexity and it gives a very minimal gain and only for a very
small subset of tunneled packets.

> allocations and will try to follow your response on the

Ok, since that's a bit more complex issue, I will get back to that when
I have had more time to prepare a comprehensive answer and re-read all
the old discussions we had last year.

BR,
   Kristofer

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Fri, 15 Jun 2007 06:51:47 -0700

<Kristofer> Anyway, note that section 5 is informative, so if an implementation
wants to do something else such as a one-step approach, that would not
be illegal, although it is not the main recommendation of this spec

Since Section 5 is informative, I am assuming that the decompressor state transition (i.e., NC -> IC -> FC) is also informative. Also, there is no requirement on the compressor to send packets according to this transition of the decompressor.

As an example, say the decompressor implemements a 2-state transition as above. Say, the compressor sends a few IRs followed by a UO-0. The IRs will cause the decompressor to transition from NC to IC, but the UO-O will be received when the decompressor is in IC, and will cause a failure.

If most decompressor implementations follow the recommended 2-step state transition diagram but there is no requirement (or recommendation) on the compressor to send a CRC-7 packet after sending IRs, isn't this broken?

Thanks,
Rohit

---

From: "Jin, Haipeng" <[email-masked]>
Date: Mon, 18 Jun 2007 18:09:32 -0700

Hi, Kristofer,

Thanks for your reply, please see more comments following yours.

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]] 
Sent: Friday, June 15, 2007 1:26 AM
To: Jin, Haipeng; [email-masked]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: [rohc] RE: Comments on ROHCv2 profiles draft 

Hi Haipeng,

[Haipeng] The framework only says the coverage of CRC-8 for IR is
profile-dependent and recommends what is the minimal that need to be
covered. If you think there are fields that need to be covered in
RTP/UDP/... profiles, wouldn't it be great to list them out and have a
discussion here and maybe make the coverage mandatory in these profiles?

[Haipeng] The problem is that the text gives the impression that only
two-step transition is allowed. For example, if no CRC7 is received
in-between crc8 and crc3 packets, the decompressor will not attempt
decompression on those crc3 packets. If both options are allowed, then
it would be great if the text can be clarified to convey the idea. I
understand that it might be hard to express all possibilities in the
diagram before making it appear messy, maybe an alternative is to make
the diagram simpler. Instead of showing all transition possibilities
which are not currently done as you pointed out, the diagram can show
only the three available states and general transition connections. The
text can be enhanced to capture all the conditions.  

[Haipeng] The reason I gave this example is because in the past email
threads, similar examples (IR re-ordering followed by crc3 packets) were
used to show why two-step transition is needed. I agree that if the
compressor can choose a good OAA value, then neither that example nor my
example will be a concern. One-step approach won't have problem either.

[Haipeng] RFC3095 only discussed two-step downward transition, " Only
when decompression of several packets sent in the FO state fails in the
"Static Context" state will the decompressor go all the way back to the
"No Context" state.". I don't see much problem allowing transition back
from FC to NC, but it would be great if there are some general
guidelines on what might be the criteria for the decompressor to
determine whether to go from FC to IC or from FC to NC. Do you have some
scenarios in mind?

[Haipeng] I would be careful in saying that tunneled packets belong to a
very small subset. MIP is a mobility management mechanism that is used
widely. Tunnel packets with two levels of headers are common if CCoA
mode of operation is used and it is important for ROHC to handle them
efficiently.

[Haipeng] In addition, the text in the expired requirements draft says
that it is unrealistic that the outer IP-ID can be compressed
sequentially. This is not true either. There are actually
implementations where the tunneling endpoints set outer IP-ID to the
same as inner IP-ID sequentially to allow efficient compression using
3095. If the same stacks are used for updated profile, the IP-ID will
not be compressed efficiently.

Best Regards,
Haipeng

BR,
   Kristofer

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Tue, 19 Jun 2007 08:16:34 +0200

Rohit,

you are right, there is probably some text missing from section 6 which
makes some normative statements about this, it must have fallen out of
the draft at some point :)
If we stick with the two-step approach for the next revision, I think
we should fix that. Thanks for pointing it out.
See also separate mail about the states which I will send in a couple
of minutes time.

/Kristofer

Kapoor, Rohit <mailto:[email-masked]> wrote on den 15 juni 2007
15:52 :

> Since Section 5 is informative, I am assuming that the
> decompressor state transition (i.e., NC -> IC -> FC) is also
> informative. Also, there is no requirement on the compressor
> to send packets according to this transition of the decompressor.
> 
> As an example, say the decompressor implemements a 2-state
> transition as above. Say, the compressor sends a few IRs
> followed by a UO-0. The IRs will cause the decompressor to
> transition from NC to IC, but the UO-O will be received when
> the decompressor is in IC, and will cause a failure.
> 
> If most decompressor implementations follow the recommended
> 2-step state transition diagram but there is no requirement
> (or recommendation) on the compressor to send a CRC-7 packet
> after sending IRs, isn't this broken?
> 
> Thanks,
> Rohit

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Tue, 19 Jun 2007 08:48:31 +0200

Hi Haipeng,

thanks for the feedback, more comments inline.

Jin, Haipeng <mailto:[email-masked]> wrote on den 19 juni 2007
03:10 :

>> CRC-7 packet such as co-common or p0-crc7 is needed as an
>> intermediate step. Now that IR-DYN is removed, I would propose to
>> change the stage diagram to allow direct transition from NC to FC
>> with CRC-8 verification.
> 
> fields etc, but I think that's going to be a lot more "patch-work"
> (and more overhead) than having a 2-step transition which is simple.
> And the cost
> option, unfortunately.

When I read up on the old discussions we had on this, I found my old
email from last year
http://www1.ietf.org/mail-archive/web/rohc/current/msg04569.html 
which proposed alternatives for how to handle IR and state transitions,
and the only reply I got on that was from Lars-Erik who supported the
two-step approach which is why this draft version still uses the
two-step
logic.

Could you check that one and give your opinions?

Btw, you're absolutely right that the IR CRC-8 coverage is 
profile-dependent.
I don't know where I got the other idea from, so that possibility is
also listed in the referenced mail above :)

> text can be enhanced to capture all the conditions.

Yes, as Rohit pointed out, there is something missing here w.r.t. the
two-step transition. I'm not exactly sure on what's the best way to
fix this, but probably add some normative rules in section 6.

>> 5.3.1.3, the text says "The decompressor moves back to the IC state
>> if it assumes context damage, and back to the NC state if it
>> assumes static

I prefer to leave it up to the decompressor to drop back to NC state
whenever it wants to, as long it has reason to suspect that it might
have lost synch of the static context. For example, if the decompressor
receives an IR packet with a bad CRC-8 followed by a CRC-3 packet,
it might guess that it doesn't have sufficient static context and drop
directly to NC.
I'm not saying it should do that always, but since all the downwards
transitions have to be based on some form of guessing by the
decompressor,
I think it is fine for the spec to say that it may be extra conservative
if it wants to.
But like I said, I can agree to either of the solutions.

Regarding more guidelines, do you think that section 5.3.2 is
insufficient
(we refer to that from the picture w.r.t. transitions)?
I think that has quite good guidelines for how to detect context damage,
but if you think it is insufficient, please give a text proposals that
we can discuss further.

>> compress the packet as efficiently as in RFC3095. It would be great
>> if you can add an sequential indicator for the outer header to
>> handle at least this case.
> 

Sure, there are tunnels that use such a mechanism, but however you cut
it,
tunneled packets are a subset of all packets, and tunnels with the
behavior
you describe are a subset of tunnels which means this is a minority
of packets that are affected. And the cost of 0-2 bytes in those cases 
seems small enough to avoid trying to optimize.

The outer-IPID mechanism of 3095 has really been despised by
implementers
due to its strange and over-complex logic and it would require quite a
large change in the current v2 packet formats to get that back.

So I think you will need very strong motivations to get that change into
the spec, especially with previous WG consensus of not doing this (also,
ROHC-TCP already follows the IPID logic used in v2). 

/Kristofer

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 20 Jun 2007 08:50:28 +0200

Hi Kristofer, Ghyslain,

I found a small issue in the feedback section. copy-and-paste? I believe a more
detailed description of the msn decompression in the feedback packet would improve
the draft.

Section 6.9.2.1:
	"carrying a REJECT option MUST also carry a CRC option."

There are no CRC options in ROCHv2 and crc8 is always included in feedback-2 packets.

In Section 6.9.1, it would be nice with a more detailed description how the
compressor should decompress the msn in feedback packets. There are some more
places in the draft that describes the msn in feedback, but it does not cover the
details on how to decompress/compress the field other than that it is lsb-encoded.

Best regards,
Carl Knutsson