Subject: [rohc] Questions on ROHCv2 profile draft

From: "Jin, Haipeng" <[email-masked]>
Date: Wed, 4 Oct 2006 17:01:07 -0700

Hi, Ghyslain, Kristofer, and All,

I am reading the ROHCv2 profile draft
(draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt) and have the
following questions. Could you please help clarify?

1) Regarding the TTL/Hop and ToS/TC flags, it is not completely clear
how these indicate the presence of irregular chains. My understanding is
that the ttl_hopl_outer_flag and the tos_tc_outer_flag are set if these
fields change in *any* of the outer headers. If this is so, then it
would help to make this more explicit in the text.
 
2) For IP-ID, the offset value in packets is currently set to 3 in all
packets that carry IP-ID LSBs. Is there any particular reason to choose
3 as the value? Similarly, for scaled TS compressed using LSB method,
the offset value is fixed and explicitly stated in each compressed
format, any particular reason for this design? Does it make sense to
also tie the offset value for IP-ID and TS with the re-order setting? If
yes, it might be better to define encoding methods similar to msn_lsb to
handle all the cases.
 
3) Is there a reason to have the packet type, pt_0_crc7, in RTP profile
particularly since there is no R-mode in v2 profiles?

4) Why use the term "Initial Context (IC)" instead of "Static Context
(SC)" as in RFC3095, the name SC seems more informative?

5) Page 54, in UDP header format udp_with_checksum_irregular, should it
be "ENFORCE(checksum.UVALUE != 0)" instead of "ENFORCE(checksum.UVALUE
== 1)"? checksum is the actual field, it is not a flag.

Best Regards,
Haipeng

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 5 Oct 2006 08:30:07 +0200

Hi Haipeng,

comments inline.

> would help to make this more explicit in the text.

Yes that's the idea, and we'll look at clearing this up for the next revision. We've already mde this more clear in the upcoming ROHC-TCP draft (which we probably will submit in a days time or so), and since v2 uses the same logic, we can probably just take text from there.

> yes, it might be better to define encoding methods similar to

Since the IP-ID & TS are encoded based on the MSN and the MSN handles reordering, there is no need for the IP-ID to explicitly do this in the same way as the MSN itself, so I'm quite sure this minor offset used will be sufficient.

> particularly since there is no R-mode in v2 profiles?

This packet is not meant for R-mode like behavior. If you look at the state machine in 5.3.1, you see that we have changed so that we have the new IC state, and we do not leave this until we have received a 7-bit CRC packet. In v1, you went directly from NC state up to FC state on successful decompression, while now, we only move to IC state. We feel that this logic will protect the context from decompression errors a lot better, but we still want to allow for an efficient transition from IC to FC state, and that's why we want a very small CRC-7 packet, which is the pt_0_crc7. 

> (SC)" as in RFC3095, the name SC seems more informative?

See explanation above. Mostly because you're not allowed to go directly from NC to FC any longer. IC state can mean that the context is believed to be valid (but you don 't have that strong confidence), while SC did not mean this.

> == 1)"? checksum is the actual field, it is not a flag.

Correct, I will fix that for the next revision.

Thanks for your comments, it is very helpful for us to get this type of reviews!

/Kristofer

---

From: "Jin, Haipeng" <[email-masked]>
Date: Thu, 5 Oct 2006 13:29:51 -0700

Hi, Kristofer,

Thanks for the clarification, please see more comments in line. I
snipped the part where I don't have any further doubts.

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]] 
Sent: Wednesday, October 04, 2006 11:30 PM
To: Jin, Haipeng; [email-masked]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: [rohc] RE: Questions on ROHCv2 profile draft
(snip ...)

> particularly since there is no R-mode in v2 profiles?

This packet is not meant for R-mode like behavior. If you look at the
state machine in 5.3.1, you see that we have changed so that we have the
new IC state, and we do not leave this until we have received a 7-bit
CRC packet. In v1, you went directly from NC state up to FC state on
successful decompression, while now, we only move to IC state. We feel
that this logic will protect the context from decompression errors a lot
better, but we still want to allow for an efficient transition from IC
to FC state, and that's why we want a very small CRC-7 packet, which is
the pt_0_crc7. 

[Haipeng] This is the part I don't fully understand. Do you have any
specific scenarios in mind that this transition logic (in combination
with pt_0_crc7) will help to improve? it seems to me co_common is more
likely to be used in this transition. For example, at initial context
setup, a number of IRs might be followed by one or more co_common to
establish the flags and control fields; in decompression error case,
co_common is also likely to be the one for updating contexts.

> (SC)" as in RFC3095, the name SC seems more informative?

See explanation above. Mostly because you're not allowed to go directly
from NC to FC any longer. IC state can mean that the context is believed
to be valid (but you don 't have that strong confidence), while SC did
not mean this.

[Haipeng] Well, this may be true when the context is first established.
But when decompression error happens in FC state, the decompressor
transits back to this lower state with the assumption that something is
wrong in the context (as also indicated in the current state diagram)
and the error is more likely to be in the dynamic part than the static
part of the context. SC still seems to be more appropriate than IC.

(snip ...)

Thanks,
Haipeng

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Fri, 6 Oct 2006 08:36:38 +0200

Hi,

comments inline.

On Thursday, October 05, 2006 10:30 PM, Jin, Haipeng wrote:

> Subject: [rohc] RE: Questions on ROHCv2 profile draft (snip ...)
> 
>> 
>> 3) Is there a reason to have the packet type, pt_0_crc7, in RTP
>> profile particularly since there is no R-mode in v2 profiles?
>> 
> 

Which packet type is used after IR is pretty dependent on both traffic 
and on how you implement your compressor, so I wouldn't say that you
will always go for co_common in this transition. There's nothing
stopping you from guessing the control fields already at the first
IR packet, and ion many situations you can be pretty accurate on
these guesses. In such a case, you wouldn't need to send a co_common
after the IRs, you could immediately start sending pt_0 packets.

Also, we want to avoid the case where you NACK and reply with an IR-DYN
and immediately move back to FC state, since the IR-DYN uses an 8-bit
CRC which does not verify the context, only the actual packet itself.
This is a bit risky in case you have corruption on something
not covered by the 8-bit CRC (e.g. the static fields or
control fields that might not be present in the IR-DYN).
So, if you recover with an IR-DYN, you should send pt0_crc7 after this
to make sure that your repair was successful before you start sending
CRC-3 packets again.
With 3095-logic, there are some nasty corner cases that can cause
huge problems, so we really want to close the door on those with v2.

> to be valid (but you don 't have that strong confidence), while SC
> did not mean this. 
> 
> [Haipeng] Well, this may be true when the context is first
> established. But when decompression error happens in FC state, the
> decompressor transits back to this lower state with the assumption
> that 
> something is

See the IR-DYN repair case above for one example, we feel that a
repair should always be verified with a CRC-7, and not only with CRC-8.

BR,
  Kristofer

---

From: "Jin, Haipeng" <[email-masked]>
Date: Mon, 9 Oct 2006 10:36:35 -0700

Hi, Kristofer,

More comments in line marked with [haipeng2].

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 11:37 PM
To: Jin, Haipeng; [email-masked]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: RE: [rohc] RE: Questions on ROHCv2 profile draft

Hi,

comments inline.

[haipeng2] In that case why not simply add a CRC7 to IR-DYN to verify
the context? I understand now the problem you are trying to solve here:
basically ensure robust transfer from IC to FC while at the same time
keep the overhead small by only sending a small 2B compressed header. If
overhead is not a problem (considering this type of transition only
happen rarely), one alternative to ensure robust is to send co_common
after IR or IR-DYN as I suggested in the previous message. If overhead
is really an issue here, then another alternative is to add an extra
byte to IR-DYN to include CRC-7 so that context update and verification
can be done with one packet. Either way, we can avoid the need to add a
packet type just for this transition.

[haipeng2] I understand the robust transition problem, but my point is
what does the "IC" state mean to the decompressor? My interpretation
under both the cases you and I talked about is that "IC" here means the
decompressor is more confident in its static context than dynamic
context even though both may be correct (or wrong). In this sense, "SC"
seems like a more appropriate name and it aligns with the understanding
people had while reading RFC3095.  But it is just a symbol/name anyway,
so if you like "IC" better, I wouldn't argue too much about it.

Best Regards,
Haipeng 

BR,
  Kristofer

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Tue, 10 Oct 2006 08:34:32 +0200

Hi Haipeng,

comments inline.

>> successful decompression, while now, we only move to IC state. We
>> feel that this logic will protect the context from decompression
>> errors a lot
>> better, but we still want to allow for an efficient transition from
>> IC to FC state, and that's why we want a very small CRC-7
>> packet, which is
>> the pt_0_crc7.
>> 
>> 
>> with pt_0_crc7) will help to improve? it seems to me co_common is
>> more likely to be used in this transition. For example, at initial
>> context setup, a number of IRs might be followed by one or more
>> co_common to establish the flags and control fields; in
>> decompression error case, co_common is also likely to be the one for
>> updating contexts. 
> 
> CRC-3 packets again. With 3095-logic, there are some nasty corner
> cases that can cause huge problems, so we really want to close the
> door on those with v2. 
> 
> byte to IR-DYN to include CRC-7 so that context update and
> verification can be done with one packet. Either way, we can avoid the
> need to add a

When we made the initial draft, we also discussed the alternative of 
adding an additional CRC7 to the IR-DYN (we must of course keep the 
CRC-8 that's already there since it is part of the framework), but we 
preferred to instead add this packet format so that we can enforce a 
"two-step transition". I also prefer to force sending of CRC-7 packets
even after an IR to really verify that things are ok before moving on 
to CRC-3 packets, but maybe that's just my paranoia, though :) 

Both of these are valid solutions to the problem, but could you
please try to motivate what's you issue with the pt_0_crc7 packet and
why you think the other solution is preferrable?

> 
>> 
>>> 4) Why use the term "Initial Context (IC)" instead of "Static
>>> Context (SC)" as in RFC3095, the name SC seems more informative?
>> 
>> that something is
>> and the error is more likely to be in the dynamic part than the
>> static part of the context. SC still seems to be more appropriate
>> than IC. 
> 
> seems like a more appropriate name and it aligns with the
> understanding people had while reading RFC3095.  But it is just a
> symbol/name anyway,

I think the renaming of the state is important just to make it clear 
to people that this is NOT the same transition logic as in 3095. If 
we change the transistion logic but keep the same name, I feel that 
it is much more likely that people will confuse things and not notice 
the difference. So, I don't really care if it should be called "IC"
or something else completely, but I think it is important that the name
is not the same as before now that the logic is changed.

BR,
   Kristofer

---

From: "Jin, Haipeng" <[email-masked]>
Date: Tue, 10 Oct 2006 10:15:50 -0700

Hi, Kristofer,

Please see comments inline with [haipeng3].

-----Original Message-----
Sent: Monday, October 09, 2006 11:35 PM

Hi Haipeng,

comments inline.

[Haipeng3] It seems an over kill to have one packet type just for that
transition :-) Anyway here come the more specific reasons:
1. In the IR-DYN + pt_0_crc7 two-step procedures, you are assuming that
IR-DYN may not update the entire context correctly and thus it is
necessary to use pt_0_crc7 to verify it later. However, this implies
that an error packet decompressed based on the IR-DYN will be passed to
the upper layer. Having CRC7 inside the IR-DYN will avoid this problem
while achieving the same verification purpose. On the other hand, if you
don't see this scenario possible, then there is no need to have
pt_0_crc7 either.
2. In designing co_common in V2, the principle seems to have one crc to
verify the decompression/context and one crc to verify the control
fields that are not verified by the first crc. I see no reason to apply
a different principle to IR-DYN packets. Why not just follow the same
principle throughout the V2 design?

Regards,
Haipeng

BR,
   Kristofer

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 15:00:24 +0200

Haipeng,

Comments inline.

///Ghyslain

> > [haipeng2] I understand the robust transition problem, but 
> > my point is what does the "IC" state mean to the decompressor? My 
> > interpretation under both the cases you and I talked about is 
> > that "IC" here means the decompressor is more confident in its
> > static context than dynamic context even though both may be
> > correct (or wrong). In this sense, "SC" seems like a more
> > appropriate name and it aligns with the understanding people
> > had while reading RFC3095.

I think that the important point here is that it does not matter in fact
what part of the context is wrong, or rather, it is not possible to
_know_ what went wrong and what in the context is faulty. One can only
guess. It is only possible to know what is right, when something is
right.

In this respect, the decompressor implements some sort of 2-level of
severity in its assumption of how much of a repair it needs, and it
starts with the least severe assumption. It is the compressor that has
the responsability to make up what it has sent, what possibly went wrong
and figure out what to send - if it chooses not to resend the entire
dynamic part of the context incl ctrl fields in the case of a NACK.

So I agree that we must take a step away from 3095 regarding this.

> I think the renaming of the state is important just to make 
> it clear to people that this is NOT the same transition logic 
> as in 3095. If we change the transistion logic but keep the 
> same name, I feel that it is much more likely that people 
> will confuse things and not notice the difference. So, I 
> don't really care if it should be called "IC"
> or something else completely, but I think it is important 
> that the name is not the same as before now that the logic is changed.
> 
> BR,
>    Kristofer
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 15:04:01 +0200

All,

Let's try to summarize some of the robustness features of RoHCv2, wrt to
the recent discussions about IC to FC state transition and to new
requirements posed by the possibility to have reordering between
compression endpoints.

Those interested in this discussion should not necessarily answer to
this mail (I want to use it as a reference, not as a discussion object)
and instead answer the next mail I will send in the discussion.

Some background first:
======================
Keep the following guidelines in mind:
1) reordering increases the requirements on robustness
2) under the _same_ operating assumptions as RFC3095,
  compression efficiency should be at least equivalent

>From this, we've:
o added a CRC3 over control fields
o used a new philosophy wrt compressor confidence of the
  decompressor state
O created a new small packet type (pt_0_crc7).

IC (Initial Context)
====================
RFC3095 uses IR/SC/FC decompressor states. This logic is based on what
_part_ of the context is assumed valid (i.e. NONE, STATIC or FULL). IR,
IR-DYN and UOR-2* allow a direct transition to FC state (while in fact
the logic should be based on if the context is initialized or not, needs
validation or not, or is valid or not and what type of packets can be
decompressed in each case)

So, in other words the philosophy in 3095 is based on the confidence wrt
what part of the context the decompressor has received, not on what part
of the context it has validated (based on decompression of specific
packet types) before it can decompress the smallest packet types.

o Proposed increased robustness in RoHCv2:
------------------------------------------
In RoHCv2, the philosophy wrt robustness and what packets may be
decompressed is based on a confidence about the _validity_ of the
_entire_ context (not parts of the context as in 3095), not only on the
assumption that some of the information was properly received as in
3095.

We wanted to make the transition towards FC as robust as possible, so
we've made it a two-step process were the requirement is that the
context be validated at least once with a CRC7 packet before
decompressing CRC3 packets. This is the safest approach we've found for
addressing 1) above.

In RoHCv2, the context is either:
o invalid/uninitialized (NC)
o in some initial state where it is believed to be valid
  as information was received correctly (CRC8) but hasn't
  been used for decompression yet (no CRC-7 verification) OR
  has previously been CRC-7 verified but now in need of a
  repair from a failure of at least one CRC of any type (IC)
o entirely valid and suitable to decompress any packet type
  (CRC-7 verified) (FC).

We feel that this removes many (if not all) of the ugly corner cases
that 3095 did not address.

Namely, the condition that allows the decompressor to attempt
decompression of the smallest packet types is that the entire context,
including control fields (_and_ their use for decompression), is first
verified. This corresponds to the transition from IC to FC state in the
draft.

o Problem addressed:
--------------------
IR-DYN headers carry optional fields and do not verify decompression and
the entire context. ACK(IR-DYN) is unclear in what gets ACKed.

We wanted to avoid this.

This can be solved by:
- making all fields mandatory in the IR-DYN (to avoid unsuccessful
  repairs due to an optional field not in the IR-DYN header while
  it needed an update itself), and by adding a CRC7 over the
  uncompressed header.
- making the transition from IC to FC more robust and requiring
  the decompression of a CRC7 header, together with a new small
  CRC7 header type (pt_0_crc7). 

We've chosen the second option.

o Problem addressed (from 3095):
--------------------------------
UOR-2-EXT3 updates control fields without CRC protection.
ACK(UOR-2-EXT3) validates the update of the control field(s), but these
aren't verified.

We wanted to avoid this too.

We've chosen to add a CRC3 over the control fields in the UOR-2-EXT3
replacement.

o Problem addressed (from 3095):
--------------------------------
IR-DYN can be used to repair a context, but it carries optional fields
and it does not verify the context.

We wanted to avoid the IR-DYN to be used to make+validate a context
repair at once (co_common is more suited).

We've chosen to restrict IR-DYN to the IC state looping there until a
CRC7 is received and successfully decompressed.

Purpose of CRC3 over control fields
===================================
Protect updating of control fields against residual bit errors.

A 3-bit CRC is used to validate all the control fields that are updated
in co_common. This only guarantees that the information was received
properly, not that it was used sucessfully when decompressing, as
normally a header that carry control fields may not use these fields
when decompressed. Failure to verify this CRC is interpreted by the
decompressor as a decompression failure. Used in combination with the
requirements for the transition from IC to FC state, this makes the
updating of control fields more robust. 

///Ghyslain

> From: Jin, Haipeng [mailto:[email-masked]] 
> Sent: den 10 oktober 2006 19:16
> To: Kristofer Sandlund (LU/EAB); [email-masked]
> >> state machine in 5.3.1, you see that we have changed so 
> that we have 
> >> the new IC state, and we do not leave this until we have 
> received a 
> >> 7-bit CRC packet. In v1, you went directly from NC state up to FC 
> >> state on successful decompression, while now, we only move to IC 
> >> state. We feel that this logic will protect the context from 
> >> decompression errors a lot better, but we still want to 
> allow for an 
> >> efficient transition from IC to FC state, and that's why we want a 
> >> very small CRC-7 packet, which is the pt_0_crc7.
> >> 
> >> 
> decompression 
> >> error case, co_common is also likely to be the one for updating 
> >> contexts.
> > 
> > stopping you from guessing the control fields already at 
> the first IR 
> > packet, and ion many situations you can be pretty accurate on these 
> > guesses. In such a case, you wouldn't need to send a 
> co_common after 
> > the IRs, you could immediately start sending pt_0 packets.
> > 
> > Also, we want to avoid the case where you NACK and reply with an 
> > IR-DYN and immediately move back to FC state, since the 
> IR-DYN uses an 
> > 8-bit CRC which does not verify the context, only the actual packet 
> > itself.
> > This is a bit risky in case you have corruption on something not 
> > covered by the 8-bit CRC (e.g. the static fields or control fields 
> > that might not be present in the IR-DYN).
> > keep the overhead small by only sending a small 2B 
> compressed header. 
> > If overhead is not a problem (considering this type of 
> transition only 
> > need to add a packet type just for this transition.
> 
> When we made the initial draft, we also discussed the 
> alternative of adding an additional CRC7 to the IR-DYN (we 
> must of course keep the
> CRC-8 that's already there since it is part of the 
> framework), but we preferred to instead add this packet 
> format so that we can enforce a "two-step transition". I also 
> prefer to force sending of CRC-7 packets even after an IR to 
> really verify that things are ok before moving on to CRC-3 
> packets, but maybe that's just my paranoia, though :) 
> 
> Both of these are valid solutions to the problem, but could 
> you please try to motivate what's you issue with the 
> pt_0_crc7 packet and why you think the other solution is preferrable?
> 
> 
> [Haipeng3] It seems an over kill to have one packet type just 
> for that transition :-) Anyway here come the more specific reasons:
> 1. In the IR-DYN + pt_0_crc7 two-step procedures, you are 
> assuming that IR-DYN may not update the entire context 
> correctly and thus it is necessary to use pt_0_crc7 to verify 
> it later. However, this implies that an error packet 
> decompressed based on the IR-DYN will be passed to the upper 
> layer. Having CRC7 inside the IR-DYN will avoid this problem 
> while achieving the same verification purpose. On the other 
> hand, if you don't see this scenario possible, then there is 
> no need to have
> pt_0_crc7 either.
> 2. In designing co_common in V2, the principle seems to have 
> one crc to verify the decompression/context and one crc to 
> verify the control fields that are not verified by the first 
> crc. I see no reason to apply a different principle to IR-DYN 
> packets. Why not just follow the same principle throughout 
> the V2 design?
> 
> Regards,
> Haipeng
> 
> > 
> >> 
> >> See explanation above. Mostly because you're not allowed to go 
> >> directly from NC to FC any longer. IC state can mean that 
> the context 
> >> is believed to be valid (but you don 't have that strong 
> confidence), 
> >> while SC did not mean this.
> >> 
> >> that something is wrong in the context (as also indicated in the 
> >> current state diagram) and the error is more likely to be in the 
> >> dynamic part than the static part of the context. SC still 
> seems to 
> >> be more appropriate than IC.
> > 
> my point is 
> > under both the cases you and I talked about is that "IC" here means 
> > the decompressor is more confident in its static context 
> than dynamic 
> > symbol/name anyway, so if you like "IC" better, I wouldn't 
> argue too 
> > much about it.
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 15:04:19 +0200

All,

Let me summarize the purpose of pt_0_crc7, as it is not in fact only
related to the current discussion about IC to FC state transition.

///Ghyslain

Purposes of pt_0_crc7
=====================
Purpose 1:
----------
Efficient transition from IC to FC with a small CRC7 protected header.

By introducing the above condition for the decompressor to enter the FC
state by the IC state, and thus to start decompressing headers with a
3-bit CRC with the entire context + control fields verified, there were
alternatives:

a) use co_common or pt2. This would somewhat against 2) above,
   as 3095 allows a 1 octet header to be decompressed already
   after an IR/IR-DYN
b) add a CRC7 to IR-DYNs, in addition to the already existing
   CRC8. Possibly a CRC3 would be needed as well. This would
   go against 2) somewhat, although it would be marginal.
c) create a new packet type similar to pt0 but with a CRC7.

We've chosen c) because the combination of the condition to leave IC
state with the very small pt_0_crc7 packet type in particular will
protect the context from decompression errors in the most robust manner
while still allowing that transition to be efficient. co_common is
always an alternative otherwise when pt0-crc7 is not possible (e.g. ctrl
fields need to be updated).

Purpose 2:
----------
Efficient and more robust 3095-pt-0 replacement for high-reordering/loss
rates.

In some situations such as if the amount reordering is known to be high
(e.g. from the reordering ratio used), it may be desirable to have a
packet that can be more robust, using a CRC7, while still be spectrally
efficient. Or simply to lower the probability that a crc3 succeeds where
it shouldn't. pt0 or pt1 cannot serve this purpose as they have CRC3.
pt2 and co_common are too large for this.

Purpose 3:
----------
Robustly shorten OA repetitions when ooo delivery and high reordering
depth possible.

The pt_0_crc7 can be used to make the OA repetitions shorter when the
reordering depth is quite large, and replace e.g. a fraction of the OA
repetitions while still providing reliable detection of faulty
decompression.

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 15:05:06 +0200

Haipeng,

Thanks for your comments, much appreciated.
I think that this is an interesting discussion. 

Summarizing the discussion so far, it seems that there are agreements on
the following:
- IR-DYN is generally problematic when it only has a CRC8.
- HD state transitions need to be more robust than in RFC3095
- ctrl fields (and the entire context) should be verified
  before allowing HD to FC state

Some further observations:
- although the pt_0_crc7 can be used for the transition
  from IC to FC, its existence does not have much to do
  with this state transition in fact (see other mail on RoHCv2
  robustness also sent today)
- IR-DYN is not suitable for a repair (not clear from RFC3095);
  co_common is more useful because it carries the same
  information AND has a CRC7 that verifies decompression
- IR-DYN's existence in RFC3095 is solely motivated by
  the "profile downgrade" "feature"

Some wishes heard in the discussion:
- allow transition NC->FC directly for IR
- allow transition IC->FC directly for IR-DYN

The two-step approach currently in RoHCv2 mainly aims to solve the issue
about IR-DYN not being suited (read - robust) for the transition IC->FC.
It also locks IR to the two-step approach, as IR also has some drawbacks
with respect to this transition, although much easier to fix (much on
this below).

We've chosen the two-step approach among a number of alternatives. The
reason was to keep the "profile downgrade" functionality (but we're open
to debate that function).

Note that alternatives below may be independently applied to IR and/or
IR-DYN unless stated otherwise.

Problems addressed:
===================
o IR and IR-DYN headers carry optional fields.
o IR-DYN does not verify decompression or the entire context.
o ACK(IR-DYN) is unclear in what gets ACKed with respect to static
  fields and ctrl fields that were not part of the header.
o ACK(IR) is unclear in what gets ACKed wrt to ctrl fields
  that were not part of the header.

Considerations of the solution:
===============================
o must be more robust than in 3095 (reordering)
o should allow efficient transition to FC state

Possible alternatives:
======================
1) two-step approach
2) remove IR-DYN (not possible for IR, of course)
3) CRC3 over ctrl fields context values
4a) CRC7 and update all optional fields always (IR-DYN only)
4b) update all optional fields always (IR only)

Alternative 1: Two-step approach
============================================================
As in current draft.

Pros: very robust against any error case (packet losses,
      reordering AND residual bit errors),
      removes corner-cases due to IR-DYN.
Cons: 1 octet more than 3095 to move from IC->FC with
      pt_0_crc7?

Note: the two-step approach can be applied to IR and/or
IR-DYN independently of each other. 

Alternative 2: Don't use IR-DYN in RoHCv2
============================================================
IR-DYN exists only because of the profile downgrade feature.
Profile reuse is not a key feature of RoHC: good flow
classification and the use of IR header when profiles
need to be changed may very well be sufficient. 

Pros: IR-DYN and associated problems disappears
      (IR-DYN would not be used in RoHCv2)
Cons: Only if some thinks profile downgrade is useful in
      practice and worth the (implementation) effort

Alternative 3: Add CRC3 over ctrl fields context values
============================================================
A CRC3 covering the values of ctrl fields in the context
can be added to the IR and/or the IR-DYN format. As a value
may not be available from the first packet in the flow,
default initial values would have to be specified. In
addition, CRC failure logic need to be augmented, e.g.
failure for this CRC triggers context damage but the
packet may be decompressed ok (ctrl fields aren't used
for decompressing IR/IR-DYN).

The presence of ctrl fields would still be optional in the
IR/IR-DYN header format.

Pros: Solves robustness issues for IR (transition NC->FC ok)
     
Cons: Does not solve all robustness issues with IR-DYN
      One more CRC in IR/IR-DYN format
      Compressor logic for received feedback even less clear

Alternative 4: Add CRC7 (IR-DYN), update all optional fields
============================================================
All optional fields get updated, present (from the value in
the header) or not (from a default value) in the format.
The CRC8 protects what is sent, and what's not sent gets a
clear value. This ensures that ctrl fields don't get
corrupted by e.g. residual bit errors.

For IR-DYN, a CRC7 would be necessary to also verify the
decompression (e.g. to cover for the static fields)

Pros: Solves robustness issues for IR (transition NC->FC ok)
      Solves robustness issues for IR-DYN (IC->FC ok)

Cons: One more CRC in IR-DYN format
      More overhead when default values are not matching the
      characteristics of the flow.
      May impact e.g. unidirectional operation.

Conclusion
==========
Possible solutions ...

o Solution 1:
-------------
Current 2-step approach (alternative 1 above).

Possibly combine with alternative 3 above with a CRC3 or with
alternative 4b above for the IR, to allow transition NC->FC for IR. But
no changes to IR-DYN, keep it locked to the 2-step approach. We believe
that the advantage of additional robustness of the two-step approach is
worth it, and certainly for IR-DYN.

o Solution 2:
-------------
Remove IR-DYN (alternative 2 above).
Use alternative 4b above for IR (or alternative 3 with a CRC3)
Change "IC" state to "Repair Context (RC)" state.
Use the following state machine:

                            CRC-8 Validation
                   +-->---->---->---->---->---->---->--+  CRC-8(IR)
                   |                     CRC-8(IR)     |  Validation
                   |                     Validation    |  CRC-7(CO) or
    CRC-8(IR)      |                     CRC-7(CO)     |  CRC-3(CO)
    Failure        |                     Verification  |  Verification
    +--->---+      |                     +-->---->--+  |  +-->---->--+
    |       |      |                     |          |  |  |          |
    |       v      |                     |          v  v  |          v
   +-----------------+  +----------------------+  +-------------------+
   | No Context (NC) |  | Repair Context (RC)  |  | Full Context (FC) |
   +-----------------+  +----------------------+  +-------------------+
       ^                 | ^ CRC-7(CO)      | ^                 |
       | Static Context  | | Failure or     | | Context Damage  |
       | Damage Detected | | PT not allowed | | Detected        |
       +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+
   where:
      CRC-8(IR) validation: successful CRC-8 validation for the IR
      header.
      CRC-7(CO) and/or CRC-3(CO) verification: successful CRC
      verification for the CO header, based on the number of CRC bits
      carried in the CO header.
      CRC-7(CO) failure: failure to CRC verify the decompression of a CO
      header carrying a 7-bit CRC.
      PT not allowed: the decompressor has received a packet type (PT)
      for which the decopressor's current context does not provide
      enough valid state information for that packet to be decompressed.
      Static Context Damaged Detected: see definition in Section 5.3.2.
      Context Damage Detected: see definition in Section 5.3.2.

o Solution 3:
-------------
Alternative 4 above, for IR and IR-DYN.
We're somewhat concerned by the cons of this alternative.

Comments?

Best regards,

///Ghyslain

---

From: "Jin, Haipeng" <[email-masked]>
Date: Wed, 11 Oct 2006 18:30:12 -0700

Hi, Ghyslain,

Thanks very much for your extensive summary on the related topics.
Please see more comments in line with [haipeng4].

Best Regards,
Haipeng
-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 6:05 AM
To: Jin, Haipeng; Kristofer Sandlund (LU/EAB); [email-masked]
Subject: RE: [rohc] RE: Questions on ROHCv2 profile draft

Haipeng,

[Haipeng4] but the state transition logic is one of the main reasons
that you listed as why pt_0_crc7 is added. 

[Haipeng4] agree unless another crc7 is added as I suggested in previous
emails.

[Haipeng4] Could you please elaborate a little more about the IR
drawbacks? The main point listed in your message below is that IR
carries optional fields. I am still not convinced that is a problem. The
point I want to stress is that the robustness of ROHC really depends on
both HC (header compressor) and HD (header decompressor), and maybe more
on HC than HD. It does not matter how many steps we have in the HD state
transition logic, if the HC does not send enough context information or
updates, the decompression will fail anyway. To improve robustness, it
might make more sense to look at HC instead of HD. 

Problems addressed:
===================

Possible alternatives:
======================
1) two-step approach

[Haipeng4] It is actually one packet later than 3095 and one new packet
type more than 3095. As I pointed out in the previous message, the same
robustness can be achieved in one step by adding the extra byte to
IR-DYN or simply use co_common (already have the crc7).

[Haipeng4] I am fine with not using IR-DYN in RoHCv2 but would be
interested to see whether anyone relies on this packet type for the
downgrade function. Note that this discussion may also affect the last
call currently going for the ROHCv2 framework.

[Haipeng4] The motivation for this extra crc3 is vague to me. My
understanding is we need two CRCs at most in each packet, one is to
verify that the control fields sent but not used for the current
decompression are correct (e.g. crc8 in IR-DYN or CRC3 in co_common);
the other is used to verify that the decompression is correct (e.g. crc7
in co_common). The success of decompression also indirectly verifies
that context is correct. The extra crc3 does not add any value here.
Introducing it actually causes more problems, for example, it would need
to be added in all context update and verify packets including IR,
IR-DYN, co_common since none of these packets sends the entire context. 

[Haipeng4] As stated above, the control fields are already indirectly
verified by the decompression.  

[Haipeng4] similar to the comments above, it is not clear why we always
need to update all optional fields. co_common has options to update only
some of the control fields. If co_common works fine, then why wouldn't
IR-DYN with the extra CRC7 work? 

Conclusion
==========
Possible solutions ...

o Solution 1:
-------------

o Solution 2:
-------------

[Haipeng4] As stated above, the need for 2-step is really eliminated if
CRC7 is added to co_common and IR-DYN (or simply remove IR-DYN).   
[Haipeng4] If transition from NC or IC(RC) to FC based on IR is not
desired, we can also consider another solution which is similar to
solution 2 but with the following changes:
1. no NC -> FC transit, instead NC -> IC(RC)
2. transition from IC(RC) to FC is based on CRC7, which can be provided
by either co_common or IR-DYN with CRC7.

                            CRC-8 Validation

o Solution 3:
-------------
Alternative 4 above, for IR and IR-DYN.
We're somewhat concerned by the cons of this alternative.
[Haipeng4] This is similar to solution 2. Could you please explain more
about the extra overhead problem? Regardless of whether the CRC7 is
added or not, if the characteristics do not match, then the HC can send
T1 or T2 packets. If T1/T2 is not enough, then co_common can be used
which will contain CRC7 anyway. If co_common is not enough, then IR or
IR-DYN needs to be sent anyway, what difference does an extra byte make
if the header is already more than 20 bytes?

Comments?

Best regards,

///Ghyslain

---

From: "Jin, Haipeng" <[email-masked]>
Date: Wed, 11 Oct 2006 21:34:10 -0700

Hi, Ghyslain and all,

Please see my comments in line.

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 6:04 AM
To: Jin, Haipeng; Kristofer Sandlund (LU/EAB); [email-masked]
Subject: Purpose of pt_0_crc7

All,

///Ghyslain

Purposes of pt_0_crc7
=====================
Purpose 1:
----------

[Haipeng] I'm not sure that (c) is always the most robust option. In
fact, if in (c), an IR-DYN packet is sent and the IR-DYN is decompressed
incorrectly, it will mean that one erroneous packet is passed up to the
application, and only the next pt_0_crc7 packet will catch this. In
cases (a) and (b), on the other hand, since IR-DYN (assuming we add
crc7) and co_common have CRC7, no erroneous packet passes decompression.
With the extra crc7, a) is not exactly equivalent to 3095. It is
actually more robust.

Purpose 2:
----------

[Haipeng] If reordering is expected, systems will typically set the
reordering parameter so as to handle a high percentage of cases. From
our experience with 3GPP2 systems, if we set the appropriate reordering
value in RoHC, the chances of packets having higher reordering than the
expected range is 10^(-5) or even lesser (and erroneous decompression
for crc3 would be 1/8th of this). Given that air-links typically have
error rates of 10^(-2), the gain of detecting erroneous decompression
"faster" with crc7 in such very small percentage cases is insignificant.
For 3gpp system, the same applies.

[Haipeng] Also, pt_0_crc7 packet only helps in detecting "bad"
decompression faster, and the detection process maybe 1 or 2 packets
faster than a CRC3. The probability difference is about 1/10 on top of
the already very small residual error probability. Having this
functionality for such an insignificant fraction of packets is overkill,
in my opinion. On the other hand, if a system is having a very high
amount of reordering (greater than what Type0 or Type1 can handle) for a
high % of packets, then most robust option is just to use Type 2
packets.

Purpose 3:
----------

The pt_0_crc7 can be used to make the OA repetitions shorter when the
reordering depth is quite large, and replace e.g. a fraction of the OA
repetitions while still providing reliable detection of faulty
decompression. 
[Haipeng] Not sure I completely follow this. The compressor would
typically set the value of OA based upon the characteristics of "packet
drop run lengths". I'm not sure how a pt_0_crc7 helps if all OA
"updates" are dropped on the airlink. As I already mentioned in the
separate email thread, if robustness is needed, then we really need to
make sure that the compressor sends enough repetition of the updates.
Using crc7 does not help to shorten the OA length, it just helps to
increase the error detection probability by a very marginal amount as
pointed out above.

Regards,
Haipeng

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 Oct 2006 13:46:32 +0200

Haipeng, all,

Thanks for your comments.

What I mainly wanted to bring forth with my previous mail:

o transition IC->FC (purpose 1) is not the only reason motivating
  the existence of pt_0_crc7.
o pt_0_crc7 provides 2 additional MSN bits (purpose 2).
  This is useful to increase the interpretation interval from
  16 packets to 64 packets to handle more losses and ooo depth,
  with stronger CRC protection against faulty decompression.
o considering it may be acceptable to discard errorneous packets
  when ensuring that no such packet are delivered to upper layer,
  an implementation may consider that it is suitable to lower the
  number of OA repetitions. This makes purpose 3 useful to reduce
  the costs of adjusting the OA for _both_ reordering _and_
  consecutive losses.
o IETF does not design for specific air interfaces using specific
  assumptions, i.e. the proposed solution is meant to be robust
  and efficient in any possible scenario, including links with
  residual errors; in such case a compressor could refrain from
  using compressed headers having only a 3-bit CRC over the
  uncompressed header to further improve robustness.

Finally, some notes on your answer:

> [Haipeng] Not sure I completely follow this. The compressor
> would typically set the value of OA based upon the
> characteristics of "packet drop run lengths". I'm not sure

When reordering is possible, the OA becomes must include _both_ an
estimate of the maximum consecutive losses _and_ of the maximum
reordering depth as well. This can be costly when this estimate is high,
so I expect most implementation not to (want to) follow this
recommendation by the letter and compress more aggressively. This packet
type allows a compressor to shorten the OA more robustly, as explained
in purpose 3.

Please read rfc4224 wrt OA considerations with ooo, especially from
section 6.1.1.1:

   For example, the number of repetitions for each context update can be
   increased.  The compressor should ensure that each update is repeated
   until it is reasonably confident that at least one change packet in
   the sequence of repetitions has reached the decompressor before the
   first packet sent after this sequence.

> If reordering is expected, systems will typically
> set the reordering parameter so as to handle a high
> percentage of cases.

There is no assumption of a correlation between the maximum amount of
consecutive losses and the maximum possible reordering depth when
considering the robustness ratio used. With pt0 having 4 bits of MSN,
the interpretation interval has room for 16 packets. When the ration is
set to a high value, PT-0 loses robustness against losses - and
vice-versa. The alternative is for the compressor to use a packet with
more MSN bits, in which case pt_0_crc has the benefit to be both small
and more robust with the CRC7.

> the gain of detecting erroneous decompression "faster" with
> crc7 in such very small percentage cases is insignificant.

What we are worried about here is the effect of header that update e.g.
semi-static fields, ctrl fields or dynamic functions when these would be
reordered in the middle of a PT-0 sequence that do not match these
updates. 

///Ghyslain

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 12 Oct 2006 14:05:03 +0200

Haipeng, Ghyslain and others,

Personally I want to keept the pt_0_crc7. Even if 3GPP and 3GPP2 links will handle
reordering, this may not be the case for all link layers and tunnels deploying
ROHC. I can see no harm in keeping the pt_0_crc7. A compressor doesn't have to use
this packet format over a 3GPP/3GPP2 link.

I would like to add that 6 bit msn is probably more important then the larger crc3
when avoiding decompression errors due to reordering or loss. It allows us to A
larger msn, makes lsb msn wraparound less probable. The larger crc7 will help to
detect msn lsb wraparound caused by reordering and loss, but it will also improve
to detection of bit errors.

If the decompressor uses some kind of local repair mechanism, the crc3 is more or
useless for verifying the context repair. It may be of some use if receiving some
kind information from the link layer (3GPP/3GPP2/?), but without such information
it is not good enough. That is probably why rfc3095 is not allowed to repair the
context and pass on packets until 3 packet have been successfully verified using
the crc[3,7].

Having this packet will enable the compressor to send all packets with crc7 over a
link and still get a decent compression efficiency during harsh link conditions.

/Calle

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 Oct 2006 14:59:30 +0200

Haipeng,

Comments inline. I've clipped away what I think we don't need anymore.

///Ghyslain

Jin, Haipeng wrote:

> [Haipeng4] Could you please elaborate a little more about the
> IR drawbacks? The main point listed in your message below is
> that IR carries optional fields. I am still not convinced
> that is a problem.

Protocol-wise it is _possible_ for an HC implementation to make a repair
without including the optional fields, and it _can_ do this forever.

This is because the HC cannot know from the feedback message what went
wrong _exactly_, while it has the responsibility to identify what
information is needed for the repair.

We want to avoid defining a protocol that leaves open such possibility,
and adding a CRC7 does not solve this.

> The point I want to stress is that the robustness of ROHC
> really depends on both HC (header compressor) and HD
> (header decompressor), and maybe more on HC than HD.

Robustness depends solely on the compressor.
The selection of proper packet format is key. 

> It does not matter how many steps we have in the
> HD state transition logic, if the HC does not send enough
> context information or updates, the decompression will fail
> anyway. To improve robustness, it might make more sense to
> look at HC instead of HD.

I disagree. Sender requirements are implicit to receiver specifications.

Defining requirements based on the receiver is common practice. As
impairment events may occur during transmission from sender to receiver
and change the information flow (losses, reordering, residual bit
errors) it makes little sense to specify sender behavior when it can be
avoided. Furthermore, there is a broader range of possible
implementations for a sender than for a receiver, thus it is simpler and
more efficient to specify receiver requirements.

Clear receiver requirements in turns specify sender's behavior, without
constraining the implementation details and creating overspecified
protocols with redundant text.

More specifically in this case, the two-step approach aims at ensuring
that the HC will ensure that no packets having only a CRC3 will reach
the HD before HC has sent the necessary information for the HD to CRC-7
verify at least one decompression. This is done by specifying that the
HD must not attempt decompression of CRC3-protected header without
having first successfully decompressed a CRC7 protected header.

(...)

> Cons: 1 octet more than 3095 to move from IC->FC with pt_0_crc7?
> 
> [Haipeng4] It is actually one packet later than 3095 and one
> new packet type more than 3095.

I disagree. The exact same sequence is possible, only the size of
pt_0_crc7 and UO-0 (1 octet) over the OA approach differ.

RoHCv2 has removed a huge number of packet types, considering extensions
in RFC3095 and R-mode packet types. So this is a rather weak argument
against having pt_0_crc7, especially considering the robustness gains
that 2 extra MSN bits and a 7-bit CRC brings with respect to increased
robustness requirements on ROHCv2.

> As I pointed out in the
> previous message, the same robustness can be achieved in one
> step by adding the extra byte to IR-DYN or simply use
> co_common (already have the crc7).

In what sense using IR-DYN with an additional CRC7 instead of pt_0_crc7
is more efficient? IR-DYN with a CRC7 is still not robust wrt optional
fields, so I would not claim the above and I don't see it as an
improvement or a better solution.

We also have to make the difference here between:
1) going from NC to FC using the two-step via IC:

   i.e. NC->IC->FC will e.g. use OA*IR + OA*pt_0_crc7
   I would not use IR-DYN here anyway (even with a CRC7).
   Would OA*IR not be enough, I'd use e.g. with OA=3:
   IR
   IR(opt_fields)
   IR(opt_fields)
   co_common(opt_fields)
   pt_0_crc7               
   pt_0_crc7
   pt_0_crc3 ...

2) repairs:
   i.e. from IC->FC, co_common should be used (4-5 octets + update).
   I would not use IR-DYN here ever (even with a CRC7).

> classification and the use of IR header when profiles need to
> be changed may very well be sufficient.
> 
> [Haipeng4] I am fine with not using IR-DYN in RoHCv2 but
> would be interested to see whether anyone relies on this
> packet type for the downgrade function.

The RoHCv2 profile work does not have any explicit requirement
about supporting profile downgrade using IR-DYN. But even if
it does and I am mistaking, I think its sound to discuss its
relevance to RoHCv2 profiles.

> Note that this
> discussion may also affect the last call currently going for
> the ROHCv2 framework.

Not at all, this has nothing to do with the RoHC framework.

The use of the IR-DYN packet type is profile-specific.
Common for all profile is the discriminator of the IR-DYN
format being reserved. Profiles may refrain from defining the
profile-specific part of the IR-DYN, in which case the IR-DYN
header is not used. For example, profile 0x0000 explicitely
does not define the IR-DYN format. 

Supporting profile downgrade is also profile specific, it must
be explicitely supported by the profile that is the target to
use the static part of a context that was associated with
another profile, using the IR-DYN. E.g. profile 0x0001 defines
downgrade from 0x0002.

Note: The framework described in 3095 and in the FW draft are
essentially identical, simply more clearly separated and
defined in the FW draft. In other words, RFC3095 profiles can
be used over the channel defined in the new draft, just like
RoHCv2 profiles can be used over the RoHC channel defined in
rfc3095.

> A CRC3 covering the values of ctrl fields in the context can
> be added to the IR and/or the IR-DYN format. As a value may
> not be available from the first packet in the flow, default
> initial values would have to be specified. In addition, CRC
> failure logic need to be augmented, e.g.
> failure for this CRC triggers context damage but the packet
> may be decompressed ok (ctrl fields aren't used for
> decompressing IR/IR-DYN).
> 
> [Haipeng4] The motivation for this extra crc3 is vague to me.
> My understanding is we need two CRCs at most in each packet,
> one is to verify that the control fields sent but not used
> for the current decompression are correct (e.g. crc8 in
> IR-DYN or CRC3 in co_common); the other is used to verify
> that the decompression is correct (e.g. crc7 in co_common).

> The success of decompression also indirectly verifies that
> context is correct.

Wrong. The success of the CRC7 verifies that the part of the
context that was _used_ to decompress the header is correct.

Specifically, for co_common, the control fields get updated
but are not (and will not be) used for the decompression of
the co_common header itself, hence the ctrl fields are not
verified by the CRC7.

This is the same for UOR-2-EXT3 in 3095 with e.g. TS_STRIDE.

> The extra crc3 does not add any value here.

The extra CRC3 protects the fields that are either optional
and/or not used in the decompression of a header that updates
their value, whether their value is present in the header or
not, by covering their value in the context.

Specifically wrt optional fields:
o CRC8 protects when the field is present in the header
o CRC7 protects only the decompression (i.e. ctx value used)
o CRC3 over optional field is as described above.

Clearly, CRC3 has value and makes things more robust.

> Introducing it actually causes more problems, for example, it
> would need to be added in all context update and verify
> packets including IR, IR-DYN, co_common since none of these
> packets sends the entire context.
> 
> [Haipeng4] As stated above, the control fields are already
> indirectly verified by the decompression.

Not always. See above.
 
(...)

> [Haipeng4] similar to the comments above, it is not clear why
> we always need to update all optional fields. co_common has
> options to update only some of the control fields. If
> co_common works fine, then why wouldn't IR-DYN with the extra
> CRC7 work?

Well, the co_common works fine because it has the CRC3.

CRC8 and CRC7 do not protect a ctrl field that is not
present in the IR-DYN header. See also above on CRC3.
 
(...)

> o Solution 2:

CRC7 is already in the co_common format.

Solution 2 as proposed as an alternative to what's in the current draft
already eliminates the two-step approach.

For this, IR and IR-DYN must be fixed:
o IR: optional fields must be protected/validated
o IR-DYN: same as IR + the static part must be protected/verified
  because of possible ooo. Or remove it.

> [Haipeng4] If transition from NC or IC(RC) to FC based on IR
> is not desired, we can also consider another solution which

I'm lost here, I thought you were after allowing the IR to move
from NC->FC???

> is similar to solution 2 but with the following changes:
> 1. no NC -> FC transit, instead NC -> IC(RC) 2. transition
> from IC(RC) to FC is based on CRC7, which can be provided by
> either co_common or IR-DYN with CRC7.

(...)

---

From: "Jin, Haipeng" <[email-masked]>
Date: Fri, 13 Oct 2006 19:33:04 -0700

Hi, Ghyslain,

If there are strong opinions thinking that pt_0_crc7 is useful, then I
can take it. As far as state transition is concerned, I still think that
whatever x + pt_0_crc7 does, the same can be achieved by adding a crc7
to the x packet if there is currently no crc7 in x. It does not matter
whether the x is co_common (which currently includes crc7) or some other
updating types. I agree that the extra MSN in crc7 might be helpful in
some cases.

About IR-DYN, I think removing it helps to make the spec simpler without
losing major functionality. So it might be worthwhile considering. When
you say that removing IR-DYN does not affect the framework, do you mean
that even though we are removing IR-DYN from the current profile draft,
it can still be kept in framework so that other profiles such as TCP can
make use of IR-DYN? 

About the IR drawback, I would appreciate it if you can give a realistic
example on when there could be a problem. Although protocol-wise it is
possible for an HC implementation to never include the optional fields,
I would not expect this to happen in reality. If the HC wants to be
robust and it is not sure what has gone wrong at the HD, then it would
include more information instead of including less. With that said, if
there is really concern about optional fields not being sent, then does
it make sense to extend the coverage of CRC8 to include those uncertain
control fields that are not sent? The crc8 covers control fields anyway.

Another minor comment about the control_crc3 currently defined in the
profile draft. Based on our discussion, it seems that the crc3 will
cover the control field even if they are not sent. could you please
clarify this in the next revision? The current text does not explicitly
state this assumption.

Thanks,
Haipeng

-----Original Message-----
Sent: Thursday, October 12, 2006 6:00 AM

Haipeng,

///Ghyslain

(...)

2) repairs:

Not always. See above.
 
(...)

 
(...)

(...)

---

From: [email-masked]
Date: Mon, 16 Oct 2006 10:24:37 +0200

Hi Haipeng,

Thanks for your answer.
Comments inline.

///Ghyslain

> updating types. I agree that the extra MSN in crc7 might be helpful in

Ok. Our recent as Kristofer sent last week is to remove the IR-DYN and fix IR 
so that it does not have to be locked in a 2-step transition in the HD, i.e. 
the IR can be made to safely allow moving to FC directly. This way, we don't 
even need to consider this issue anymore. Repairs would either be made by 
co_common or IR, which packet type both allow moving back to FC would we agree 
on this solution.

> losing major functionality. So it might be worthwhile considering. When

I also favor removing the definition of IR-DYN in the RoHCv2 profiles, thus 
leaving it unsupported.

I will wait some more to see if others have a different views on this.

> it can still be kept in framework so that other profiles such as TCP can

Exactly.

The "IR-DYN" can be minimally seen from the framework perspective simply as a 
reserved type that has a minimal requirements that needs to be followed IF its 
usage is defined by a specific profile. There is no requirement from the 
framework for any profile to define its profile-specific content.

In other words, we'll leave it untouched in the framework document, as RoHC-
TCP, profiles from 3095 and other derivates such as RoHCv1-IP only and RoHCv1 
UDP Lite do define its use, and also to leave this possibility open for other 
profiles in the future. But we'll remove its definition in the RoHCv2 profile 
if consensus of the wg indicates that we shall do like this.

Right now, I haven't seen any objections to this proposal so far.

> I would not expect this to happen in reality. If the HC wants to be

... and we would like to address this from the protocol design itself, not to 
leave this to the implementation. This simplifies the implementation work and 
remove the possibility of "rogue" implementation behavior. 

An example is an IR that gets reordered with another IR as follow, combined 
with some unfortunate but legal feedback logic:

SENT:
-----
IR(SN=0, TS_STRIDE=Y)
IR(SN=1, TS_STRIDE=X)
IR(SN=2, TS_STRIDE=X)
IR(SN=3, TS_STRIDE=X)
co_common(SN=4)

RECEIVED:
---------
IR(SN=1, TS_STRIDE=X)
IR(SN=2, TS_STRIDE=X)
IR(SN=3, TS_STRIDE=X)   -> ACK(SN=3)
IR(SN=0, TS_STRIDE=Y)   -> HD update the context
                           (it MAY do so and keep TS_STRIDE=Y)
co_common(SN=4)         -> fails, NACK(SN_NOT_VALID)

While I would not pride myself in succeeding in conceiving the above example, I 
still think that it does nothing wrong from the protocol's perspective.

The HD has acked SN=3 for some reason (e.g. to shorten the OA of the HC).
The HD is simply implemented to update its context for all packets that 
succeeds its verification at any time (e.g. as above including SN=0 even if the 
packet was reordered.

The HD sent feedback when the first CRC7 attempts fails, and it sends it with 
the highest severity level because it assumes a severe error. In the example, 
this is a possible implementation as there is no advanced logic to address 
reordering other than to rely on feedback and repairs for simplicity.

The HC can reply with resending only what has changed from SN=3 and above, for 
which optional field such as TS_STRIDE hasn't.

... and then on forever (e.g. for several RTT)

A far-fetched example (that might actually be wrong too), but possible the 
protocol perspective. I am much more interested by making sure this is not 
possible from the protocol design perspective, if it can be avoided easily, 
than to try to identify all possible corner-cases of possible impairments. 

Other cases may occur as well, this is because context updating logic and 
feedback logic in the HD and repair logic in the HC are left to implementation, 
and this is something I strongly feel is the correct way to have things. 

Finally, there is no reason to protect updating and repair of optional and/or 
control fields less than any other fields - they are just as important as any 
other fields. And this is what the current proposal addresses.

> control fields that are not sent? The crc8 covers control fields anyway.

This is a possible alternative. However, we do not want the CRC8 to cover parts 
of the context - it should only cover what is part of the IR header itself. 

This means that any field that remains optional will still not be covered by a 
CRC, thus not verified, unless it is present in the IR header.

In other words, having CRC8 providing robustness for such fields at all times 
means that:
1) either we change the CRC8 definition to include fields that
  are not part of the IR header
2) CRC8 covers only what is sent, and no fields are optional,
  and thus always sent

I am opposed to 1), because the success of IR should be independent of the 
state of the decompressor context. 2) is an alternative, but it means much 
overhead and some of the fields don't always have a suitable value to be 
included in the header when sending the IR (e.g. TS_STRIDE in the first IR is 
purely a guess in theory). The extra overhead of sending all fields in IR can 
get up to 8-10 octets (and overshoot the MTU in some cases such as streaming), 
which feels like an unnecessary drawback. 

Alternatively, I would like to know if you see a problem with the current 
proposed approach, or if you are simply looking to understand its motivation?

> clarify this in the next revision? The current text does not explicitly

Absolutely. I agree that this isn't clear right now.

---

From: "Jin, Haipeng" <[email-masked]>
Date: Wed, 18 Oct 2006 00:53:42 -0700

Hi, Ghyslain,

Thanks for the clarification. It seems that we have common understanding
on most issues here.

As far as the IR fix is concerned, using CRC8 is just a suggestion
trying to avoid adding another crc to the IR. But it seems from the
problems you identified, this may lead to dependency of IR on context or
inefficiency if all optional fields are sent always. It seems that
adding crc3 may be more preferable. Since sending IR is really a rare
event, I don't have strong preference on this issue.

Regards,
Haipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 1:25 AM
To: Jin, Haipeng
Cc: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund (LU/EAB);
[email-masked]

Hi Haipeng,

Thanks for your answer.
Comments inline.

///Ghyslain

> updating types. I agree that the extra MSN in crc7 might be helpful in

Ok. Our recent as Kristofer sent last week is to remove the IR-DYN and
fix IR 
so that it does not have to be locked in a 2-step transition in the HD,
i.e. 
the IR can be made to safely allow moving to FC directly. This way, we
don't 
even need to consider this issue anymore. Repairs would either be made
by 
co_common or IR, which packet type both allow moving back to FC would we
agree 
on this solution.

> losing major functionality. So it might be worthwhile considering.
When

I also favor removing the definition of IR-DYN in the RoHCv2 profiles,
thus 
leaving it unsupported.

Exactly.

The "IR-DYN" can be minimally seen from the framework perspective simply
as a 
reserved type that has a minimal requirements that needs to be followed
IF its 
usage is defined by a specific profile. There is no requirement from the

In other words, we'll leave it untouched in the framework document, as
RoHC-
TCP, profiles from 3095 and other derivates such as RoHCv1-IP only and
RoHCv1 
UDP Lite do define its use, and also to leave this possibility open for
other 
profiles in the future. But we'll remove its definition in the RoHCv2
profile 
if consensus of the wg indicates that we shall do like this.

> I would not expect this to happen in reality. If the HC wants to be

... and we would like to address this from the protocol design itself,
not to 
leave this to the implementation. This simplifies the implementation
work and 
remove the possibility of "rogue" implementation behavior. 

An example is an IR that gets reordered with another IR as follow,
combined 
with some unfortunate but legal feedback logic:

SENT:
-----
IR(SN=0, TS_STRIDE=Y)
IR(SN=1, TS_STRIDE=X)
IR(SN=2, TS_STRIDE=X)
IR(SN=3, TS_STRIDE=X)
co_common(SN=4)

RECEIVED:
---------
IR(SN=1, TS_STRIDE=X)
IR(SN=2, TS_STRIDE=X)

While I would not pride myself in succeeding in conceiving the above
example, I 
still think that it does nothing wrong from the protocol's perspective.

The HD has acked SN=3 for some reason (e.g. to shorten the OA of the
HC).
The HD is simply implemented to update its context for all packets that 
succeeds its verification at any time (e.g. as above including SN=0 even
if the 
packet was reordered.

The HD sent feedback when the first CRC7 attempts fails, and it sends it
with 
the highest severity level because it assumes a severe error. In the
example, 
this is a possible implementation as there is no advanced logic to
address 
reordering other than to rely on feedback and repairs for simplicity.

The HC can reply with resending only what has changed from SN=3 and
above, for 
which optional field such as TS_STRIDE hasn't.

A far-fetched example (that might actually be wrong too), but possible
the 
protocol perspective. I am much more interested by making sure this is
not 
possible from the protocol design perspective, if it can be avoided
easily, 
than to try to identify all possible corner-cases of possible
impairments. 

Other cases may occur as well, this is because context updating logic
and 
feedback logic in the HD and repair logic in the HC are left to
implementation, 
and this is something I strongly feel is the correct way to have things.

Finally, there is no reason to protect updating and repair of optional
and/or 
control fields less than any other fields - they are just as important
as any 
other fields. And this is what the current proposal addresses.

> control fields that are not sent? The crc8 covers control fields
anyway.

This is a possible alternative. However, we do not want the CRC8 to
cover parts 
of the context - it should only cover what is part of the IR header
itself. 

This means that any field that remains optional will still not be
covered by a 
CRC, thus not verified, unless it is present in the IR header.

In other words, having CRC8 providing robustness for such fields at all
times 
means that:
1) either we change the CRC8 definition to include fields that
  are not part of the IR header
2) CRC8 covers only what is sent, and no fields are optional,
  and thus always sent

I am opposed to 1), because the success of IR should be independent of
the 
state of the decompressor context. 2) is an alternative, but it means
much 
overhead and some of the fields don't always have a suitable value to be

included in the header when sending the IR (e.g. TS_STRIDE in the first
IR is 
purely a guess in theory). The extra overhead of sending all fields in
IR can 
get up to 8-10 octets (and overshoot the MTU in some cases such as
streaming), 
which feels like an unnecessary drawback. 

Alternatively, I would like to know if you see a problem with the
current 
proposed approach, or if you are simply looking to understand its
motivation?