Subject: [rohc] Hi, all. How can I get the Max_jitter_CD and the time when to translate mode?

From: "wanxiujin" <[email-masked]>
Date: Sat, 19 Nov 2005 15:11:20 +0800 (CST)

Hi, all
   I have two question about ROHC 3095.
   1.  If I want to compress RTP protocol TS with time_base_compression. But how can I get the jetter between the compressor and decompressor ,also we can say Max_jitter_CD.
   2.  If the wirless_link is bad we should use U/O mode when the compressor and decompressor work in R mode ,but how we can know when we should let decompressor translate the mode to low mode. Also this question is how to determine the time when to translate the mode?  How we can get the wirless_link situation to determine to translate the mode??
Thank you very much and hop you help me:
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 23 Nov 2005 11:38:00 +0100

Hi,

Regarding Max_jitter_CD, I think that first the compressor should be configured with a default value that matches the jitter characteristics of the link where header compression is applied, i.e. Start with some type of "educated guess" with respect to the maximum jitter that the link between compressor and decompressor may introduce to the packet.

Then the Max_jitter_CD may be refined from feedback received by the decompressor, if it sends feedback with the JITTER option.

Regarding the second question ... huum ... I am not entirely that I understand what you wrote. Either the language is making things problematic here, or there are a number of fundamentals about ROHC modes of operation that are being confused.

I will assume that this is a language problem, thus my guess is that you meant to ask the following:

"Is the usage of the different mode related to the quality of the link? If so, what mode should the compressor and decompressor use when the BER increase over the wireless link? What is the threshold to make the decision to switch from one mode to another?"

Here, I will give my opinion -- but I don't want to open the debate between operational modes, I know that others have different opinions than mine, but I also know that many others share my opinion as well, so you can take what you want out of it.

So, my opnion is -- always use U/O mode, because every packet contains a CRC to verify the decompression outcome. I also uses less feedback since only NACKs are necessary. Your decompressor should never switch to R-mode, it is pointless to do so.

Note also (this is still only my opinion) that the terminology "Optimistic mode" VS "Reliable mode" has little to do with the respective robustness characteristics of each mode of operation. Many people get confused by this and wrongly believe that it relates directly to each mode's capacity to be robust when operating over links with high error rates -- this is not the case.

"Optimistic" is the name given for the approach used to update a context, which simply implies that it is sufficient to send changes in a number of consecutive packets in a manner that ensures that at least one such updating packet makes it to the decompressor, in order to update the context and resume more aggressive compression.

"Reliable" is the name used for the approach where the compressor must send the changes until an ACK comes -- meaning that there will likely be an unnecessary delay before resuming more aggressive compression -- it should have been called "Pessimistic" mode in my opinion ... From my experience, the presence of a CRC in each compressed packet as in U/O-mode is what gives the real reliability, and the more the BER increases over the link the more the U/O-mode has advantage over R-mode.

But hey, this is my opinion, and if someone else wants to say otherwise on this topic I am not thinking to get drawn into this discussion -- and I won't answer with more details either, because the bottom line is that all U/O/R-modes are in 3095 and may be used, and the usage of a specific mode is up to the decompressor implementation only.

///Ghyslain

[email-masked] wrote:
>    1.  If I want to compress RTP protocol TS with
> time_base_compression. But how can I get the jetter between
> the compressor and decompressor ,also we can say Max_jitter_CD.
> 
>    2.  If the wirless_link is bad we should use U/O mode when
> the compressor and decompressor work in R mode ,but how we
> can know when we should let decompressor translate the mode
> to low mode. Also this question is how to determine the time
> when to translate the mode?  How we can get the wirless_link
> situation to determine to translate the mode??
> 
> ________________________________
> 
> 需要一个2000兆的免费邮箱吗？
> 网易免费邮箱是中国最多人使用的电子邮箱。 <http://www.126.com>

---

From: "wanxiujin" <[email-masked]>
Date: Thu, 24 Nov 2005 12:45:43 +0800 (CST)

Hi Ghyslain：
  Thank you for your reply to my question. I also agree with your idear that we use U/O mode will be better,because the wireless link can`t come to so good state.Although the link state is good,but big RTT may make many initial packets for twaiting the ACK packet.
   I am sorry for last letter that I can`t say my question clearly.
   My second question is :if we have only two modes U/O. At first time the decompressor and compressor word at U mode,but the decompressor should go to the O mode for a certain time.So there is a mode translation process.Now my question is when the decompressor decide to translate the mode?The decompressor translates mode from U mode to O mode when the wireless link state is better,but how to weigh the wireless_link_state is becoming better,also we can say the question is how to determine the time that the decompressor starts the translatation ? I wanted to make use of the correct_decompressed rate to determine the link state,but this way can`t deal with the loss between compressor and decompressor. Do you have a better way to analyse the link state in order to determine the time to taranslate the mode from U to O or from O to U mode?
                                    
Yours wan