Subject: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-15.txt

From: [email-masked]
Date: Tue, 7 Sep 2010 07:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : Unicast-Based Rapid Acquisition of Multicast RTP Sessions
	Author(s)       : B. Ver Steeg, et al.
	Filename        : draft-ietf-avt-rapid-acquisition-for-rtp-15.txt
	Pages           : 55
	Date            : 2010-09-07

When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process
any data sent in the multicast session.  Depending on the join time,
length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to
as the Acquisition Delay, varies and can be large.  This is an
undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay.  In this
method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the multicast
stream.  This unicast RTP flow can be transmitted at a faster than
natural bitrate to further accelerate the acquisition.  The
motivating use case for this capability is multicast applications
that carry real-time compressed audio and video.  However, the
proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a
problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for-rtp-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 8 Sep 2010 17:59:35 +0200

I've been checking through the -12 through -15 versions that exists after RAI AD comments.

I had the following comments (mostly minor or editorial).

Section 6.2:

           Upon receiving a reject response indicating a transient
           problem such as insufficient BRS or network resources, if the
           RTP_Rx wants to retry sending the same request, it MUST
           follow the RTCP timer rules of [RFC4585] to allow the
           transient problems go away.  However, if the reject response
           indicates a non-transient problem (such as the ones reported
           by response codes 504, 505 and 506), the RTP_Rx MUST NOT
           attempt a retry.

Section 6.2:

   4.   Unicast Burst:  For the primary multicast stream(s) for which
        the request is accepted, the BRS starts sending the unicast
        burst(s) that comprises one or more RTP retransmission packets
        sent in the unicast burst RTP session.  In addition, in some
        applications the BRS can send preamble information data to the
        RTP_Rx in addition to the requested burst to prime the media
        decoder(s).  However, for the BRS to send the preamble
        information in a particular format, explicit signaling from the
        RTP_Rx is required.  In other words, the BRS MUST NOT send
        preamble information in a particular format unless the RTP_Rx
        has signaled support for that format in the RAMS-R message
        through a public or private extension as defined in Section 7.1.

I suggest the following minor rewording (two thirds of the way down):

   4.   Unicast Burst:  For the primary multicast stream(s) for which
        the request is accepted, the BRS starts sending the unicast
        burst(s) that comprises one or more RTP retransmission packets
        sent in the unicast burst RTP session.  In addition, in some
        applications the BRS can send preamble information data to the
        RTP_Rx in addition to the requested burst to prime the media
        decoder(s).  However, for the BRS to send the preamble
        information in a particular format, explicit signaling from the
        RTP_Rx needs to occur first.  The BRS MUST NOT send
        preamble information in a particular format unless the RTP_Rx
        has signaled support for that format in the RAMS-R message
        through a public or private extension as defined in Section 7.1.

I suggest a minor change to:

           Upon receiving a reject response indicating a transient
           problem such as insufficient BRS or network resources, if the
           RTP_Rx wants to retry sending the same request, the RTP_Rx MUST
           follow the RTCP timer rules of [RFC4585] to allow the
           transient problems go away.  However, if the reject response
           indicates a non-transient problem (such as the ones reported
           by response codes 504, 505 and 506), the RTP_Rx MUST NOT
           attempt a retry.

Section 6.2:

   5.   Updated Request:  The RTP_Rx MAY send an updated RAMS-R message
        (as unicast feedback in the primary multicast RTP session) with
        a different value for one or more fields of an earlier RAMS-R
        message.  If there is already a burst planned for or being
        transmitted to a particular RTP_Rx for a particular stream, the
        newly arriving RAMS-R is an updated request; otherwise, it is a
        new request.  It is also possible that the RTP_Rx has sent an
        improperly formatted RAMS-R message or used an invalid value in
        the RAMS-R message.  If notified by the BRS using a 4xx-level
        response code (as defined in Section 11.6), the RTP_Rx MAY re-
        send its corrected request only after following the timing rules
        of [RFC4585].

The final sentence now has the conditionals split by the action. Reword as follows:

   5.   Updated Request:  The RTP_Rx MAY send an updated RAMS-R message
        (as unicast feedback in the primary multicast RTP session) with
        a different value for one or more fields of an earlier RAMS-R
        message.  If there is already a burst planned for or being
        transmitted to a particular RTP_Rx for a particular stream, the
        newly arriving RAMS-R is an updated request; otherwise, it is a
        new request.  It is also possible that the RTP_Rx has sent an
        improperly formatted RAMS-R message or used an invalid value in
        the RAMS-R message.  If notified by the BRS using a 4xx-level
        response code (as defined in Section 11.6) and only after following the timing rules
        of [RFC4585], the RTP_Rx MAY re-
        send its corrected request.

Section 7.1:

   The vendor-neutral and private extensions MAY exist in any RAMS
   message.  Such extensions MUST be placed after the mandatory fields
   and mandatory TLV elements (if any), and MAY be placed in any order.
   In a RAMS message, multiple TLV elements with the same Type value
   MUST NOT exist.

   The support for extensions (unless specified otherwise) is OPTIONAL.
   An RTP_Rx or BRS receiving a vendor-neutral or private extension that
   it does not understand MUST ignore that extension. 

If the first sentence is to be normative, then it needs to be stated for both sender (the receiver requirement is stated in the second sentence of the second quoted paragraph above). I would suggest the following revisions of the first of these paragraphs (getting rid of passive requirements as well to make the conformance clearer.

   An RTP_Rx or BRS MAY include vendor-neutral and private extensions in any RAMS
   message.  The RTP_Rx or BRS MUST place such extensions after the mandatory fields
   and mandatory TLV elements (if any), and MAY place such extension in any order.
   The RTP_Rx or BRS MUST NOT include multiple TLV elements with the same Type value
   in a RAMS message.

I believe this still has the same technical sense as the original text.

Section 7.3

      When the BRS serves two or more bursts and sends a separate RAMS-I
      message for each burst, the join times specified in these RAMS-I
      messages SHOULD correspond to more or less the same time instant,
      and the RTP_Rx sends the SFGMP Join message based on the earliest
      join time.

Here the "should" has become a "SHOULD". I am left wondering in what direction the SHOULD applies in terms of implementations not conforming. Does it mean any, or more than one of:

-	that certain join times will not follow this rule at all, or 

-	is it just emphasising that the join times are more or less the same time instant, but will not be exactly the same time instant, or 

-	is it a relaxation of the statement "and the RTP_Rx sends the SFGMP Join message based on the earliest join time". 

Can we try and make this clearer, assuming we don't really mean MUST in the first place.

Section 11.6

It is not clear to me whether the content of 11.6.1 appears in the IANA registration or not. If it does, it should be integrated in the table in section 11.6. If it does not, then it should be placed elsewhere than section 11, which should contain just the IANA actions.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, September 07, 2010 3:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D 
> Action:draft-ietf-avt-rapid-acquisition-for-rtp-15.txt
> 
> 	Filename        : 
> draft-ietf-avt-rapid-acquisition-for-rtp-15.txt
> 	Pages           : 55
> 	Date            : 2010-09-07
> 
> When an RTP receiver joins a multicast session, it may need 
> to acquire and parse certain Reference Information before it 
> can process any data sent in the multicast session.  
> Depending on the join time, length of the Reference 
> Information repetition (or appearance) interval, size of the 
> Reference Information as well as the application and 
> transport properties, the time lag before an RTP receiver can 
> usefully consume the multicast data, which we refer to as the 
> Acquisition Delay, varies and can be large.  This is an 
> undesirable phenomenon for receivers that frequently switch 
> among different multicast sessions, such as video broadcasts.
> 
> In this document, we describe a method using the existing RTP 
> and RTCP protocol machinery that reduces the acquisition 
> delay.  In this method, an auxiliary unicast RTP session 
> carrying the Reference Information to the receiver 
> precedes/accompanies the multicast stream.  This unicast RTP 
> flow can be transmitted at a faster than natural bitrate to 
> further accelerate the acquisition.  The motivating use case 
> for this capability is multicast applications that carry 
> real-time compressed audio and video.  However, the proposed 
> method can also be used in other types of multicast 
> applications where the acquisition delay is long enough to be 
> a problem.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 12 Sep 2010 15:43:30 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, September 08, 2010 7:00 PM
> To: IETF AVT WG
> Cc: [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-15.txt
> 

"needs to occur first" does not fully replace "is required" IMO.

>            RTP_Rx wants to retry sending the same request, the RTP_Rx MUST

Replace "it"? I think the intent is pretty clear based on the earlier part of the sentence. This can be fixed during the editing.

>         send its corrected request.

This can also be left to editing.
 
> If the first sentence is to be normative, then it needs to be stated for both sender (the receiver requirement is stated in the
> second sentence of the second quoted paragraph above). I would suggest the following revisions of the first of these
> paragraphs (getting rid of passive requirements as well to make the conformance clearer.
> 

OK.
 
> Here the "should" has become a "SHOULD". I am left wondering in what direction the SHOULD applies in terms of
> implementations not conforming. Does it mean any, or more than one of:
> 

I think we spent more than necessary time on this. I am not sure why you are trying to read too much into this. If the join times are not corresponding to a more or less the same time, it means the BRS implementation is broken or something is seriously wrong. They can't necessarily be the exact same time due to the nature of individual burst streams. So, we cannot use "MUST" or "must".
 
> Section 11.6
> 
> It is not clear to me whether the content of 11.6.1 appears in the IANA registration or not. If it does, it should be integrated in
> the table in section 11.6. If it does not, then it should be placed elsewhere than section 11, which should contain just the IANA
> actions.

It does not. We can move this to a new section (which is I think an overkill) in the editing stage.

Thanks for the comments. I think all these are minor and editorial and could be addressed after the IESG call. But, do let me know if you (or Robert) want a revision before then.

-acbegen

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Sep 2010 10:47:20 -0500

I've requested IETF LC for version 15 of the draft - that should appear on IETF Announce shortly.

Ali - Please treat Keith's comments as IETF LC comments. We will have an opportunity to revise the draft
based on these and any other Last Call comments received before the draft moves into IESG Evaluation.

Thanks,

RjS

On Sep 12, 2010, at 5:43 PM, Ali C. Begen (abegen) wrote:

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt