RE: [rohc] RoHCv2 issue #1: Number of TBC and MSN bits

["Jin, Haipeng" <[e-mail]>]

Hi, Ghyslain,

Referring to the same thread you quoted, there were some proposals on the packet format (http://www1.ietf.org/mail-archive/web/rohc/current/msg04565.html), some of the main changes are highlight as follows:
1. PT1 will have 5 bits for TS instead 4bits, P0-CRC7 will have 5 bits of MSN instead of 6bits
2. a couple of PT2 packets will have 6bits of MSN instead of 7bits.

It seems based on discussion in the mailing list, the main focus were on point 1 above. So the main tradeoff is really as follows:
1. 4b TS, +/-100ms jitter tolerance; 6b MSN, at least 16 packets reordering tolerance
2. 5b TS, +/-260ms jitter tolerance; 5b MSN, at least 8 packets reordering tolerance

Since VoIP is really the application that cares most about the jitter and reordering, we can use VoIP as an example, then we can further simplify the comparison as follows:
1. 4b TS, +-100ms; 6b msn, 16 packets reordering, 320ms jitter => Min(100, 320) = 100ms effective jitter/reorder tolerance
2. 5b TS, +- 260ms; 5b msn, 8 packets reordering, 160ms jitter => Min (260, 160) = 160ms effective jitter/reorder tolerance

Option 2 would allow better usage of the packet formats.

In addition, I don't understand why you are saying that one octet does not matter. In essence, we are both arguing over one octet. If you really believe that one-octet does not matter, then we can simply get rid of P0-crc7 and use 3-Byte PT2 for the purposes you wanted, PT2 has 7b of MSN and 7b CRC. It also helps to free up some scarce packet discriminator resource for more TS bits :-)

It has been iterated over the mailing list, the reason for TBC is because even though it may seem only one extra byte without it. Over some wireless links (at least for PP2), the extra byte really dictates that a much larger physical layer packet will be needed to carry the VoP packet. This directly converts to capacity loss. Thus it is important to get rid of the extra byte.

Best Regards,
Haipeng

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2007 7:58 AM
To: [e-mail]
Subject: [rohc] RoHCv2 issue #1: Number of TBC and MSN bits

RoHCers,

Trying to summarize the issues in order to move forward.

Issue #1: Number of TBC and MSN bits
====================================
The issue here seems to be that there are only a certain number of bits available for MSN and TBC in PT1 packet types. These bits should be split between those two fields in the best manner.

Currently, we have the following formats:
1) useful against moderate # consecutive losses, very small reordering depth:
  - PT0-CRC3: MSN(4 bits), size(1 octet)
  - PT1     : MSN(4 bits), size(2 octets)
2) useful against higher # consecutive losses, higher reordering depth
  - PT0-CRC7: MSN(6 bits), size(2 octets)   
  - PT2     : MSN(7 bits), size(3 octet)

Note that PT0-CRC7 is also useful (when sending a PT0 type is possible) to efficiently verify the updating of control fields by an IR header. This makes updating of control fields more robust (see next mail).

Gains of TBC:
=============
With respect to the gains of TBC, my understanding is that:

1) the compression gain it is limited in practice to at most one octet for a number "OA" of packets after a silence period, where the TS to SN function need to be adjusted. This is because the current PT2 (3 octets) can be used, while the alternative would be to modify PT1 (2 octets).

IMO, this is a very small gain, and we need to consider how relevant it is compared to what would be lost in terms of robustness. 

2) one aspect is the amount of jitter that TBC can tolerate depending on the number of TS TBC bits.

Looking at last year's discussions, there is a mail arguing in favor of having 5 bits of TS in PT1:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04579.html

This would require reshuffling the discriminators and taking one MSN bit from PT0-CRC7.

>From what I understand, 4 bits of TBC TS provides a tolerance to jitter of +-100ms; this seems quite sufficient for real-time media such as VoIP, because the end-user/jitterbuffer most likely not be capable of handling a larger variation in arrival time. Wrt large jitter in practice, my understanding is that even with a slow HARQ etc, 100 ms is a lot. So it is unclear to me that handling more jitter than this is needed in fact.

Hence, I think that we should stop trying to optimize for one octet here and there for cases where compression is not in "steady-state", and instead focus on robustness against reordering. In that case, I would argue in favor of keeping the current packet formats in the draft as they are, i.e. 4 bits of TS TBC is enough and less a priority than to have 6 bits MSN in PT0-CRC7

Cheers,

///Ghyslain

 --
 Ghyslain Pelletier, Dipl. Ing.
 Senior Research Engineer
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: [phone]
 Ghyslain.Pelletier at ericsson.com
 http://www.ericsson.com

--------------------------------------------
 The opinions expressed in this message are
 my personal opinions.
 These opinions are not necessarily those of
 my employer, unless stated otherwise.
--------------------------------------------


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

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