[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Adopting Rapid Acquisition of Multicast RTPSessions(RAMS) as a working group item
Ingemar-
I think current RAMS draft should be focused on unicast acceleration
methods. It is not clear (at least to me) that there is enough
concurrency in RAMS requests to drive a multicast-based acceleration
solution. I do have an open mind on this, and could be convinced by data
showing a high degree of fine-grained concurrency in time-sensitive join
activity.
Having said that I do not see a current need for a multicast solution -
we should not preclude a subsequent multicast solution, and an analysis
of how one would implement a multicast solution using the RAMS
primitives would be a good test case for the extensibility of the
protocol. Using sub-types for RAMS-R, RAMS-I and RAMS-T (and reserving
additional subtypes) is a step in the right direction. Defining an
extensible TLV mechanism, which could be used to describe the behavior
of the proposed multicast enhancements would also be prudent.
In summary, I am broadly OK with having a baseline unicast RAMS solution
that allows for extensions. A wide variety of extensions should be
possible, and if a multicast extension eventually makes sense we should
be sure that the protocol design supports such an extension.
Bill verSteeg
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Ingemar Johansson S
Sent: Friday, May 15, 2009 9:45 AM
To: avt at ietf.org
Cc: Ingemar Johansson S; Bill Ver Steeg (versteb); Even.roni at huawei.com
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast
RTPSessions(RAMS) as a working group item
Hi
As the draft name does not mention multicast or unicast I would like to
have the door open for later inclusion of a description of the multicast
version or RAMS descibed in
http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt
into the WG draft.
I plan to submit an update of said draft relatively soon which will
contain more info regarding signalling and overall functionality.
As a consequence of this (and of course, if the group agrees to merge
the drafts) there may be a need for a field containing various flags in
the header, see
http://www.ietf.org/mail-archive/web/avt/current/msg11079.html
For more detailed info
Regards
Ingemar
> ------------------------------
>
> Message: 2
> Date: Wed, 13 May 2009 16:35:49 -0700
> From: "Ali C. Begen (abegen)" <abegen at cisco.com>
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
> Sessions(RAMS) as a working group item
> To: "Roni Even" <Even.roni at huawei.com>, "Bill Ver Steeg
> (versteb)"
> <versteb at cisco.com>, <avt at ietf.org>
> Message-ID:
>
> <04CAD96D4C5A3D48B1919248A8FE0D54094C3DBF at xmb-sjc-215.amer.cisco.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> Inline.
>
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of Roni Even
> > Sent: Wednesday, May 13, 2009 5:22 AM
> > To: Bill Ver Steeg (versteb); avt at ietf.org
> > Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast
> RTP Sessions(RAMS) as a working
> > group item
> >
> > Bill,
> > Any changes that are not editorial should be presented to
> the list before
> > they are added to the draft.
> >
> > The changes for section 8 and 13 can be added to the draft.
>
> OK.
>
> > For section 7 please send a suggestion to the list since I
> am not sure that
> > there was a preferred way to do it.
>
> As we proposed previously (actually since version -00), we
> are using TLV elements to provide the extension mechanism and
> avoid the problems associated with using special values in
> various fields. In the update, we are saying that the TLV
> types will be registered with IANA in a new registry. Some of
> the available type space is reserved for vendor-neutral
> extensions whereas the rest is for private extensions. We
> briefly outline the requirements for registering the
> vendor-neutral extensions.
>
> As proposed by Ingemar previously in the breakout session, we
> are now using sub FMT fields to specify the individual RAMS
> messages (request, information and termination). So, for the
> message format we have something like:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | SFMT=1 | Optional TLV-encoded Fields |
> +-+-+-+-+-+-+-+-+ |
> : Optional TLV-encoded Fields (and Padding, if needed) :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Further RAMS message types could be defined in the future, if needed.
>
> We wanna conclude these issues quickly and address the
> remaining open items (you mentioned some of them already) in
> the next revision.
>
> BR,
> -acbegen
>
> > Thanks
> > Roni Even
> > AVT co-chair
> >
> > -----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