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

From: Roni Even GW11514 <[email-masked]>
Date: Tue, 12 May 2009 12:01:47 +0300

Hi,
There was a big support to adopt this work based on the proposed draft.
Bill will be the editor and he will submit the initial draft-ietf-avt-rapid-synchronization-for-rtp-00.
I hope all people who showed interest in the work will participate in the review of this draft so we can move it fast.
Thanks
Roni Even

12/5/09

---

From: David R Oran <[email-masked]>
Date: Tue, 12 May 2009 11:21:42 +0200

Thanks, everyone!

On May 12, 2009, at 11:01 AM, Roni Even GW11514 wrote:

> I hope all people who showed interest in the work will participate  
> in the review of this draft so we can move it fast.
> Thanks
> Roni Even
>
> 12/5/09
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 12 May 2009 09:27:45 -0400

Excellent news Roni.

As discussed during the breakout session and on the list, I suggest we
use the name "draft-ietf-avt-rapid-acquisition-for-rtp-00". We want to
avoid confusion with the other ongoing "synchronization" AVT drafts.

Bill VerSteeg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even GW11514
Sent: Tuesday, May 12, 2009 5:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions
(RAMS) as a working group item

Hi,
There was a big support to adopt this work based on the proposed draft.
Bill will be the editor and he will submit the initial
draft-ietf-avt-rapid-synchronization-for-rtp-00.
I hope all people who showed interest in the work will participate in
the review of this draft so we can move it fast.
Thanks
Roni Even

12/5/09

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 13 May 2009 08:08:10 -0400

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

---

From: Roni Even <[email-masked]>
Date: Wed, 13 May 2009 15:22:10 +0300

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.

For section 7 please send a suggestion to the list since I am not sure that
there was a preferred way to do it.

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

Bill VerSteeg

---

From: Roni Even <[email-masked]>
Date: Wed, 13 May 2009 15:41:30 +0300

Hi,

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.

2. The issue of RTP/RTCP multiplexing should be discussed, is it mandatory
to use it.

3. The issue of FW/NAT traversal for the unicast stream should also be
discussed.

Thanks
Roni Even

-----Original Message-----

Bill VerSteeg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 13 May 2009 16:35:49 -0700

Inline.

> 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,

OK.
 
> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 13 May 2009 16:46:18 -0700

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.

> port specified in this parameter instead of the port offered in the

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

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

Indeed. The NAT section is TBC.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 14 May 2009 09:55:22 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Thursday, May 14, 2009 2:46 AM
To: Roni Even; Bill Ver Steeg (versteb); [email-masked]
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
Sessions(RAMS) as a working group item

Roni,

- 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.

Some comments inline.

> port specified in this parameter instead of the port offered in the

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

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.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 14 May 2009 09:59:05 +0300

Hi Ali,
I would like to see the text about this extensions mechanism. It was not
discussed in the mailing list, what was done in a un-official design team or
breakout session is not binding for a WG document.

If you have a proposal please bring it forward.
It should address the issue of what extensions are allowed, what is the
registration procedure for the two types of extensions , do you need a draft
describing the extension and so on.
It should be discussed before it is added to a working group document.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Thursday, May 14, 2009 2:36 AM
To: Roni Even; Bill Ver Steeg (versteb); [email-masked]
Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP

Inline.

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

OK.
 
> 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

We wanna conclude these issues quickly and address the remaining open items
(you mentioned some of them already) in the next revision.

BR,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 May 2009 07:41:30 -0700

> 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

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2009 11:55 PM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); [email-masked]
> Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions(RAMS) as a working
> group item
> 
> Ali,
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 15 May 2009 10:32:17 -0700

Hi Roni, All,

Here is a diff for sections 7 and 13. 

Comments are welcome.
-acbegen

> Sent: Wednesday, May 13, 2009 11:59 PM

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 21 May 2009 21:38:29 -0400

On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) <[email-masked]>wrote:

> 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.
>

Sorry for responding late, but I have been digging through this.

I would strongly urge that RAMS support unmuxed audio / video. This is
common in certain circumstances, and is probably more common in multicast
RTP than muxed AV. (One use case is multiple audio tracks, such as different
languages, for one  video, another is multiple video encodings, such as
different aspect ratios, for one audio.)

 Marshall

> Bill

---

From: Roni Even <[email-masked]>
Date: Fri, 22 May 2009 07:26:36 +0300

Marshalll,

By multiplexing we are discussing RTP/RTCP multiplex over the unicast stream
and not Audio and video multiplexing.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marshall Eubanks
Sent: Friday, May 22, 2009 4:38 AM
To: Ali C. Begen (abegen)
Cc: Bill Ver Steeg (versteb); Roni Even; [email-masked]
Subject: Re: [AVT] Adopting Rapid Acquisition of Multicast RTP
Sessions(RAMS) as a working group item

On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) <[email-masked]>
wrote:

Roni,

Some comments inline.

 Marshall

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 21 May 2009 22:18:15 -0700

Actually, Marshall has a valid concern. You are right that we are considering RTP/RTCP muxing to ease the NAT traversal. However, there is also this question what happens when the multicast session carries multiple RTP streams. Do we rapidly acquire individual streams or individual RTP sessions or the whole multicast session?

I tried to emphasize this question in my email below and I am looking forward to some input from AVT. Please share your comments.

-acbegen 

> Sent: Thursday, May 21, 2009 9:27 PM
> To: 'Marshall Eubanks'; Ali C. Begen (abegen)
> Cc: Bill Ver Steeg (versteb); [email-masked]
> By multiplexing we are discussing RTP/RTCP multiplex over the unicast stream and not Audio
> and video multiplexing.
> 
> 
> 
> Roni
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
> On Wed, May 13, 2009 at 7:46 PM, Ali C. Begen (abegen) <[email-masked]> wrote:
> 
> Roni,
> 
> - 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.
> 
> 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.
> 
> 
> 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.
> 
> 
> 
> I would strongly urge that RAMS support unmuxed audio / video. This is common in certain
> circumstances, and is probably more common in multicast RTP than muxed AV. (One use case
> is multiple audio tracks, such as different languages, for one  video, another is multiple
> video encodings, such as different aspect ratios, for one audio.)
> 
> 
> 
>  Marshall
> 
> 
> 
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 29 May 2009 15:39:30 -0400

Fellow AVT folks-

We are continuing to solicit comments on the RAMS design points
identified in Ali's email from May 15 (diff enclosed). We have received
some valuable feedback. We hope to have a new draft mid next week, and
will incorporate comments that we receive through Monday or Tuesday in
that draft.

Thanks in advance

Bill VerSteeg

-----Original Message-----
From: Ali C. Begen (abegen) 
Sent: Friday, May 15, 2009 1:32 PM
To: Roni Even; Bill Ver Steeg (versteb); [email-masked]
Subject: RE: [AVT] Adopting Rapid Acquisition of Multicast RTP

Hi Roni, All,

Comments are welcome.
-acbegen