Subject: [rohc] Proposed changes for ROHCv2 packet formats

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Fri, 13 Oct 2006 09:23:13 +0200

Hi all,

in parallell with the ongoing discussions, I'd like to inform about 
the other changes that are planned for next revision of the v2 
profiles draft. This only includes changes to the FN code, and other 
changes to the draft will be discussed separately at a later time.

List of proposed changes:
- REORDERING_NONE offset changed to "+1" so that it handles one packet 
of prelink reordering for RTP-based profiles so that it has the same 
tolerance as ROHCv1 even with this reordering setting
- Typo fix: Changed UDP checksum so that it checks !=0 instead of ==1
- INITIAL section added for ts_stride
- Typo fix: Added one more reserved bit in rtp_dynamic to get octet
alignment
- All co_common packet formats optimized by using "meta-indicators", 
so that one flag bit at the top level controls the presence of 
one-octet of additional flag bytes. This removes padding and reduces 
the minimum size of all co_common packets, but adds a number of new 
encoding methods to the FN code. These new things use the grouping 
syntax in the latest FN draft. This also means that the order of
fields is revised
- Fixes to scaling code and more ENFORCE statements to make sure that
there can be no misunderstandings in its use
- msn_lsb changed to take only one argument since the offset is set 
by the reordering offset
- Added a new format for RTP-based profiles, pt_2_seq_both, which is 
an UOR-2-ID-ext1 replacement which can send a few bits of both TS and 
IP-ID efficiently. This packet format's discriminator is created by 
making the pt_2_seq_id have one bit longer discriminator and one less 
bit of coded IP-ID
- time_stride and other timer-based functionality will be added to 
RTP-based profiles. This will update all scaled encoding code, 
including having to add another text-based encoding method that 
defines the separate interpretation interval to use with using 
timer-based encoding.
- Cleanup changes to the code, for example use of expressions in 
place of some of the current VARIABLE declarations

If you feel that any of the changes above should not be incorporated
into the draft, reply to this with a motivation of why.

/Kristofer

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

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Fri, 13 Oct 2006 14:23:10 -0700

Kristofer,

The changes mentioned by you look OK. I have a question on one of the

>>- Added a new format for RTP-based profiles, pt_2_seq_both, which is
an UOR-2-ID-ext1 replacement which can send a >>few bits of both TS and
IP-ID efficiently. This packet format's discriminator is created by
making the pt_2_seq_id >>have one bit longer discriminator and one less
bit of coded IP-ID

Can you please give the motivation behind adding this packet format?

Also, few comments on the v2 draft:

1) In Sections 6.5.1 and 6.5.2, I think some more explanation would help
in readability. As an example, if the inner IP header has extension
headers, what is going to be the order of headers in the irregular chain
etc?

2) At the beginning of the RTP profile, there is a comment
"ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit of an
outer header." This sentence does not seem to be complete. Also, is the
intention for the user to set this flag? Shouldn't the compressor be
figuring out the value of this flag?
 
3) It would be best if number of bits for SN, TS and IP-ID are kept as
similar as possible to RoHC v1 profiles, unless there is a need to
change these. For instance, in packet pt_1_rnd, SN is now 5 bits, which
also changes TS to 4 bits (in 3095 in the corresponding packet, SN was 4
bits and TS was 5 bits). Also, in packet pt_1_seq_id, SN is now 5 bits
and IP-ID is 4 (in 3095 in the corresponding packet, SN was 4 bits and
ID was 5 bits).
 
4) Also, one overall comment. In general for a VoIP service (which
benefits the most from RoHC compression due to its small payload), the
two most important and frequently used packets are likely to be pt_0 and
pt_1_seq_ts (due to Silence Suppression). In 3095, these packets had
sizes of only 1 and 2 octets respectively, which is one reason why 3095
proved to be so efficient in carrying VoIP traffic. IMO, RoHC v2 profile
should also be designed to be as good for VoIP. In the current v2 draft,
this is indeed the case.
 
My only concern is that 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"
 
Other discriminators stay the same.
 
The above is just a suggested discriminator scheme. Whether you pick up
this or some other discriminator scheme, I strongly urge the authors to
fit pt_1_seq_ts within 2 octets, to ensure that the service that can
potentially gain the maximum from RoHC, i.e., VoIP, continues to do so.
 
Thanks,
Rohit

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Mon, 16 Oct 2006 16:21:15 +0200

Hi Rohit,

comments inline.

On Friday, October 13, 2006 11:23 PM, Kapoor, Rohit wrote:

>> making the pt_2_seq_id have one bit longer discriminator
>> and one less bit of coded IP-ID
> 

I added this based on comments I have received on the individual
submission of the draft (off-list, before the draft was a WG draft). 
I agree with those comments that it is a good idea
to allow sending some TS and some IP-ID bits simultaneously and not
have to go up to co_common. When the timestamp changes (for example
after a silence period), it is quite high probability that also the
IP-ID has changed its offset, and therefore it would be nice to update
both.
On the other hand, after my optimization of co_common, the same 
information can be conveyed by a packet that is just one octet larger
than this one, so it might not be the most important change ever.
On the other hand, I don't see a problem with adding this since it
is both a simple-to-implement format and the bit of IP-ID which is
stolen from the pt_2_seq_id does not seem important, so it should
be pretty ok to add it.

> headers, what is going to be the order of headers in the

These sections do not deal with the irregular chain, they only deal
with how the things are handled in the UNCOMPRESSED part of baseheader.
But the information you're looking for will be added to the draft.
Please look ar ROHC-TCP for now, and see if the explanations
of chains are sufficient there since we plan on just "porting" that text
to the v2 draft. If that text is not good, please suggest alternative
wordings.

> figuring out the value of this flag?

Same here, look at ROHC-TCP (section 6.5). We plan to add a similar
chapter to v2 profiles that explain this type of arguments to encoding
methods.
Would that type of section be good enough?

> change these.

Why would that "be best"?
Implementation-wise any such change should not be more than 2-3 lines
of code and we don't have any backwards-compatibility requirement.

> For instance, in packet pt_1_rnd, SN is now 5
> bits, which
> and IP-ID is 4 (in 3095 in the corresponding packet, SN was 4 bits
> and ID was 5 bits). 
> 
> pt_1_seq_ts (due to Silence Suppression). 

The feedback I've seen from "v1 implementers" and from the interop 
tests that have been held (also for v1), the most frequent packet used 
when compressing VoIP would be pt_0 and pt_2, while pt_1 is more more 
unusual.
So basically, the type of packets used for VoIP depends on a number of
other factors, and the ROHC WG must choose a solution that works as 
good as possible for all of these, and then I'm far from sure that pt_1
must receive "preferential treatment".
I'm not commenting on your specific proposal for packet types since I
think we first need to discuss the above.

BR,
   Kristofer

---

From: Carl Knutsson <[email-masked]>
Date: Mon, 16 Oct 2006 18:10:36 +0200

Hi Rohit, Kristofer,

Comments inline..

> stolen from the pt_2_seq_id does not seem important, so it should

It was I who requested this packet format. The equivalent in v1 would be
UOR-2-(ID|TS)-Ext[1-2] (regex). As Kristofer mentions above, when IP-ID is
sequential and other IP traffic are produced by the same stack, it is very likely
that a ROHC compressor would pick this packet format after a silence period.

This was before it was decided to use optional fields and bit masks in co_common
(which I also requested off-list, Unnecessary since the Kristofer and Ghyslain was
already considering adding it:). I may be willing to compromise on the
pt_2_seq_both when I see the actual packet formats for co_common and
pt_2_seq_both. If co_common make pt_2_seq_both redundant, then we should remove it
from v2. If not, I find this packet format important since most IP stacks today
use IPv4 with some sort of sequential identification field. If it helps, I don't
think the size of the type field a very big priority for the pt_2_seq_both format.
 It will still have a smaller type field than co_common.

/Calle

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Mon, 16 Oct 2006 12:28:04 -0700

Kristofer,

Please see some comments below.

> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB)
[mailto:[email-masked]]
> Sent: Monday, October 16, 2006 7:21 AM
> To: Kapoor, Rohit; [email-masked]
> Subject: RE: [rohc] Proposed changes for ROHCv2 packet formats
> 
<Rohit> Yes, the TCP draft is clearer in the explanation of some of
these things. That would certainly help. I will take a more detailed
look at the TCP draft, and let you know if I have any suggestions for
v2.

> > and IP-ID is 4 (in 3095 in the corresponding packet, SN was 4 bits

<Rohit> My concern here is that when timer-based is added, at least 5
bits for TS would be useful to handle jitter on the link (as much as
3095 can). So, I was recommending changing pt_1_rnd to have 4 bits for
SN and 5 for TS (same as 3095). I am not too concerned about
pt_1_seq_id.

> think we first need to discuss the above.

<Rohit> My comment about T0 and T1 being most frequently used was
applicable to PP and PP2 systems. On the other hand, as you said, there
may be other systems that may use T2 packets for VoIP (though I don't
know which systems).

Pls note that I am not asking for preferential treatment for T1 packet,
just that it should be as good as corresponding 3095 packet. Also, pls
note that I am also not advocating increasing the size of the T2 packet
compared to 3095.

Also, my comment about T1 is sort of part of a more broad comment, that
v2 profiles should be as good, if not better than 3095, so that systems
have the incentive to migrate to v2. Clearly, v2 has some advantages
over 3095 (more robust, better handling of multiple IP headers etc). In
the same spirit, if T1 (and even T2) packets in v2 are "not bigger" in
size than corresponding 3095 packets (leading to "not worse than 3095"
performance for VoIP in some systems), that would really be a strong
incentive to migrate to v2, given the other advantages of v2.

Thanks,
Rohit

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Mon, 16 Oct 2006 12:29:49 -0700

Carl,

Thanks for the comments.

Rohit

> From: Carl Knutsson [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 9:11 AM
> To: Kristofer Sandlund (LU/EAB)
> Cc: Kapoor, Rohit; [email-masked]
> Subject: Re: [rohc] Proposed changes for ROHCv2 packet formats
> 
> Hi Rohit, Kristofer,
> 
> Comments inline..
> 
> sequential and other IP traffic are produced by the same stack, it is
very
> likely
> pt_2_seq_both. If co_common make pt_2_seq_both redundant, then we
should
> remove it
> from v2. If not, I find this packet format important since most IP
stacks
> today
> use IPv4 with some sort of sequential identification field. If it
helps, I
> don't
> think the size of the type field a very big priority for the
pt_2_seq_both
> format.

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Tue, 17 Oct 2006 16:01:27 +0200

Hi,

comments inline.

> Please see some comments below.

<snip>

>>> benefits the most from RoHC compression due to its small payload),
>>> the two most important and frequently used packets are likely to
>>> be pt_0 and
>> tests that have been held (also for v1), the most frequent packet
>> used when compressing VoIP would be pt_0 and pt_2, while pt_1 is
>> more more unusual. So basically, the type of packets used for VoIP
>> depends on a number of other factors, and the ROHC WG must choose a
>> solution that works as good as possible for all of these, and then
>> I'm far from sure that pt_1 must receive "preferential treatment".

What I meant by "preferential treatement" is the either we prioritize
pt_0_crc7 or we prioritize pt_1_seq_ts. In one case, we have the current
where pt_0_ctc7 has 6 bits of MSN and pt_1_seq_ts has 4 bits of TS or
we have pt_0_ctc7 has 5 bits of MSN and pt_1_seq_ts has 5 bits of TS.

So far, I prefer the former since I think that pt_0_crc7 really benefits
from having 6 bits and that this packet types adds flexibility to the
spec when ROHC is used in very different operating environments.
But you're saying that this gives decrease flexibility for 
TBC-deployments which also is something we have to take into 
consideration.

There's of course one way where we both get what we want and that is
to base some of the discriminators on the context value of time_stride,
something like:

pt_0_crc7_no_tbc {
   ENFORCE(time_stride==0);
   discriminator =:= '100';
..... <same as right now>
}

pt_0_crc7_tbc {
   ENFORCE(time_stride==1);
   discriminator =:= '1011';
.....<one less bit of MSN>
}

pt_1_seq_ts_no_tbc {
   ENFORCE(time_stride==0);
   discriminator =:= '1011';
.....<same as right now>
}

pt_1_seq_ts_no_tbc {
   ENFORCE(time_stride==1);
   discriminator =:= '100';
.....<one extra bit of TS>
}

And we could have both (the same way that IP-ID behavior is used to
control seq and rnd). Details have to be fleshed out and we have to
make sure that this would work and not add extra implementation 
complexity, but off the top of my head, I feel it should work.

But before go into such details, could you please try to explain a bit
more about which assumptions are used when you calculate that 5 bits
are needed for the jitter? I've kind of forgotten timer-based, so it
would be interesting so know why 5 bits is important.

Anyway, I right now see three options:
1) Current draft
2) Change as per your previous suggestion
3) Improve the sketeched suggestion above can be made to satisfy both
requirements (not at the same time, though)

/Kristofer

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 17 Oct 2006 18:51:36 +0200

Hi,

Comments inline..

<snip>

> requirements (not at the same time, though)

I just want to add one thing to this discussion. When creating new packet formats
don't forget that there are two separate sets of packet formats. One set is used
by IPv6 and IPv4 with random and constants_zero IP-ID behavior and the other set
is used by IPv4 with sequential or swapped sequential IP-ID behavior. We must try
to make the two sets with as small type fields as possible. At least for pt 0,1,2.

IPv6, IPv4 RND/ZERO =	{pt_0_cr3, pt_0_crc7, pt_1_rnd, pt_2_rnd}

IPv4 SEQ =		{pt_0_cr3, pt_0_crc7, pt_1_seq_id, pt_2_seq_ts,
			pt_2_seq_id, pt_2_seq_ts}

/Calle

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 17 Oct 2006 16:49:09 -0700

Kristofer,

Thanks for the comments. Please see a couple of comments below.

> Sent: Tuesday, October 17, 2006 7:01 AM

<Rohit> According to Section 4.5.4 of RFC 3095:

            k = ceiling(log2(2 * J + 1),

         where J = Max_Jitter_BC + Max_Jitter_CD + 2.

This means that if you have 4 bits, you can tolerate approx +- 100 msec
of jitter (Max_Jitter_BC + Max_Jitter_CD), while with 5 bits, you can
tolerate approx +- 260 msec of jitter. For packet-switched cellular
systems (and under medium-high loads), 100 msec of jitter protection is
typically not sufficient, while 260 msec is quite good. So, 5 bits is
important.

Just one more comment regarding 6 bits in pt_0_crc7. I agree that 6 bits
provides a lot of protection, but even 5 bits of protection is quite
robust. As an example, if reordering_ratio is quarter, it means with 5
bits, you can handle approx 24 consecutive packet losses (and up to 7
out-of-order). On top of this, pt_0_crc7 also has the strong 7-bit CRC.
So, IMO, even with 5 bits, pt_0_crc7 is very robust.

Based on the above, I would support option 2 below (also to prevent
increased complexity).
 
Also, I'm not really opposed to solution 3, just that I'm trying to
weigh the gains compared to the complexity. And it seems that even with
5 bits for SN, pt_0_crc7 is quite robust.

Thanks,
Rohit