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

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 15 May 2009 15:45:02 +0200

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)" <[email-masked]>
> Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast	RTP
> 	Sessions(RAMS) as a working group item
> To: "Roni Even" <[email-masked]>,	"Bill Ver Steeg 
> (versteb)"
> 	<[email-masked]>, <[email-masked]>
> Message-ID:
> 	
> <[email-masked]>
> Content-Type: text/plain;	charset="Windows-1252"
> 
> Inline.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roni Even
> > Sent: Wednesday, May 13, 2009 5:22 AM
> > To: Bill Ver Steeg (versteb); [email-masked]
> > 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bill
> > Ver Steeg (versteb)
> > Sent: Wednesday, May 13, 2009 3:08 PM
> > To: [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> ------------------------------

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 15 May 2009 10:49:55 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Ingemar Johansson S
Sent: Friday, May 15, 2009 9:45 AM
To: [email-masked]
Cc: Ingemar Johansson S; Bill Ver Steeg (versteb); [email-masked]
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast
RTPSessions(RAMS) as a working group item

Hi

Regards
Ingemar