Subject: [rohc] Update of ROHCv2 profiles draft

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Fri, 25 May 2007 08:48:17 +0200

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

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 25 May 2007 10:26:52 +0200

Hi Kristofer,

Without a closer investigation the changes looks good.

I have one question. How will the changes in the framework draft affect the
ongoing timetable for moving on to become a rfc? Will this change lead to more
changes in the TCP-draft? Is there going to be another round of last-call?

I am looking forward to review the new draft.

BR,
/Calle

-- 
This message and any files transmitted with it is are confidential and may contain
proprietary information. It is intended solely for the the addressee(s). Please
notify the sender immediately by e-mail if you have received this message in error
and delete this message from your system. Any unauthorized review, use,
disclosure, copying, distribution or any action taken or omitted in reliance on
the contents of this message, is prohibited and may be unlawful.

---

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

Hi Calle,

what do you mean by changes to the framework? The framework is in the
editor's queue (and has been there for quite some time now), so this
submission definitely does not change anything in the framework nor to
the TCP or FN drafts (also in the queue). All that is left for
those drafts is the AUTH48, so the WG does not need to look at those
drafts again before they are RFCs.

If my comment about the CRCs is what confused you, you have to remember
that this draft was last updated back in August or something, so
I just meant that the framework has changes since the last update
of this draft and therefore this draft was changed based on that,
not the other way around.

/Kristofer 

Carl Knutsson <mailto:[email-masked]> wrote on den 25 maj 2007
10:27 :

> I have one question. How will the changes in the framework draft
> affect the ongoing timetable for moving on to become a rfc? Will this
> change lead to more changes in the TCP-draft? Is there going to be
> another round of last-call? 
> 
>> 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.
>> 
>> - 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:
>> 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 
>> Thanks to all the people who contributed on the list to the
>> discussions on this draft! 
>> 
>> /Kristofer & Ghyslain
>>

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 25 May 2007 12:59:14 +0200

Hi Kristofer,

Yes it was the comment about the CRCs is what confused me.

BR,
/Calle

---

From: "Sarkar, Biplab" <[email-masked]>
Date: Sun, 27 May 2007 20:15:23 +0530

Kristofer/Ghyslain,

I think the draft should also consider the "out-of-sequence" delivery of
packets at the input of the compressor. Since it's a very common
scenario in the network, we need to address these scenarios more
efficiently. Current draft has incorporated 8-bits for ts_scaled in
pt_2_seq_both format. I would suggest making this ts_scaled variable in
size, to the maximum of 16-bits. I have seen that often we have to use
UOR-2-TS-Ext2 to incorporate about 10-bits with typical WLSB-sliding
window size of 6. I would also suggest similar size for ip_id too. This
way one generic packet will be able to do all these multiple roles.

Thanks
Biplab

-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]] 
Sent: Friday, May 25, 2007 12:18 PM
To: [email-masked]
Cc: Ghyslain Pelletier (LU/EAB)
Subject: [rohc] Update of ROHCv2 profiles draft

Hi all,

Changes to the text:

/Kristofer & Ghyslain

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Mon, 28 May 2007 08:50:55 +0200

Hi Biplab,

I'm not sure I understand your concern here. If the problem is the
pre-link reordering (negative jumps in the absolute values), then
shouldn't it be the "p" value (offset) part of the LSB encoding that
should be changed and not the "k" (#bits)?
Also, since both the TS and the IP-ID are encoded from the MSN 
(RTP SN) then "negative jumps" in these values should be handled by
the MSNs LSB endcoding if the TS/IP-ID has not changed its relation
to it. So then maybe it is more MSN bits that you need? 

To me, the reason for increasing the k-value should be that you see
very long jumps in the TS value that cannot be compressed
with 8 bits of TS (e.g. after a silence period in a codec that does
not send SID frames) .

So, could you explain a bit more when and why you need to choose
larger k-values for these field so we can get a better understanding
of what you want to adress here (i.e. how do the SN and TS change in
the situations you see a problem with)?

BR,
   Kristofer

Sarkar, Biplab <mailto:[email-masked]> wrote on den 27 maj
2007 16:45 :

> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information
> transmitted may not be used to create or change any
> contractual obligations of Starent Networks, Corp.  Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon this e-mail and its
> attachments by persons or entities other than the intended
> recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [email-masked] -- and destroy all copies of
> this message and any attachments without reading or
> disclosing their contents. Thank you."

---

From: Biplab Sarkar <[email-masked]>
Date: Mon, 28 May 2007 12:52:11 +0530

Kristofer,

I have seen some unusual delays of the packets that come to the
compressor from the internet rtp servers and some times they come out of
sequence too. So in order to send those delayed packets I would like
more "k" bits. I often see I need 10-bits of k-bits. But with the
current packets sizes I don't get an optimal packet to sent them. So I
was thinking of the enhancements. 

Looking at the RFC3095, I see the support for UOR-1-TS-Ext2 should have
been ideal. But such packets are not there.  So only way to send large
k-bits is to go to Type-2 packets with extensions. 

Since the delays are not always with in bounds I feel support for larger
values of TS should be incorporated. If one has to minimize the value of
the TS bits they have to send  frequent updates of TIME_STRIDEs which
will bring down the efficiency. One of the problems of sending Type-2
packets in RFC3095 is that one has to repeat them multiple times. So
this is not very efficient. So I suggest support of larger values for TS
both for pt_1 and pt_2 types of packets.

Thanks
Biplab

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Mon, 28 May 2007 11:55:09 +0200

Hi,

comments inline.

Biplab Sarkar <mailto:[email-masked]> wrote on den 28 maj
2007 09:22 :

> Kristofer,
> 
> I have seen some unusual delays of the packets that come to
> the compressor from the internet rtp servers and some times
> they come out of sequence too. So in order to send those
> delayed packets I would like more "k" bits.

I don't think that would solve what you're seeing since I don't think
that is the issue. Here's why I don't agree:

If a packet arrives late out-of-sequence, it can have one of the
following two field change patterns w.r.t. the TS:

a) It sticks to the same SN-to-TS function (deltaTS=TS_STRIDE*deltaSN),
where deltaSN is probably less than zero since it is a late packet.
In this case, you should not need more TS bits since you do not need
to send TS at all, all you need is that p(MSN) can allow for a negative
offset. If this is the case, your RFC3095-compliant compressor chooses
an EXT2 because you have too few SN bits to allow for the negative
jump, and you get extra TS bits only as a sideeffect of that since
you don't have a SN-only extension format.
So are you sure that it isn't this effect you're seeing?
If this is the problem, then the ROHCv2 solution is either a pt_0_crc7
with more MSN bits or you configure for a different p(MSN) via
REORDERING_HALF or something like that. (or extend pt_0_crc7 even
further)

b) It does not have the same pattern (e.g. silence) and
deltaTS=STRIDE*deltaSN+some_other_offset. Again, if it is a late
arrival, deltaSN is probably less than zero.
Also in this case, it might be the MSN (either p or k) that forces
your compressor to choose the EXT2 format. In this case, you of
course have to send some TS bits, but with the current ROHCv2 
8-bit format, you allow an offset of 8*TS_STRIDE in the
negative direction and 248*TS_STRIDE in the positive direction.
So I would *guess* that 8 bits should be enough, possibly that
we should adjust the p-value to something more that 8 if you would
have problems with that.

> I often see I
> need 10-bits of k-bits. But with the current packets sizes I
> don't get an optimal packet to sent them. So I was thinking
> of the enhancements.
> 
> Looking at the RFC3095, I see the support for UOR-1-TS-Ext2
> should have been ideal. But such packets are not there.  So
> only way to send large k-bits is to go to Type-2 packets with
> extensions. 

See above, I suspect you're seeing k(MSN) or p(MSN) being the reason,
not k(TS), but I can't be sure since I don't have your data. 
That's why I asked you to explain the traffic pattern in more
detail.

> 
> Since the delays are not always with in bounds I feel support
> for larger values of TS should be incorporated. If one has to
> minimize the value of the TS bits they have to send  frequent
> updates of TIME_STRIDEs which will bring down the efficiency.

Again, I'd say large k(TS) is only needed in codecs that don't
send SID frames. And as long as we have an 8-bit TS in the pt_2
format, you should allow 248*TS_STRIDE jumps there.
That of couse *might* be a too-small limit, but so far, I haven't
seen any data pointing towards that. Please provide more data
on how the TS and SN jumps and we can have a discussion on if we
need to update the formats.

> One of the problems of sending Type-2 packets in RFC3095 is
> that one has to repeat them multiple times.

You have to repeat all packets multiple times if you work with
the optimistic approach. So to get around this, you would need to
have non-updating packet types, not a larger k-value.
Non-updating PT-1 packets is somehing that can be discussed,
though I am not very fond of those.

/Kristofer

> So this is not
> very efficient. So I suggest support of larger values for TS
> 	> I think the draft should also consider the "out-of-sequence"
>
> 	delivery of > packets at the input of the compressor. Since it's
a
> very common
> 	> pt_2_seq_both format. I would suggest making this ts_scaled
>
> 	variable in > size, to the maximum of 16-bits. I have seen that
> often we have to use
> 	> window size of 6. I would also suggest similar size for ip_id
>
> 	too. This > way one generic packet will be able to do all these
> multiple roles.
> 	>
> 	> Thanks
> 	> Biplab
> 	>
> 	> last year. The draft should be announced within the next
> couple
> 	of days > as usual.
> 	> - Optimized the co_common formats with "meta-discriminators"
> in
> 	order to >   reduce the flag overhead
> -
> 	Removed Appendix A.3 > - CRC algorithm and demo are now in
> framework, so it 
> is removed from
> 	> this draft
> 	getting > closer to finalizing this work now, so we would be
> very grateful
> 	discussions on this draft! >
> 	> /Kristofer & Ghyslain
> 	>

---

From: Biplab Sarkar <[email-masked]>
Date: Mon, 28 May 2007 16:49:39 +0530

Kristofer,

Sorry for the confusion. I was trying to use timer based compression and
I observed that some of the packets arrive too late. Hope Rohcv2 is
still supporting Timer based compression (6.6.9).
Since we want to avoid sending too many Ext3 packets we try to send as
many packets using the current value of TIME_STRIDE. This results in
going for larger value of TS bits. I believe the problem is more
prominent in Timer based compression. As long as the packet arrives
within the constraints of the permitted jitter we can use the same value
of TIME_STRIDE and compress the TS field. Now the problem comes in
getting the desired packet to carry the compresses TS bits. 
I  am yet to fully understand the concept of MSN in ROHCv2, But as you
said the large value of TS was a side effect of limited value of SN,
might be true.  I am attaching some sample data for your reference. 

Thanks
Biplab

---

From: Carl Knutsson <[email-masked]>
Date: Mon, 28 May 2007 16:37:51 +0200

Hi Kristofer, all,

I have found a issue with the crc-verification that we use in ROHCv2 (and ROHCv1).
I don't remember if it was up to discussion when we discussed the crc over the
control fields or not....

This concerns only profiles that consists of constant header fields. Examples are
IPv6, IPv4 with zero/constant ipid with the ip-only profile and maybe some flows
compressed with the UDP profile.

If a header field (or in same cases a control field) in incorrectly updated in the
context and the incorrectly reconstructed header packet passes a crc-verification,
all the following crc3 packet will also pass crc3 verification. This will lead to
damage propagation and the decompressor will pass on several consecutive incorrect
packets to upper layers. The decompressor will not be able to detect the broken
context until the compressor sends a crc7 or IR packet. So basically the
crc-verification does not work if all fields are constant.

This is of course a scenario caused by extreme bad luck and combined with a
failure to update the decompressor context. It may not occur very often, but it is
still a flaw in ROHC.

I also want to add that this is not on issue for flow with randomly or
sequentially changing fields. So the ESP and RTP profiles will not be affected by
this because of sequential changing header fields like ESP/RTP sequence number and
RTP timestamp.

One solution could be to add the msn to the crc3 and crc7 calculation for the
affected profiles.

BR,
Carl Knutsson, Effnet AB

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Mon, 28 May 2007 23:06:41 +0200 (CEST)

Hi Carl,

Could you please elaborate a little on what you meant by:

> If a header field (or in same cases a control field) in incorrectly
> updated in the context and the incorrectly reconstructed header
> packet passes a crc-verification, all the following crc3 packet will
> also pass crc3 verification. This will lead to damage propagation

i.e., what did you have in mind when stating 'a header field is
incorrectly updated in the context'?

Context-updating fields are generally protected by a larger (> 3-bit)
CRC. Is the above statement implying that these larger CRCs are
potentially inefficient in detecting corrupted received ROHC packets
or is there something else that is 'flawed' with the protocol?

Regards,
vick

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 29 May 2007 11:21:06 +0200

Hi Vick,

> or is there something else that is 'flawed' with the protocol?

Maybe the word 'flaw' was a bit strong. The larger crc checks are fine, in
majority of the cases they will successfully detect the context damage and errors
in the headers. I want to point out that there is no recovery mechanism to fall
back to if the if the optimistic criteria and crc-verification fails for the
headers discussed in my previous email.

The context may suffer damage because the last packet in the updating sequence is
damaged or a whole sequence of context updating packets are lost or a 'late'
reordered packet updates the context incorrectly. That is why we have a
crc-verification and negative acknowledgment feedback mechanism to fall back on.

For the headers discussed in my previous email we may be unable to detect using
the crc3 since all fields in the header are static or semi-static or rarely
changing. The crc3 and crc7 are very good at detecting context damage when we have
sequential or random field in the header, but for example crc3 is not sufficient
to detect errors in the context for a header that consists of only semi-static or
rarely changing field.

It may also be a problem for reordering since the msn is used to detect the
reordered packets and it is not protected by a crc. One solution to could be to
add msn field to the crc3/crc7. The side effect would be that the decompressor
will probably discard more packets when it fails to decompress the msn.

BR,
/Calle

>> updated in the

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 29 May 2007 14:18:38 +0200

Hi Kristofer, Ghyslain and Vick,

There are more issues concerning not protecting the msn with a crc. The compressor
can only send msn with crc-protection in IR, co_common, co_repair and *_seq in UDP
and in IP-only (zero/random ipid_behavior). This means it is sent without
protection in all other packet types.

How should the compressor interpret the msn field in an ACK/NACK/STATIC-NACK?
..and with what confidence? The msn was not crc-verified when it was decompressed
at the decompressor (it is protected on its way back though).

I bring only problems and no solutions:) Maybe adding the control fields to the
crc3/crc7 would be a solution or at least the adding the msn.

BR,
/Calle