Subject: [rohc] Calculation of TIME_STRIDE (Was - What is p value for TS?)

From: "Ashok Kumar" <[email-masked]>
Date: Tue, 1 Oct 2002 12:50:26 +0530

Hi,
 
RFC 3095 does not give enough information on how to calculate/estimate the value of TIME_STRIDE at compressor. I feel it would be nice, if the relevant information can be included in Implementer's Guide.
 
BR,
Ashok

	-----Original Message----- 
	From: [email-masked] [mailto:[email-masked]] 
	Sent: Mon 9/30/2002 10:58 PM 
	To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] 
	Cc: 
	Subject: RE: [rohc] What is p value for TS?

	Hi,
	
	Sorry about jumping in late. Mikael already answered correctly that
	P value for TS differs depending on if timer-based (TB) is enabled or not.
	
	As to Anton's question on synchronization of whether TB encoding is used,
	it is equivalent to the synchronization of TIME_STRIDE, which in turn is
	nothing different than synchronization of any other values in compression
	context, which in turn is basically a 3-way handshake.
	
	Here is a translation of above into logic.
	
	Compressor:
	
	1) It receives clock resolution from decompressor and decides to enable
	TB.
	
	2) It must keep sending decompressor packets carrying TIME_STRIDE value
	until it is confident that the decompressor has received the
	TIME_STRIDE. For UO-mode, the confidence is based on ACK. For UO-mode,
	the confidence is the repetition number of packets carrying TIME_STRIDE,
	based on some assumption of maximum number of consecutive packet loss.
	
	3) Before it has the confidence, it must NOT use TB encoding. In
	particular, the packets carrying TIME_STRIDE must NOT use TB encoding.
	
	4) Once it has the confidence, it will stop sending TIME_STRIDE,
	and at the same time, switch on TB encoding.
	
	Decompressor:
	
	1) After sending clock resolution but before receiving packets with
	TIME_STRIDE, decompress without TB.
	
	2) For received packets carrying TIME_STRIDE, decompress without TB.
	In addition, send ACKs if in R-mode.
	
	3) When receiving packets that no longer carry TIME_STRIDE, decompress
	with TB. (Stop sending TIME_STRIDE is a signal of successful handshake
	from compressor)
	
	Hope this clarifies things.
	
	BR,
	Zhigang
	
	> -----Original Message-----
	> From: ext Mikael Degermark [mailto:[email-masked]]
	> Sent: September 24, 2002 7:32 PM
	> To: Anton Mårtensson (EAB); Lars-Erik Jonsson (EAB); 'Yang Chang';
	> [email-masked]
	> Subject: Re: [rohc] What is p value for TS?
	>
	>
	> This is indeed underspecified. I have a couple of diagrams
	> that show the
	> various
	> possibilities on how switching from WLSB to Timer-based could
	> be done, but
	> I'll have to dig a bit to find them again. We have discussed
	> this issue on
	> bakeoffs.
	>
	> Two things needs to happen during the switch: Decompressor
	> needs to send its
	> clock granularity to compressor, and compressor needs to send the
	> time-stride to
	> the decompressor. The former can be per-channel, the latter
	> is per-context.
	>
	> The compressor must send a non-zero time-stride in order to enable TB
	> decoding
	> at decompressor: the decompressor does not have enough information to
	> decode otherwise.
	>
	> The main problem here is that one can (will) run into a
	> situation where the
	> compressor
	> cannot know if the decompressor is using Timer-based or WLSB.
	> Therefore it
	> must
	> during this time send enough bits to ensure a correct result
	> no matter which
	> TS decoding
	> method the decompressor is using.
	>
	> I need to sleep now, so can't answer better right now. I'll
	> try to explain
	> this better tomorrow.
	>
	> G'nite,
	>
	> Micke
	>
	> ----- Original Message -----
	> From: "Anton Mårtensson (EAB)" <[email-masked]>
	> To: "'Mikael Degermark'" <[email-masked]>; "Lars-Erik
	> Jonsson (EAB)"
	> <[email-masked]>; "'Yang Chang'"
	> <[email-masked]>;
	> <[email-masked]>
	> Sent: Wednesday, September 25, 2002 12:02 AM
	> Subject: RE: [rohc] What is p value for TS?
	>
	>
	> > Hi Micke and all,
	> > I agree with Yang and L-E that this is confusing. What I don't
	> > understand is how the decomressor could be aware of timer-based
	> > compression is used or not. Of course the decompressor signals if
	> > it is ready for timer-based compression but MUST the
	> compressor always
	> > use timer-based compression after that (with corresponding
	> interpretation
	> > intervals)
	> > If yes the OK but if not how should the decompressor know which
	> > interpretation interval to use, i.e. should it use p=2^(k-1)-1 or
	> > p=2^(k-2)-1.
	> >
	> > Regards
	> >  - Anton
	> >
	> > > -----Original Message-----
	> > > From: Mikael Degermark [mailto:[email-masked]]
	> > > Sent: den 25 september 2002 01:22
	> > > To: Lars-Erik Jonsson (EAB); 'Yang Chang'; [email-masked]
	> > > Subject: Re: [rohc] What is p value for TS?
	> > >
	> > >
	> > > Hi all,
	> > >
	> > > The way it was intended and the way we've implemented it and
	> > > successfully
	> > > interoperated is:
	> > >
	> > > The p-value definition in section 5.7 is for W-LSB encoded TS.
	> > >
	> > > The p-value definition in section 4.5.4 is for Timer-based
	> > > compression of
	> > > TS.
	> > >
	> > > So: yes, the p-values are different in for Timer-based and
	> > > W-LSB encoding of
	> > > TS.
	> > >
	> > > Cheers,
	> > >
	> > > Mikael Degermark
	> > >
	> > > ----- Original Message -----
	> > > From: "Lars-Erik Jonsson (EAB)"
	> <[email-masked]>
	> > > To: "'Yang Chang'" <[email-masked]>; <[email-masked]>
	> > > Sent: Tuesday, September 24, 2002 1:16 AM
	> > > Subject: RE: [rohc] What is p value for TS?
	> > >
	> > >
	> > > > Yang and 3095 co-authors,
	> > > >
	> > > > I totally agree with you that this is confusing.
	> Unfortunately, I
	> > > > was not involved in nailing down the details of these parts and
	> > > > have some problems giving a clear answer to your question.
	> > > >
	> > > > I hope (expect) that any of those who wrote these parts
	> can speak
	> > > > up and explain these issues (Zhigang, Micke, others??).
	> > > >
	> > > > Rgds,
	> > > > /L-E
	> > > >
	> > > >
	> > > >
	> > > > > -----Original Message-----
	> > > > > From: Yang Chang [mailto:[email-masked]]
	> > > > > Sent: den 9 september 2002 04:35
	> > > > > To: [email-masked]
	> > > > > Subject: [rohc] What is p value for TS?
	> > > > >
	> > > > >
	> > > > > Dear All,
	> > > > >
	> > > > > I have doubt about ROHC document as following:
	> > > > >
	> > > > > In Section 4.5.4, on page 33, it is said that "p = 2 ^ (k-1)
	> > > > > - 1"; However, in Section 5.7, on page 75, the interpretation
	> > > > > intervals is said to be
	> > > > > "p = 2 ^ (bits(TS)-2) -1". Which one is correct? or W-LSB
	> > > > > encoded TS use different p than Timer-based compression TS.
	> > > > >
	> > > > > Best regards,
	> > > > >
	> > > > > Yang Chang
	> > > > > _______________________________________________
	> > > > > Rohc mailing list
	> > > > > [email-masked]
	> > > > > https://www1.ietf.org/mailman/listinfo/rohc
	> > > > >
	> > > > _______________________________________________
	> > > > Rohc mailing list
	> > > > [email-masked]
	> > > > https://www1.ietf.org/mailman/listinfo/rohc
	> > > >
	> > >
	> > > _______________________________________________
	> > > Rohc mailing list
	> > > [email-masked]
	> > > https://www1.ietf.org/mailman/listinfo/rohc
	> > >
	> >
	>
	> _______________________________________________
	> Rohc mailing list
	> [email-masked]
	> https://www1.ietf.org/mailman/listinfo/rohc
	>
	_______________________________________________
	Rohc mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/rohc

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

---

From: [email-masked]
Date: Tue, 1 Oct 2002 15:15:49 -0500

Ashok,

I believe it was left out from RFC 3095 intentionally since it
is strictly a local implementation issue. As to whether this 
can be included in Implementer's guide, it's a judgment by 
the authors. To me, the answer is probably no since it is not 
an misinterpretation or ambiguous point. However, I think it 
would be good to clarify in the guide document how TIME_STRIDE
is *synchronized*. (Peter and Lars-Erik, what do you think?)

In practice, one (perhaps naive) way is to observe the arrival
time at compressor for a sequence of packets and make an estimate.
Compressor may also derive it if it gets help from external
entities about the codec being used. This is easy for compressor
at mobile, but may not be possible for compressor in network. 

Note: you also need to do the same for TS_STRIDE estimation.

Practically, there won't be many variances of TIME_STRIDE anyway. 
Most codecs (in environment where ROHC is applied first) generate 
packets at 20ms interval. In addition, even if the estimate is 
incorrect, the compressor can send more TS LSBs to compensate 
the "drift" before it figures out the correct value. Or, the 
compressor can always switch off timer-based compression 
by setting TIME_STRIDE back to 0. The procedure is similar
to that I described below, with one note: TS fields in packets
carrying TIME_STRIDE=0 should already be encoded with 
TB disabled.

BR,
Zhigang

> From: ext Ashok Kumar [mailto:[email-masked]]
> Sent: October 01, 2002 2:20 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [rohc] Calculation of TIME_STRIDE (Was - What is p value for
> TS?)
> 
> 
> Hi,
>  
> RFC 3095 does not give enough information on how to 
> calculate/estimate the value of TIME_STRIDE at compressor. I 
> feel it would be nice, if the relevant information can be 
> included in Implementer's Guide.
>  
> BR,
> Ashok
> 
> 	To: [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; [email-masked] 
> 	Cc: