Subject: [rohc] Re: Mode transitions with rfc3095

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 25 Nov 2005 11:06:59 +0100

Hi Wan,

[Wan, this is the same mail I sent you earlier, I just forgot to cc the list]
[And I had to change title - the spam filter @IETF bounced the mail back!!! ]
[Original title was -- RE: Thank you for your reply for my question.        ]

My opinion regarding how to perform mode transition is the following:
- compressor and decompressor always start in U-mode
- as soon as decompressor successfully decompress one packet (initial IR),
  the decompressor should send feedback with the mode bits set to O-mode.

i.e. The decompressor should always try to perform a mode transition from U-mode to O-mode as soon as possible. I cannot think of any good reasons for the decompressor to perform a transtion from O-mode back to U-mode -- I think it is in the specification only because it is possible, and easy to achieve. As I said previously, I cannot see any gains in ever performing a transition from U/O-mode to R-mode.

I understand that you are trying to make an algorithm that will measure the link state and link quality in order to trigger such mode transition, and I understand the problem that you are exposing to me regarding the losses over the link. Personnally, I think that there is no easy way to do this, like you point out yourself, but I also think that this is not needed if you implement your decompressor to always move to O-mode as soon as possible, and to stay in O-mode for the entire compression process. The O-mode is in my opinion both the most robust mode of operation and the most performant compression-efficiency wise of the 3 modes defined in rfc3095.

>    I am sorry for last letter that I can`t say my question clearly.

Don't be sorry for this! The important is that in the end we understand and help out each other : )

I hope this helps you a little. You're very welcome, don't hesitate if you have more questions, and I wish you the best for your work.

///Ghyslain 

wanxiujin wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 完 全 免 费 & 无 限 容 量 ＝ 你 的 网 易 相 册
> <http://adclient.163.com/event.ng/Type=click&FlightID=46628&Ad
> ID=48547&TargetID=635&Segments=80,94,289,416&Targets=1758,92,6
> 35&Values=31,43,51,60,72,78,82,91,100,110,150,312,330,332,457,
499,586,615,702,733,734&RawValues=&Redirect=http://photo.163.com/>

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