Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-11.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Aug 2010 22:50:11 +0100

On 9 Jul 2010, at 14:45, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Audio/Video Transport Working Group  
> of the IETF.
>
>
> 	Title           : Unicast-Based Rapid Acquisition of Multicast RTP  
> Sessions
> 	Author(s)       : B. Ver Steeg, et al.
> 	Filename        : draft-ietf-avt-rapid-acquisition-for-rtp-11.txt
> 	Pages           : 51
> 	Date            : 2010-07-09
...
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for-rtp-11.txt

In section 7.3, does the Burst Duration optional TLV element measure  
the duration of the burst in terms of the media data it contains, or  
does it measure the time it will take the BRS to send the burst (i.e.,  
if the burst codes video that will play for one second, but I have  
sufficient bandwidth to send at twice the normal rate, will the Burst  
Duration be 1000ms or 500ms)? The current text can be interpreted  
either way.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Aug 2010 00:53:52 -0700

> Duration be 1000ms or 500ms)? The current text can be interpreted

It is the latter, i.e., time that will take the BRS to send the data.

Will make this clear in the revision.

-acbegen
 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Peilin YANG <[email-masked]>
Date: Tue, 24 Aug 2010 17:00:13 +0800

Hi Ali,

Take Colin's example, do you mean if BRS sends the burst at twice the normal bitrate, Burst Duration is 1000ms; if BRS sends the burst at 1.5 times the normal bitrate, Burst Duration is 2000ms?

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 八月 24日, 2010 下午3:56
主题: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-11.txt
收件人: Colin Perkins <[email-masked]>, [email-masked]

> > does it measure the time it will take the BRS to send the burst 
> (i.e.,> if the burst codes video that will play for one second, 
> but I have
> > sufficient bandwidth to send at twice the normal rate, will the 
> Burst> Duration be 1000ms or 500ms)? The current text can be 
> interpreted> either way.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Aug 2010 02:12:43 -0700

This is the text I suggest:

"Optional TLV element that denotes the time the burst will last (in ms), i.e., the delta difference between the transmission times of the first and the last burst packet that BRS is planning to send in the respective RTP stream."

Does this work for everyone?

-acbegen

> -----Original Message-----
> From: Peilin YANG [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 12:00 PM
> To: Ali C. Begen (abegen)
> Cc: Colin Perkins; [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-11.txt
> 
> 
> Hi Ali,
> 
> Take Colin's example, do you mean if BRS sends the burst at twice the normal bitrate, Burst Duration is 1000ms; if BRS sends
> the burst at 1.5 times the normal bitrate, Burst Duration is 2000ms?
> 
> Peilin
> 
> 
> 
> ----- 原邮件 -----

---

From: Colin Perkins <[email-masked]>
Date: Tue, 24 Aug 2010 10:27:36 +0100

That clarifies the intended meaning, although I suggest changing "will  
last" to "is expected to last" and adding a note to the effect that  
changes in the available network capacity between BRS and receiver may  
cause this estimate to be inaccurate.

It's also not clear why this is useful, given the earliest multicast  
join time attribute which tells you almost the same thing. I had  
assumed the burst duration was the duration of the media data, since  
that can be used to determine playout buffer size, rather than  
delivery time.

Colin

On 24 Aug 2010, at 10:12, Ali C. Begen (abegen) wrote:
> "Optional TLV element that denotes the time the burst will last (in  
> ms), i.e., the delta difference between the transmission times of  
> the first and the last burst packet that BRS is planning to send in  
> the respective RTP stream."
>
>> Take Colin's example, do you mean if BRS sends the burst at twice  
>> the normal bitrate, Burst Duration is 1000ms; if BRS sends

-- 
Colin Perkins
http://csperkins.org/

---

From: Peilin YANG <[email-masked]>
Date: Tue, 24 Aug 2010 17:27:45 +0800

Hi Ali,

I think it is clear.

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期二, 八月 24日, 2010 下午5:12
主题: RE: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-11.txt
收件人: Peilin YANG <[email-masked]>
抄送: Colin Perkins <[email-masked]>, [email-masked]

> "Optional TLV element that denotes the time the burst will last 
> (in ms), i.e., the delta difference between the transmission times 
> of the first and the last burst packet that BRS is planning to 
> send in the respective RTP stream."
> 
> > Take Colin's example, do you mean if BRS sends the burst at 
> twice the normal bitrate, Burst Duration is 1000ms; if BRS sends
> > > > In section 7.3, does the Burst Duration optional TLV element 
> measure> > > the duration of the burst in terms of the media data it
> > > contains, or

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Aug 2010 02:40:08 -0700

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 12:28 PM
> Cc: Peilin YANG; [email-masked]

Ok sounds good.
 
> join time attribute which tells you almost the same thing. I had

Not necessarily. I.e., there is no requirement that the mcast and ucast streams should not collide at all. 

> that can be used to determine playout buffer size, rather than

The client can specify the min/max buffer fill requirements in the rams-r message if needed (page 30).

-acbegen 

> >>>> measure

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 24 Aug 2010 19:46:30 +0700

> cause this estimate to be inaccurate.

Indeed.  Unless we want to change the name to the Internet Fortunetelling Task Force, perhaps we should try to refrain from predicting the future in too much detail ;-).

...

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Aug 2010 05:57:26 -0700

I am not sure why you are reading too much into this. It has nothing to do with predicting the future. If the burst will take X ms for the server to transmit, that is the number it reports. This means, if there is no jitter, it will take this long for the client to receive the burst. Of course, nasty things may and will happen but at the end RAMS success does not depend on very accurate timings. We attempt to optimize the acquisition but we also provide enough flexibility in the implementation so that things will not break when the underlying IP network behaves as it usually does.

-acbegen

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Tuesday, August 24, 2010 3:47 PM
> To: 'Colin Perkins'; Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: RE: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-11.txt
> 
> Indeed.  Unless we want to change the name to the Internet Fortunetelling Task Force, perhaps we should try to refrain from
> predicting the future in too much detail ;-).
> 
> ...

---

From: Colin Perkins <[email-masked]>
Date: Tue, 24 Aug 2010 15:34:39 +0100

The server can only estimate how long the burst will take to transmit,  
on the assumption that the network conditions don't change. I was  
asking, in the least important part of my comment, that the text  
reflect this.

Colin

On 24 Aug 2010, at 13:57, Ali C. Begen (abegen) wrote:
> I am not sure why you are reading too much into this. It has nothing  
> to do with predicting the future. If the burst will take X ms for  
> the server to transmit, that is the number it reports. This means,  
> if there is no jitter, it will take this long for the client to  
> receive the burst. Of course, nasty things may and will happen but  
> at the end RAMS success does not depend on very accurate timings. We  
> attempt to optimize the acquisition but we also provide enough  
> flexibility in the implementation so that things will not break when  
> the underlying IP network behaves as it usually does.
>
> -acbegen
>
>>> That clarifies the intended meaning, although I suggest changing  
>>> "will last" to "is expected to last" and adding a note to the  
>>> effect that changes in the available network capacity between BRS  
>>> and receiver may cause this estimate to be inaccurate.
>>
>> Indeed.  Unless we want to change the name to the Internet  
>> Fortunetelling Task Force, perhaps we should try to refrain from  

-- 
Colin Perkins
http://csperkins.org/

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 24 Aug 2010 23:02:55 +0700

Ali C. Begen (abegen) [mailto:[email-masked]] writes:

> I am not sure why you are reading too much into this. It has nothing to
> do with predicting the future. If the burst will take X ms for the
> server to transmit, that is the number it reports. 

I guess that it's the declarative nature of the statement that bothers me: there is in fact no way for anyone to _know_ that "the burst will take X ms for the server to transmit"; the number it reports is an estimate.   

> This means, if there
> is no jitter, it will take this long for the client to receive the
> burst. Of course, nasty things may and will happen but at the end RAMS
> success does not depend on very accurate timings. We attempt to optimize
> the acquisition but we also provide enough flexibility in the
> implementation so that things will not break when the underlying IP
> network behaves as it usually does.

Normally, estimates are qualified with a margin of error; how far off can this estimate be w/o becoming useless?

> "will

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 24 Aug 2010 09:07:34 -0700

> Sent: Tuesday, August 24, 2010 7:03 PM
> To: Ali C. Begen (abegen); 'Colin Perkins'
> Cc: [email-masked]
> I guess that it's the declarative nature of the statement that bothers me: there is in fact no way for anyone to _know_ that
> "the burst will take X ms for the server to transmit"; the number it reports is an estimate.

The server can make a pretty good estimate about how long it will take it to transmit that burst because it knows the rate of the transmission.
 
> Normally, estimates are qualified with a margin of error; how far off can this estimate be w/o becoming useless?

I'd say that is pretty implementation and application dependent. In some cases 10s of milliseconds could be tolerable, in some cases not.

-acbegen