Re: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working group item

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> My understanding is that having a single physical entity is the assumption
> of this work and any other architecture is for further study.

Indeed, that is the assumption. I should have said that even when it is the same entity, the ports could be different.

-acbegen

> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Wednesday, May 13, 2009 11:55 PM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); avt at ietf.org
> Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working
> group item
> 
> Ali,
> 
> "This is tricky. Remember that the RAMS request message goes to the Feedback
> Target of the primary multicast session but the burst comes from the
> retransmission server. They could be the same entity or different ones. Any
> solution should consider this in its design."
> 
> From the draft
> 
> " Editor's note:  As stated above, FT, Burst Source and Retransmission
>    Source are logical entities.  For efficiency and simplicity, they MAY
>    be implemented by a single physical Retransmission Server (RS).  In a
>    number of places throughout this document we assume (and explicitly
>    state so) that all three are implemented by the same physical entity
>    and therefore share the same IP address and the port number.  The
>    authors look to the AVT community for recommendations on whether this
>    is sufficient or the mechanism has to explicitly address other
>    topologies where FT, Burst Source and Retransmission Source are not
>    co-located."
> 
> My understanding is that having a single physical entity is the assumption
> of this work and any other architecture is for further study.
> 
> BTW: figure 2 has feedback target as part of the retransmission server, I
> think that you meant retransmission source for the burst.
> 
> Roni
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ali C.
> Begen (abegen)
> Sent: Thursday, May 14, 2009 2:46 AM
> To: Roni Even; Bill Ver Steeg (versteb); avt at ietf.org
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
> 
> Roni,
> 
> There are a few other important issues that we need WG input on:
> 
> - The scenarios where there are multiple SSRC-multiplexed RTP streams in a
> single RTP session. Will RAMS apply to individual streams or the whole
> session? Similarly, what happens when the same multicast session carries
> multiple RTP sessions (same multicast address but different ports). Clearly,
> such cases will exist. We have a draft text that discusses different
> scenarios and what needs to be done in each such cases. But before we move
> forward, we would like to hear WG input. Managing multiple bursts
> simultaneously requires some details.
> 
> - The security section needs to be completed as well as the NAT section.
> 
> Some comments inline.
> 
> > I have some others issues to add to this list
> >
> > 1. I suggest to add to the RAMS request an optional parameter that will
> > allow the receiver to request that the unicast stream will be sent to the
> a
> > port specified in this parameter instead of the port offered in the
> > announcement.
> 
> This is tricky. Remember that the RAMS request message goes to the Feedback
> Target of the primary multicast session but the burst comes from the
> retransmission server. They could be the same entity or different ones. Any
> solution should consider this in its design.
> 
> > 2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory
> > to use it.
> 
> It is not mandatory. Even if we made it mandatory, it would not help us with
> the issue you describe above. Muxing only simplifies NAT traversal.
> 
> > 3. The issue of FW/NAT traversal for the unicast stream should also be
> > discussed.
> 
> Indeed. The NAT section is TBC.
> 
> -acbegen
> 
> >
> > Thanks
> > Roni Even
> >
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill
> > Ver Steeg (versteb)
> > Sent: Wednesday, May 13, 2009 3:08 PM
> > To: avt at ietf.org
> > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> > Sessions(RAMS) as a working group item
> >
> >
> >
> > We submitted version -00 of "draft-ietf-avt-rapid-acquisition-for-rtp".
> > This is basically a name change from
> > "draft-versteeg-avt-rapid-synchronization-for-rtp-03" to avoid confusion
> > with other pending "synchronization" drafts.
> >
> > There were some issues remaining from -03 version that have already been
> > identified on the list and technical breakout session. We are planning
> > to address these issues in the next version of the draft.
> >
> > We hope to address the following areas in the next revision of the
> > draft:
> >
> > - Section 7 - Define a method for vendor-specific and generic extensions
> > to RAMS, lay out the intent to use FMT==6 for all messages and to have
> > an (extensible) enumeration of the RAMS sub-FMTs
> > - Section 8 - Elaborate SDP to describe the various use cases for RAMS
> > - Section 13 - Define a single registry (FMT==6) for all RAMS
> > transactions, and then define Sub-FMT Values for RAMS Messages. Also
> > define an extensible RAMS TLV space registry
> >
> > - We need to make some typographical corrections, mostly changing from
> > RMS to RAMS.
> > - We need to formalize the TLV definitions and extensions (both vendor
> > and private extensions)
> > - We need to register FMT=6 with IANA for RAMS and use sub-FMT values to
> > identify various RAMS messages
> > - We need to clarify the SDP section based on the earlier discussion.
> > The SDP example is still declarative and we are looking forward to
> > include more examples as we move forward.
> > - The IANA concerns section needs to be updated to reflect how to extend
> > the RAMS protocol.
> > - The unicast/multicast addresses need to be fixed according to the
> > idnits tool.
> >
> > Are there other issues that we need to address in the next revision of
> > the draft? The authors would like to address these high priority issues
> > in the next few days, so timely feedback would be appreciated.
> >
> >
> > Bill VerSteeg
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt