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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 14 Dec 2005 10:46:45 +0100

Hi Wan,

I think that you are asking the following question, if I understand you correctly (otherwise, let me know if I misunderstood it):

"We know that the compressor and the decompressor always start in U-mode."
"a) When is it time to move to O-mode?" 

If a feedback channel back to the compressor is available, the decompressor should send feedback with the mode set to O-mode as soon as it receives the first packet. I.e. the decompressor should always seek to move to O-mode as soon as possible.

"b) Is this decision based on the wireless link state (or quality)?"

My answer is that there is no reason to do so. I think that a mode transition from U-mode to O-mode should be based only on the availability of a feedback channel back to the compressor. I understand that you would like to get a suggestion for monitoring this and making your decision process based on link quality and that I am not giving you an answer in that direction may be disappointing, but I think that this is just not the right thing to do - it's simpler: if there's a feedback channel, send feedback to request a transition to O-mode as soon as possible after you've received the first packet for the flow.

"c) 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?"

No, I don't, simply because this is not something that my decompressor would do. I can't see a need for this. My decompressor would move to O-mode as soon as possible when there is a feedback channel available, and stay in O-mode.

Hope this helps, otherwise let us know!

/Ghyslain

[email-masked] 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
> 
> <mailto:[email-masked]>

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 15 Dec 2005 13:27:56 +0100

Hi Wan,

> I can`t determine the time to translate the mode from to 
> O-MODE to U-MODE. Can you help me??

I think that there might be some misunderstanding here.
Either it is the language, or it is the RFC itself
(we normally blame everything on the RFC, it usually is the case ; )
Hopefully I am not misunderstanding your question too much,
but it may be the case! Let's see what we can do about it...

My understanding it that the U-mode means the following:
- the compressor do not expect to receive feedback (ACKs, NACKs)
  from the decompressor -- therefore it must periodically send
  IR-DYN and/or IR packets because it has nothing to rely upon
  to determine if the decompressor has proper context to
  decompressor other type of headers
- the decompressor does not have to send feedback (or it can't).

My understanding it that the O-mode means the following:
- the compressor does rely on, and thus does expect, to receive feedback
  (NACKs, and possibly optional ACKs) from the decompressor --
  therefore it can decide to send IR/IR-DYN for the specific
  purpose of context repairs only based on feedback, and that
  will robust.
- the decompressor is expected to use feedback, at least when
  it assumes context damage (static and/or dynamic)

Also, both U/O-modes perform context updates according to the optimistic approach (OA) (i.e. updates are repeated X times, per field and per change event of a value). Now, this being said, let's go back to your last email:

> packets are lossed. At the same time the decompressor can`t 
> move to U-mode and the IR/IR-DYN packet can`t be sent to 
> decompressor for a long time .

I get the feeling from the above text in your included mail that you are associating the sending of IR/IR-DYN to the U-mode only. IR packets (and IR-DYNs as long as the static context was previously communicated) can and may be sent at any time, in any mode (U/O/R) for any state (IR/FO/SO) -- the IR packet will always be allowed for decompression and decompressible.

> I think it`s very important to 
> let the decompressor have the capacity that the decompressor 
> can translate the mode from O to U. As a robust head 
> compression method ,decompressor must have this capacity.

And so it has, you are very much correct in this. The decompressor may request a transition back from O-mode to U-mode at any time, using feedback. However, if a feedback channel is available, there is no real benefit (as I can see it) in ever performing a transition back to U-mode in terms of compression efficiency and/or robustness. Note that all the packet types that can be sent in O-mode can also be sent in U-mode as well, the challenge resides for the compressor in choosing the right type of compressed header so that the decompressor can successfully decompress, and the compressor base itself on its assumption of what information is established and valid in the decompressor; in U/O-mode this is normally based on the OA and either on periodic refreshes (timers, or counters) in U-mode or on feedback in O-mode. 

> I can`t determine the time to translate the mode from to 
> O-MODE to U-MODE. Can you help me??

I really want to help you, but I can only answer the exact same as I did before. I can't see the need to transit back from O-mode to U-mode. The only thing that I can do is try to identify where the misunderstanding is, but this is more difficult.

Perhaps... perhaps the fact that rfc3095 states that compression always starts in U-mode, establishing a context using IR and IR-DYN packets, is what confuses our discussion? Consider:

1) All compression starts in U-mode
(because the compressor can't assume that the decompressor will send feedback for that flow until it explicitly states it will using a feedback message with mode != U)
2) A context can only be initialized using IR and IR-DYNs
(because these packets both carry all the necessary header information AND the profile to use for this flow)

BUT... 1) and 2) above do _NOT_ mean that IR/IR-DYN can only be sent in U-mode and in IR state!!!

Once again, IR and IR-DYN packet may be sent at any time -- i.e. in any mode (the packet type is framework reserved, thus common to all profiles and common to any possible mode -U/O/R) and in any state (IRs carry enough information to be decompressed).

Please keep taking contact with us until you are confortable with answers to your questions, and let me know if my answers still do not make sense to your understanding so we can identify where the misunderstanding is!

Best regards,

/Ghyslain

> -----Original Message-----
> From: wanxiujin [mailto:[email-masked]] 
> Sent: den 15 december 2005 12:41
> To: Ghyslain Pelletier (LU/EAB)
> Subject: Re: RE: [rohc] Hi, all. How can I get the 
> Max_jitter_CD and the time when to translatemode?
> 
> Hi Ghyslain：
>    Thank you very much for your reply to my letter.  Now I 
> have some question about your reply.
>    If compressor and decompressor translate to O-mode and 
> stay in this mode and can`t translate to U-mode,I thank that 
> the robust is very poor when the wireless link is bad or the 
> mobile-set is moving for a long time. In this case,the 
> packets are lossed. At the same time the decompressor can`t 
> move to U-mode and the IR/IR-DYN packet can`t be sent to 
> decompressor for a long time .I think it`s very important to 
> let the decompressor have the capacity that the decompressor 
> can translate the mode from O to U. As a robust head 
> compression method ,decompressor must have this capacity. But 
> I can`t determine the time to translate the mode from to 
> O-MODE to U-MODE. Can you help me??
>   
> Last ,hope you have beautiful sunshine  everyday.
>                                                               
>                     wan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ________________________________
> 
> 
> 	-----原始邮件-----
> 	发件人:"Ghyslain Pelletier \(LU/EAB\)" 
> 	发送时间:2005-12-14 17:46:45
> 	收件人:"???" ,"" 
> 	抄送:(无)
> 	主题:RE: [rohc] Hi, all. How can I get the Max_jitter_CD 
> and the time when to translatemode?
> 	
> 	
> 	
> 	Hi Wan,
> 	
> 	I think that you are asking the following question, if 
> I understand you correctly (otherwise, let me know if I 
> misunderstood it):
> 	
> 	If a feedback channel back to the compressor is 
> available, the decompressor should send feedback with the 
> mode set to O-mode as soon as it receives the first packet. 
> I.e. the decompressor should always seek to move to O-mode as 
> soon as possible.
> 	
> 	My answer is that there is no reason to do so. I think 
> that a mode transition from U-mode to O-mode should be based 
> only on the availability of a feedback channel back to the 
> compressor. I understand that you would like to get a 
> suggestion for monitoring this and making your decision 
> process based on link quality and that I am not giving you an 
> answer in that direction may be disappointing, but I think 
> that this is just not the right thing to do - it's simpler: 
> if there's a feedback channel, send feedback to request a 
> transition to O-mode as soon as possible after you've 
> received the first packet for the flow.
> 	
> 	"c) 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?"
> 	
> 	No, I don't, simply because this is not something that 
> my decompressor would do. I can't see a need for this. My 
> decompressor would move to O-mode as soon as possible when 
> there is a feedback channel available, and stay in O-mode.
> 	
> 完 全 免 费 & 无 限 容 量 ＝ 你 的 网 易 相 册 
> <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/>