Subject: Re: [AVT] 回复: FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 4 Sep 2009 23:27:49 -0700

Good question. We have fields for this in the rams-i message and personally I expect these fields to be used more generally. However, some implementations may have rr-based methods to deal with this as I was told.  but I don't have the details. I will let other co-authors repond to this in case they have specific methods in mind. 

-acbegen

----- Original Message -----
From: zouzixuan 61302 <[email-masked]>
To: Ali C. Begen (abegen)
Cc: [email-masked] <[email-masked]>
Sent: Fri Sep 04 23:18:46 2009
Subject: 回复:[AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt

Hi, Ali

 In page 21 of the draft:
A specific situation occurs near the end of the unicast burst, when
   RS has almost no more additional data to sustain the relatively
   higher bursting rate, thus, the upper-bound bursting rate
   automatically gets limited by the nominal rate of the primary
   multicast stream.  During this time frame, RR will join the primary
   multicast session because it was instructed to do so via an RAMS-I
   message or based on some heuristics.  This means that both the burst
   packets and the primary multicast stream packets will be
   simultaneously received by RR for a period of time.

How is RR supposed to know when to join the multicast session based on some "heuristics" without being notified by RAM-I? 

Zou ZiXuan
Senior Research Engineer
Media & Communication Laboratory
Corporate Research Department
Huawei Technologies. Co.,Ltd

Tel: 86 0755 28789364

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期六, 九月 5日, 2009 上午3:27
主题: [AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt
收件人: [email-masked]

> This version provides clarifications on some of the RAMS-I fields. 
> It also assigns the type values to the TLV elements in RAMS messages.
> 
> For the diff, click:
> http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-
> rtp-03
> 
> Comments are welcome.
> -acbegen
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> Sent: Friday, September 04, 2009 8:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-
> 03.txt
> 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-03.txt
> 	Pages           : 45
> 	Date            : 2009-09-04
> 
> When an RTP receiver joins a primary multicast session, it may need
> to acquire and parse certain Reference Information before it can
> process any data sent in the multicast session.  Depending on the
> join time, length of the Reference Information repetition interval,
> size of the Reference Information as well as the application and
> transport properties, the time lag before an RTP receiver can
> usefully consume the multicast data, which we refer to as the
> Acquisition Delay, varies and may be large.  This is an undesirable
> phenomenon for receivers that frequently switch among different
> multicast sessions, such as video broadcasts.
> 
> In this document, we describe a method using the existing RTP and
> RTCP protocol machinery that reduces the acquisition delay.  In this
> method, an auxiliary unicast RTP session carrying the Reference
> Information to the receiver precedes/accompanies the primary
> multicast stream.  This unicast RTP flow may be transmitted at a
> faster than natural rate to further accelerate the acquisition.  The
> motivating use case for this capability is multicast applications
> that carry real-time compressed audio and video.  However, the
> proposed method can also be used in other types of multicast
> applications where the acquisition delay is long enough to be a
> problem.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-
> acquisition-for-rtp-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: zouzixuan <[email-masked]>
Date: Mon, 07 Sep 2009 15:03:52 +0800

Hi, Ali

         When you said “we have fields for ‘this’..”, did you mean the fields for RR doing “heuristic“ multicast joining?

Zou ZiXuan, Senior Research Staff

Media & Communication Lab
HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: [email-masked]
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Saturday, September 05, 2009 2:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: 回复:[AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt

-acbegen

----- Original Message -----
From: zouzixuan 61302 <[email-masked]>
To: Ali C. Begen (abegen)
Cc: [email-masked] <[email-masked]>
Sent: Fri Sep 04 23:18:46 2009
Subject: 回复:[AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt

Hi, Ali

 In page 21 of the draft:

Zou ZiXuan
Senior Research Engineer

Tel: 86 0755 28789364

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 7 Sep 2009 02:52:18 -0700

> “heuristic“ multicast joining?

No. I meant fields for "deterministic" join, e.g., Earliest Multicast Join Time field. Burst Duration field also helps RR to determine join time in mostly a deterministic and somewhat heuristic manner.

-acbegen

---

From: zouzixuan <[email-masked]>
Date: Wed, 09 Sep 2009 10:27:35 +0800

Hi, Ali

Zou ZiXuan, Senior Research Staff
Media & Communication Lab
HUAWEI TECHNOLOGIES CO.,LTD. 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Monday, September 07, 2009 5:52 PM
To: zouzixuan
Cc: [email-masked]
Subject: RE: 回复:[AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt

-acbegen

[zou] So burst duration could be used to anticipate the join time. In the draft, the burst duration is in "RTP ticks" unit. So "RTP ticks" stand for what?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 9 Sep 2009 03:01:44 -0700

> >          When you said “we have fields for ‘this’..”, did you mean the fields for RR
> doing
> > “heuristic“ multicast joining?
> 
> No. I meant fields for "deterministic" join, e.g., Earliest Multicast Join Time field.
> Burst Duration field also helps RR to determine join time in mostly a deterministic and
> somewhat heuristic manner.
> 
> -acbegen
> 
> [zou] So burst duration could be used to anticipate the join time. In the draft, the burst
> duration is in "RTP ticks" unit. So "RTP ticks" stand for what?

It is the number of ticks. The absolute time can be computed based on the ticks and clock rate. E.g., if the clock rate is 90K, 30K ticks corresponds to 1/3 second.

One thing to note here is that burst duration may not always accurately indicate when RR should join the multicast. RS may have planned an overlap or a gap between the burst and primary multicast stream. Furthermore there is always a join latency. So, as much as the current draft says the join time "SHOULD" be sent by RS at least once, we might consider making it a "MUST" if we agree that is a better approach.

-acbegen

---

From: zouzixuan 61302 <[email-masked]>
Date: Wed, 09 Sep 2009 21:59:20 +0800

> It is the number of ticks. The absolute time can be computed based 
> on the ticks and clock rate. E.g., if the clock rate is 90K, 30K 
> ticks corresponds to 1/3 second.

So it's the time that RR would approximately take to transmit the burst.
-Zou 
> One thing to note here is that burst duration may not always 
> accurately indicate when RR should join the multicast. 
>RS may have 
> planned an overlap or a gap between the burst and primary 
> multicast stream. Furthermore there is always a join latency. So, 
> as much as the current draft says the join time "SHOULD" be sent 
> by RS at least once, we might consider making it a "MUST" if we 
> agree that is a better approach.
> 
> -acbegen
> 
But there isn't guide on how to get this earilest join time at RS side. Different RS may have different implementation on this. In that case, the accuracy of join time is still a matter.

Zou ZiXuan
Senior Research Engineer

Tel: 86 0755 28789364

----- Original Message -----
From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wednesday, September 9, 2009 6:05 pm
Subject: RE: RE:[AVT] FW: I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-03.txt
To: zouzixuan <[email-masked]>
Cc: [email-masked]

> It is the number of ticks. The absolute time can be computed based 
> on the ticks and clock rate. E.g., if the clock rate is 90K, 30K 
> ticks corresponds to 1/3 second.
> 
> One thing to note here is that burst duration may not always 
> accurately indicate when RR should join the multicast. RS may have 
> planned an overlap or a gap between the burst and primary 
> multicast stream. Furthermore there is always a join latency. So, 
> as much as the current draft says the join time "SHOULD" be sent 
> by RS at least once, we might consider making it a "MUST" if we 
> agree that is a better approach.
> 
> -acbegen
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 9 Sep 2009 07:21:56 -0700

> So it's the time that RR would approximately take to transmit the burst.

It is the length of the burst in time, which is also the time that will take RS to send the burst. Since burst is sent at a higher rate, the normal playback time will be longer.

> But there isn't guide on how to get this earilest join time at RS side. Different RS may
> have different implementation on this. In that case, the accuracy of join time is still a
> matter.
 
Of course, one RS may plan to send a different burst than another RS. At the end, there are lots of parameters that will cause the burst streams to be different. But, the definition of this field is universal, i.e., independent of the implementation. Through this field (earliest join time), RS tells RR the time to join the multicast session.

-acbegen