Subject: Re: [AVT] Open issues in the RAMS draft

From: Jinwei Xia <[email-masked]>
Date: Thu, 03 Sep 2009 17:50:27 +0800

Hi Ali,

Sorry to pick up this thread again, however I am not concern whether one
method overwhelm another, but just hope some questions can be clarified in
belowing description. 

> 
> I am not saying RAMS is worse, I am saying RAMS is better. 
> Dedicating the resources to the unicast burst initially and 
> then switching to multicast will perform faster acquisition. 
> In theory, if the current point in multicast transmission is 
> very close to a TSRAP point, server can ask the receiver to 
> join the multicast right away (rather than starting a burst). 

what's the specific message sent from server to receiver? This specific
message is spontaneous or is triggered by receiver? And the "server" is
multicast source, RS or some entity else?

> This is, what I said, available in our draft. 

Does above description is embodied in RAMS draft? Which section?

Your prompt feedback is very appreciated :-)  Thank you!

BR

Jinwei

We can work out 
> the math in the next meeting if you like.
> 
> One point worth to consider in practice is that in mpeg2-ts 
> video, there won't be many "magical" tsrap points (from where 
> you can start decoding immediately). Simply starting from an 
> I frame does not cut it (as explained in our other draft). 
> Many other components are required by the decoder, so, almost 
> always starting a unicast burst will perform better since the 
> unicast burst will provide exactly that information to the 
> receiver in the shortest amount of time.
>

---

From: Jinwei Xia <[email-masked]>
Date: Thu, 03 Sep 2009 19:38:44 +0800

Hi Martin,

Yes, I have reviewed this portion in RAMS draft.  The rejection use case
maybe caused by lacking RAMS authorization on RR, or by absence burst stream
on SR, or some other reason. But what's I wonder is another use case,
please check the below bullet, I copy from last mail.

>> In theory, if the current point in multicast transmission is very 
>> close to a TSRAP point, server can ask the receiver to join the 
>> multicast right away (rather than starting a burst).

If the "server" is RS, I agree that receiver can be indirectly asked to join
multicast upon receiving rejection message from RS. However, how did RS
learn the current point is adjacent to TSRAP? RAMS-R does not provide such
information. 

Anyway, your response partly answers my question. Thank you!  :-)

BR

Jinwei

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Martin Ellis
> Sent: Thursday, September 03, 2009 6:21 PM
> To: Jinwei Xia
> Cc: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [AVT] Open issues in the RAMS draft
> 
> Hi,
> 
> Wouldn't this just be RS rejecting the RAMS request (via a 
> RAMS-I message)?
> 
> From Section 6.2, step 2:
>        If RS cannot provide a rapid acquisition service, RS 
> rejects the
>        request and informs RR immediately via an RAMS-I 
> message.  If RR
>        receives a message indicating that its rapid 
> acquisition request
>        has been denied, it abandons the rapid acquisition attempt and
>        MAY immediately join the multicast session by sending an SFGMP
>        Join message towards its upstream multicast router for the new
>        primary multicast session.
> 
> 
> Martin
> 
> 2009/9/3 Jinwei Xia <[email-masked]>:
> > Hi Ali,
> >
> > Sorry to pick up this thread again, however I am not 
> concern whether 
> > one method overwhelm another, but just hope some questions can be 
> > clarified in belowing description.
> >
> >>
> >> Dedicating the resources to the unicast burst initially and then 
> >> switching to multicast will perform faster acquisition.
> >> In theory, if the current point in multicast transmission is very 
> >> close to a TSRAP point, server can ask the receiver to join the 
> >> multicast right away (rather than starting a burst).
> >
> > what's the specific message sent from server to receiver? This 
> > specific message is spontaneous or is triggered by 
> receiver? And the 
> > "server" is multicast source, RS or some entity else?
> >
> >> One point worth to consider in practice is that in mpeg2-ts video, 
> >> there won't be many "magical" tsrap points (from where you 
> can start 
> >> decoding immediately). Simply starting from an I frame 
> does not cut 
> >> it (as explained in our other draft).
> >> Many other components are required by the decoder, so, 
> almost always 
> >> starting a unicast burst will perform better since the 
> unicast burst 
> >> will provide exactly that information to the receiver in 
> the shortest 
> >> amount of time.
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> >

---

From: Martin Ellis <[email-masked]>
Date: Thu, 3 Sep 2009 11:21:29 +0100

Hi,

Wouldn't this just be RS rejecting the RAMS request (via a RAMS-I message)?

>From Section 6.2, step 2:
       If RS cannot provide a rapid acquisition service, RS rejects the
       request and informs RR immediately via an RAMS-I message.  If RR
       receives a message indicating that its rapid acquisition request
       has been denied, it abandons the rapid acquisition attempt and
       MAY immediately join the multicast session by sending an SFGMP
       Join message towards its upstream multicast router for the new
       primary multicast session.

Martin