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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 3 Sep 2009 04:30:34 -0700

Right. Rams-i may indicate the rejection of the request. It is of course up to the receiver to join the mcast right away. 

-acbegen

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Jinwei Xia <[email-masked]>
Cc: Ali C. Begen (abegen); [email-masked] <[email-masked]>
Sent: Thu Sep 03 03:21:29 2009
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.
>
>>
>> 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.
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>