Subject: [AVT] New Version: draft-versteeg-avt-rapid-synchronization-for-rtp-02

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 9 Mar 2009 13:42:13 -0700

An updated version of our draft is available at:
http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza
tion-for-rtp-02.txt

As usual, comments are welcome.
-acbegen 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 

A new version of I-D,
draft-versteeg-avt-rapid-synchronization-for-rtp-02.txt has been
successfuly submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-versteeg-avt-rapid-synchronization-for-rtp
Revision:	 02
Title:		 Unicast-Based Rapid Synchronization with RTP Multicast
Sessions
Creation_date:	 2009-03-09
WG ID:		 Independent Submission
Number_of_pages: 32

Abstract:
When a 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 interval, size of the Reference
Information as well as the application and transport properties, the
time lag before a receiver can usefully consume the multicast data,
which we refer to as the synchronization delay, varies and may 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
synchronization delay.  In this method, an auxiliary unicast RTP
session carrying the Reference Information to the receiver precedes/
accompanies the multicast flow.  This unicast flow may be transmitted
at a faster than natural rate to further accelerate the
synchronization.  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 synchronization delay is long
enough to be a problem.

The IETF Secretariat.

---

From: "Ye-Kui Wang" <[email-masked]>
Date: Tue, 10 Mar 2009 01:30:30 -0400

Hi Ali, All,

Some comments (text or just section number goes first, the corresponding
comment follows). 

[start]

   Section 1.
   In some other cases, the Reference Information is not
   contiguous in the flow but dispersed over a large period, which
   forces the receiver to wait for all of the Reference Information to
   arrive before starting to process the rest of the data.

Could you please give an example of dispersed Reference Information? Are
there any benefits for dispersing Reference Information. The drawback is
clear; it introduces additional delay for tuning-in. 

   Section 1.
   It is also worth noting that in order to issue
   the initial RTCP message to the feedback target, the SSRC of the
   session to be joined must be known prior to any packet reception, and
   hence, needs to be signaled out-of-band (or in-band). 

Shouldn't "(or in-band)" be removed, as in-band signaling of SSRC seems
impossible anyway, since upon joining a new session the receiver has never
received a packet?

   Section 5.
   In particular, the system needs operate within a number of constraints.

"needs operate" -> "needs to operate".

   Fig. 2.
   
The arrow for the unicast RTP flow from RS to router is missing.

   Fig. 3.

"RMR-R" -> "RMS-R" 
"RMR-T"-> "RMS-T"

   Section 6.2, step 1. 
       Also note that since no RTP packets have been received yet for this
       session, the SSRC must be obtained out-of-band or in-band.

Same as above, "or in-band" should be removed.

   Section 6.2, step 2. 
       If RR receives a message indicating that its rapid synchronization
       request has been denied, it abandons the rapid synchronization
       attempt and MAY immediately join the multicast session by sending
       an IGMP Join message [RFC3376] to its upstream multicast router
       for the new multicast session.
 
Why "MAY", instead of "MUST" or "SHOULD", is used here?

   Section 6.2, step 2. 
       If RS accepts the request, it sends an RMS-I message to RR
       (before commencing the burst or during the burst) that comprises
       fields that can be used to describe the burst that will be sent
       by RS (e.g., the bitrate and the size of the burst).

To be more consistent with the syntax (and hence more instructive), "the
bitrate and the size of the burst" should be changed to "the maximum bitrate
and the duration of the burst".

   Section 6.2, step 2. 
       The burst duration may be calculated by RS, and its value may be
       updated by messages received from RR.

What messages from RR may be used to update the bust duration?

   Section 7. 
   o  Length:  A two-octet field that indicates the length of the Value
      field.

The unit is missing. In octets?

   Section 7.1.

The unit of Min RMS Buffer Fill Requirement and Max RMS Buffer Fill
Requirement is ms. Are the values measured in the media presentation
timeline? How does the RS utilize these values?

   Section 7.2.

What is the essential difference between Response equal to 0 and Response
equal to 2 (e.g. from implementation point of view)?

   Section 7.2.
      Extended RTP Seqnum of the First Burst Packet (32 bits):  The
      extended RTP sequence number of the first packet that will be sent
      as part of the rapid synchronization in the burst.  This allows RR
      to know if one or more packets have been dropped at the beginning
      of the burst. 32-bit extended RTP sequence number is constructed
      by putting the 16-bit RTP sequence number in the lower two bytes
      and octet 0's in the higher two bytes.

It should be clarified that "the 16-bit RTP sequence number" is not the RTP
sequence number of the packet in the burst stream.
Why does this field need to be 32 bits? You expect that there might be more
than 2^16-1 packets lost in the beginning of the burst?

   Section 7.2.

How does RR utilize the Max Burst Bitrate conveyed in the RMS-I message?

   Section 7.2.
   The length of the feedback message MUST be set to 2+n, where n is the
   number of fields contained in the message.   

This is incorrect, as not all fields in RMS-I are of 32 bits.

   Section 7.2.
      Extended RTP Seqnum of the First Multicast Packet (32 bits):  The
      extended RTP sequence number of the first packet received from the
      multicast session.

How to set the value of the higher two bytes of this field?

[end]

BR, YK

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Monday, March 09, 2009 4:42 PM
> To: IETF AVT WG
> Subject: [AVT] New Version: 
> draft-versteeg-avt-rapid-synchronization-for-rtp-02
> 
> draft-versteeg-avt-rapid-synchronization-for-rtp-02.txt has 
> been successfuly submitted by Ali Begen and posted to the 
> IETF repository.
> 
> When a 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 
> interval, size of the Reference Information as well as the 
> application and transport properties, the time lag before a 
> receiver can usefully consume the multicast data, which we 
> refer to as the synchronization delay, varies and may be 
> 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 synchronization delay.  In this method, an 
> auxiliary unicast RTP session carrying the Reference 
> Information to the receiver precedes/ accompanies the 
> multicast flow.  This unicast flow may be transmitted at a 
> faster than natural rate to further accelerate the 
> synchronization.  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 
> synchronization delay is long enough to be a problem.
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: David R Oran <[email-masked]>
Date: Wed, 11 Mar 2009 08:01:35 -0400

On Mar 10, 2009, at 1:30 AM, Ye-Kui Wang wrote:

> Could you please give an example of dispersed Reference Information?
MPEG2 Transport Streams. The PAT/PMT, ECMs, etc. are dispersed and may  
occur considerably earlier in the stream than the content that the  
decoder needs to render.

> Are
Yes, there WERE lots of (potential) advantages - lower bit rate, less  
decoder memory, transrating and multiplxing flexibility, etc. that  
were important at the time MPEG was designed. If you're asking whether  
it would be a good tradeoff to disperse such information when  
designing a NEW payload format for multicast use with RTP, I suspect  
not but that's not terribly relevant as we are designing a scheme  
meant to work with all the existing payload formats, not just new ones.

> impossible anyway, since upon joining a new session the receiver has  
Good catch - clearly, the SSRC can't be signaled in-band in the  
multicast session you want to join because that recurses back to the  
original problem. I think the intend was that it could be "in-band" in  
some auxiliary stream the receiver was already joined to. I can see  
two ways to fix this:
a) just delete "in-band"
b) reword to say "...and hence needs to be either signaled out-of- 
band, or otherwise communicated to the receiver in advance of the  
initiation of the rapid multicast synchronization operation".

> "needs operate" -> "needs to operate".
I'll let Ali fix this - he's holding the pen.

> Same as above, "or in-band" should be removed.
Ditto.

> Why "MAY", instead of "MUST" or "SHOULD", is used here?
No, it could decide to fail the whole thing and stay joined to the  
prior session, or anything else it wants to do.
Joining the new multicast is probably the most likely policy, but  
there's no reason to be more restrictive than MAY.

> and the duration of the burst".
ACK - I think that would be consistent.

> The unit is missing. In octets?
Yes. probably worth stating. Perhaps the best way to cover this is to  
have a general section on the TLV encoding scheme which says lengths  
are in octets, and also whether they include or exclude the overhead  
bytes. It's been done both ways in other protocols.

> timeline? How does the RS utilize these values?
No, i don't think so, since that would couple the scheme to the  
semantics of the payload format too much. I think they are in RTP  
timestamp units, converted to milliseconds.

> than 2^16-1 packets lost in the beginning of the burst?
General RTCP practice is to use extended sequence numbers to avoid  
ambiguity with wrapping. In this case we may have an issue however,  
because to provide an extended sequence number you have to have gotten  
an SR from the source. For the delayed RTCP-XR messages this is fine,  
but for the control-loop packets like RMS-T it needs to be worked out.

> How does RR utilize the Max Burst Bitrate conveyed in the RMS-I  
Not sure I understand the question. It uses it to figure out the  
amount of buffering needed, among other things.

> This is incorrect, as not all fields in RMS-I are of 32 bits.
Good catch - hangover from the prior encoding scheme that used fixed- 
length fields.

> How to set the value of the higher two bytes of this field?
 From the SR you get after joining the multicast.

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 11 Mar 2009 11:45:39 -0400

Ye-Kui Wang-

Thanks for your detailed review of the draft. We will be setting up
break-out session during the next IETF meeting to refine this draft. If
you are attending IETF, we would also like to have your input during
that break out session. We will be posting a meeting notice 

In-line comments, bracketed by "bvs"- 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Tuesday, March 10, 2009 1:31 AM
To: Ali C. Begen (abegen); 'IETF AVT WG'
Subject: Re: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Hi Ali, All,

[start]

   Section 1.

---bvs --- The initial design motivation for this draft was RTP
encapsulated MPEG2TS audio/video flows. In these flows, the largest item
of "reference information" is the I-frame. There is other reference
material distributed throughout the payload, including PAT/PMT/CAT and
ECMs. In DSMCC data carousels, there is also a lot of structure at the
"beginning of the file structure". Legacy (often proprietary) command
and control protocols often have authentication and scoping information
sprinkled dropout the data flow.

   Section 1.

Shouldn't "(or in-band)" be removed, as in-band signaling of SSRC seems
impossible anyway, since upon joining a new session the receiver has
never received a packet?
---bvs --- agreed. "In-band" is an over-loaded term that has different
meaning in different contexts. We should strike in-band.
 
   Section 5.
   In particular, the system needs operate within a number of
constraints.

---bvs ---- agreed

   Fig. 2.

   Fig. 3.

"RMR-R" -> "RMS-R" 
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1. 
       Also note that since no RTP packets have been received yet for
this
       session, the SSRC must be obtained out-of-band or in-band.

---bvs --- will fix

   Section 6.2, step 2. 
       If RR receives a message indicating that its rapid
synchronization

---bvs --- The behavior is totally up to the desire of the client. I can
think of quite a few cases where the client would rather join another
stream (or no stream). If the information is stale after a second or
two, the receiver would not want to receive it. The user was "channel
surfing" and had gone on to another channel, etc. It MAY want to tune to
this stream, or it MAY want to tune to another stream, or it MAY want to
do nothing.

   Section 6.2, step 2. 

To be more consistent with the syntax (and hence more instructive), "the
bitrate and the size of the burst" should be changed to "the maximum
bitrate and the duration of the burst".

--- bvs --- will fix

   Section 6.2, step 2. 

   Section 7. 

--- bvs --- will fix, bytes/octets is almost certainly the correct unit.

   Section 7.1.

--- bvs -- The authors have gone back and forth on this issues a few
times. The intent is to have the RR describe its buffering requirements
to the RS. The RS does not know if the RR is a cell phone or a
super-computer, and typically does not know the capabilities (de-jitter,
decrypt, decode, application layer processing) and thus buffering
requirements of the client. Rather than encapsulate all of the
application-layer complexity in a transaction from RR to RS, we decided
to have the RR tell the RS the minimum and maximum amount of data it
considered useful. We had been assuming that the metric was "ms at the
nominal rate", but this requires more thought - particularly if we want
to cover VBR flows.

   Section 7.2.

What is the essential difference between Response equal to 0 and
Response equal to 2 (e.g. from implementation point of view)?

   Section 7.2.

It should be clarified that "the 16-bit RTP sequence number" is not the
RTP sequence number of the packet in the burst stream.
Why does this field need to be 32 bits? You expect that there might be
more than 2^16-1 packets lost in the beginning of the burst.

--- bvs --- we have gone back and forth on "extended sequence numbers"
vs "sequence numbers" as well. In earlier versions of the draft, we
specified that if the extended portion of the sequence number was not
known it would be sent as zeros". In my opinion, the extended sequence
numbers are of limited value due to the bit rates of the streams
envisioned as well as the short duration of the acceleration bursts.
However, we stayed with extended sequence numbers in order to be
consistent the intent of the RTP design. There are some extreme cases
(uncompressed HD video with large RTT) in which extended sequence
numbers would be useful. The authors have not seen compelling arguments
for either case, so we welcome feedback on this point.

   Section 7.2.

--- bvs -- This is not specified in the document, as it is out of scope.
However, the client can use this value to assist it in managing buffer
levels.

   Section 7.2.

---bvs will fix. This may also change if we go to TLV encoding

   Section 7.2.

--- bvs -- need to clarify in document - often set to all zeros, but
sometimes set to the correct value as received in the SR.

[end]

BR, YK

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Ali C. Begen (abegen)
> broadcasts.  In this document, we describe a method using the existing

> RTP and RTCP protocol machinery that reduces the synchronization 
> delay.  In this method, an auxiliary unicast RTP session carrying the 
> Reference Information to the receiver precedes/ accompanies the 
> multicast flow.  This unicast flow may be transmitted at a faster than

> natural rate to further accelerate the synchronization.  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 synchronization delay is long enough to be a problem.
>  
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 Mar 2009 18:10:54 +0200

Bill,
I hope that this breakout session is open, in this case I would suggest that
you will give people a couple of optional time slots to select.
Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Ver Steeg (versteb)
Sent: Wednesday, March 11, 2009 5:46 PM
To: Ye-Kui Wang; Ali C. Begen (abegen); IETF AVT WG
Subject: Re: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02

Ye-Kui Wang-

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

Hi Ali, All,

[start]

   Section 1.

   Section 1.

   Section 5.

   Fig. 2.

   Fig. 3.

"RMR-R" -> "RMS-R" 
"RMR-T"-> "RMS-T"

---bvs --- will fix

   Section 6.2, step 1. 

---bvs --- will fix

   Section 6.2, step 2. 

   Section 6.2, step 2. 

--- bvs --- will fix

   Section 6.2, step 2. 

   Section 7. 

   Section 7.1.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

   Section 7.2.

[end]

BR, YK

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Mar 2009 10:30:13 -0700

Hi YK,

I saw your email when Dave responded. For some reason, your email has never arrived in my outlook. Anyway, looks like your questions have already been dealth with.

Thanks for the detailed review.
-acbegen 

> From: Dave Oran (oran) 
> Sent: Wednesday, March 11, 2009 5:02 AM
> To: Ye-Kui Wang
> Cc: Ali C. Begen (abegen); 'IETF AVT WG'
> Subject: Re: [AVT] New Version: 
> >   session to be joined must be known prior to any packet 
> reception,  
> > and
> > never
> > To be more consistent with the syntax (and hence more 
> instructive),  
> > "the
> > Response
> >      as part of the rapid synchronization in the burst.  
> This allows  
> > RR
> > It should be clarified that "the 16-bit RTP sequence 
> number" is not  
> > the RTP
> > Why does this field need to be 32 bits? You expect that 
> there might  
> > be more
> >   The length of the feedback message MUST be set to 2+n, 
> where n is  
> > the
> >      extended RTP sequence number of the first packet 
> received from  
> > the
> >      multicast session.
> >

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 11 Mar 2009 18:48:58 -0400

Thanks David and Bill for your replies. I am replying in below only to those
items that have been missed (in both replies) or that I would like to make
further comments. For other items, I am happy with answers from either or
both of you. 

> > What messages from RR may be used to update the bust duration?

Missed. I guess you meant "updated by RMS-I messages", which are sent by RS
and received by RR?

> No, i don't think so, since that would couple the scheme to 
> the semantics of the payload format too much. I think they 
> are in RTP timestamp units, converted to milliseconds.

OK, we are aligned, as to me media presentation timeline is the RTP
timestamp timeline. If not, what is "media presentation timeline" in your
mind?

> > Response equal to 2 (e.g. from implementation point of view)?

Missed. As you both mentioned in your replies to my another comment, that
the RR may choose to do something else than to immediately join the
multicast. Why not just combine Response equal to 0 (request rejected) and
Response equal to 2 (join multicast)?

> > It should be clarified that "the 16-bit RTP sequence number" is not 
> > the RTP sequence number of the packet in the burst stream.
> there might be 
> > more than 2^16-1 packets lost in the beginning of the burst?
> >
> [David] General RTCP practice is to use extended sequence numbers to 
> avoid ambiguity with wrapping. In this case we may have an 
> issue however, because to provide an extended sequence number 
> you have to have gotten an SR from the source. For the 
> delayed RTCP-XR messages this is fine, but for the 
> control-loop packets like RMS-T it needs to be worked out.
> 
> vs "sequence numbers" as well. In earlier versions of the 
> draft, we specified that if the extended portion of the 
> sequence number was not known it would be sent as zeros". In 
> my opinion, the extended sequence numbers are of limited 
> value due to the bit rates of the streams envisioned as well 
> as the short duration of the acceleration bursts.
> However, we stayed with extended sequence numbers in order to 
> be consistent the intent of the RTP design. There are some 
> extreme cases (uncompressed HD video with large RTT) in which 
> extended sequence numbers would be useful. The authors have 
> not seen compelling arguments for either case, so we welcome 
> feedback on this point.
> 

If the purpose as specified in the draft is to enable the RR to derive
whether there are a few packets lost in the burst beginning, then directly
using RTP sequence number (i.e. 16-bits) is enough. However, to be
consistent with RTCP convention may suffice the use of extended sequene
number. However again, if the same concept of extended sequence numbers as
in RTCP Sender Reprots is used, then simplying setting the higher two bytes
to zeros, as specified in the draft, seems incorrect. If they are anyway
always set as 0, then I would rather save the 16-bits, or make them reserved
for other purposes. 

> [David] Not sure I understand the question. It uses it to figure out 
> the amount of buffering needed, among other things.
>
> However, the client can use this value to assist it in 
> managing buffer levels.
> 

A mandatory way of using the parameter sets may not need to be specified.
However, it would be nice to have in the draft why they are useful.  For the
purpose you both mentioned, buffer management, I think it would be good to
include at least one example to explain how the parameters are used in
buffer management, in particular the RR has already indicated, through the
RMS-R message, the max burst rate, as well as the min and max buffer fill
leves. 

> received from the
>  [David] From the SR you get after joining the multicast.
>

Agreed. But it should be clearly specified. Otherwise, there could be
confusion, e.g. as Bill wrote that it could be set to zeros.

BR, YK

> From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
> Sent: Wednesday, March 11, 2009 11:46 AM
> Subject: RE: [AVT] 
> NewVersion:draft-versteeg-avt-rapid-synchronization-for-rtp-02
> 
> Ye-Kui Wang-
> 
> Thanks for your detailed review of the draft. We will be 
> setting up break-out session during the next IETF meeting to 
> refine this draft. If you are attending IETF, we would also 
> like to have your input during that break out session. We 
> will be posting a meeting notice 
> 
> Behalf Of Ye-Kui Wang
> Some comments (text or just section number goes first, the 
> corresponding comment follows). 
> 
> [start]
> 
>    Section 1.
> Could you please give an example of dispersed Reference 
> Information? Are there any benefits for dispersing Reference 
> Information. The drawback is clear; it introduces additional 
> delay for tuning-in. 
> 
> ---bvs --- The initial design motivation for this draft was 
> RTP encapsulated MPEG2TS audio/video flows. In these flows, 
> the largest item of "reference information" is the I-frame. 
> There is other reference material distributed throughout the 
> payload, including PAT/PMT/CAT and ECMs. In DSMCC data 
> carousels, there is also a lot of structure at the "beginning 
> of the file structure". Legacy (often proprietary) command 
> and control protocols often have authentication and scoping 
> information sprinkled dropout the data flow.
> 
>    Section 1.
> reception, and
> Shouldn't "(or in-band)" be removed, as in-band signaling of 
> SSRC seems impossible anyway, since upon joining a new 
> session the receiver has never received a packet?
> ---bvs --- agreed. "In-band" is an over-loaded term that has 
> different meaning in different contexts. We should strike in-band.
>  
>    Section 5.
> ---bvs --- The behavior is totally up to the desire of the 
> client. I can think of quite a few cases where the client 
> would rather join another stream (or no stream). If the 
> information is stale after a second or two, the receiver 
> would not want to receive it. The user was "channel surfing" 
> and had gone on to another channel, etc. It MAY want to tune 
> to this stream, or it MAY want to tune to another stream, or 
> it MAY want to do nothing.
> 
>    Section 6.2, step 2. 
> instructive), "the bitrate and the size of the burst" should 
> be changed to "the maximum bitrate and the duration of the burst".
> 
> --- bvs --- will fix
> 
>    Section 6.2, step 2. 
> The unit of Min RMS Buffer Fill Requirement and Max RMS 
> Buffer Fill Requirement is ms. Are the values measured in the 
> media presentation timeline? How does the RS utilize these values?
> 
> --- bvs -- The authors have gone back and forth on this 
> issues a few times. The intent is to have the RR describe its 
> buffering requirements to the RS. The RS does not know if the 
> RR is a cell phone or a super-computer, and typically does 
> not know the capabilities (de-jitter, decrypt, decode, 
> application layer processing) and thus buffering requirements 
> of the client. Rather than encapsulate all of the 
> application-layer complexity in a transaction from RR to RS, 
> we decided to have the RR tell the RS the minimum and maximum 
> amount of data it considered useful. We had been assuming 
> that the metric was "ms at the nominal rate", but this 
> requires more thought - particularly if we want to cover VBR flows.
> 
>    Section 7.2.
> 
> What is the essential difference between Response equal to 0 
> and Response equal to 2 (e.g. from implementation point of view)?
> 
>    Section 7.2.
> This allows RR
> It should be clarified that "the 16-bit RTP sequence number" 
> is not the RTP sequence number of the packet in the burst stream.
> Why does this field need to be 32 bits? You expect that there 
> might be more than 2^16-1 packets lost in the beginning of the burst.
> 
> vs "sequence numbers" as well. In earlier versions of the 
> draft, we specified that if the extended portion of the 
> sequence number was not known it would be sent as zeros". In 
> my opinion, the extended sequence numbers are of limited 
> value due to the bit rates of the streams envisioned as well 
> as the short duration of the acceleration bursts.
> However, we stayed with extended sequence numbers in order to 
> be consistent the intent of the RTP design. There are some 
> extreme cases (uncompressed HD video with large RTT) in which 
> extended sequence numbers would be useful. The authors have 
> not seen compelling arguments for either case, so we welcome 
> feedback on this point.
> 
>    Section 7.2.
> 
> However, the client can use this value to assist it in 
> managing buffer levels.
> 
>    Section 7.2.
> where n is the
> received from the
> --- bvs -- need to clarify in document - often set to all 
> zeros, but sometimes set to the correct value as received in the SR.
> 
> [end]
> 
> BR, YK
> 
> acquire and 
> faster than

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Mar 2009 21:13:43 -0700

Hi YK,

This time, I got your email, so it is my turn.

> Missed. I guess you meant "updated by RMS-I messages", which 

RMS-I can be used by RS to update some info about the burst and let RR know about it. 

>From RR to RS, RMS-T may signal RS to stop the burst immediately or let RS know the seqnum of the first RTP packet received from the mcast session. Based on this, RS may revise the burst duration.
 
> Buffer Fill 

I would say that the buffer reqs are better stated in ms. For example, there is a danger of not filling RR's buffer sufficiently if the burst starting point is too close to the currently multicast data. RR lets RS know about such requirements in the RMS-R message.
 
> Response equal to 2 (join multicast)?

0 means request was rejected. Whatever RR does is its choice.

OTOH, 2 may be used during the burst to indicate an "immediate mcast join" for a previously started burst. So, it has a different meaning.

Yet, burst rejection could also be indicated by setting the "burst duration" to 0. "Immediate join" could also be indicated by setting the "igmp join time" field to zero.

This structure may require further fine-tuning (especially when we will have the TLV-based structure) and your feedback will help us here.

> that will be 
> > > sent

Right, setting twose two bytes to 0 will not help us with anything. This is an open issue. We need to work this out. 
 
> RMS-R message, the max burst rate, as well as the min and max 

Good suggestion. RR specifies the max bitrate it can receive and its min/max buffer requirements.

Whatever RS will provide as a burst needs to comply with these requirements. But as RS may have to change its bitrate for this individual burst, RR may need to be informed in case RR wants to determine the time it will join the mcast itself.

This is an optional implementation issue and it is really up to the implementation.
 
> confusion, e.g. as Bill wrote that it could be set to zeros.

This ext RTP seqnum issue need to be resolved and we hope it will happen soon.

I hope I have not missed anything. Thanks again for the detailed reading.

-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Thu, 12 Mar 2009 21:28:43 +0200

Hi,
I read the draft and have some feedback.

1. In section 1 " The feedback target starts a unicast retransmission RTP
session and sends the Reference Information to the receiver over that
session.  If there is spare bandwidth, the feedback target may also burst
the Reference Information at a faster than natural rate." 

I was under the impression that spare bandwidth is required. Are you
suggesting here that the RR may use the unicast stream for the whole time if
no spare bandwidth is available.

2. At the end of section 4 " For example, MPEG  decoders require a
significant amount of content to be available in the decoder buffers prior
to starting to decode the content." 
Is this true for all MPEG codecs and all encoding profiles.

3. In section 5 "Rapid synchronization is an optimization of a system that
must continue to work correctly whether or not the optimization is
effective, or even fails due to lost control messages, congestion, or other
problems.  This is fundamental to the overall design requirements
surrounding the protocol definition and to the resource management schemes
to be employed  together with the protocol (e.g., QoS machinery, server load
management, etc).  In particular, the system needs operate within a number
of constraints." 

Do you require resource management scheme as part of the solution, I think
that the solution MUST work also on the free Internet

4. In section 5 " Similarly, using a TCP (or TCP-like) approach with a 3-way
handshake and slow-start  to avoid inducing congestion would defeat the
purpose of attempting rapid synchronization in the first place by
introducing many RTTs of delay." 
I think that calls for some mechanism to find the optimal rate for starting
the burst. I think this is discussed in the Peilin draft.

5. In 6.2 editor note. My view is that having the entities physically
co-located in this draft make sense and the text should state it and suggest
that physical decomposition is for futher study.

6. In 6.2 step 6 " RS may know when it needs to stop the unicast burst based
on the burst parameters , or RR may explicitly let RS know the sequence
number of the first RTP packet it received from the multicast session, or RR
may request RS to terminate the burst immediately."

I think that if the RS stops the burst by his own decision may cause a gap.
The question is what is better to have a gap and fill it using retransmit or
having both unicast and multicast simultaneously for a short time. Gap WILL
always require action while overlap MAY cause congestion loss.

7. In the same step 6 " In the latter case, RR SHALL include the sequence
number of the first RTP packet received in the SSM session in the RMS-T
message, and RS SHOULD terminate the burst after it sends  the RTP burst
packet whose OSN field in the RTP retransmission payload header matches this
number minus one."

I am wondering what happens if the RS decided to stop the burst before
receiving RMS-T. The RR may never receive the packet in with the requested
SN and may wait or start request for retransmission.

There is also a typo OSN should be SN

8. In 6.4 "In the case RR starts receiving an RTP burst but it does not
receive a corresponding RMS-I message  within a reasonable amount of time,
RR MAY either discard the burst data and stop the burst by sending an RTCP
BYE message to RS, or decide not to interrupt the RTP burst and be prepared
to join the primary multicast session at an appropriate time it determines
or indicated in a subsequent RMS-I message."

I think that since another RMS-I is not mandatory this will be a good reason
to have a rate adaption message from RR to RS as defined in the Peilin
draft.

9. In section 7 "Specific payload formats are not defined in this document,
but a framework is presented that allows payload-specific information to be
included in the exchange ."
I assume this is future text, look also at RFC 4585 application layer
message.

10. Editorial comment on section 7.1 - 7.3, maybe use the format for
specifying messages in RFC 4585 section 6.3

11. In section 7.1 you have the MIN RMS and Max RMS buffer fill explaining
what the RS behavior should be if specified but there is no text that
explains what should the RS do if they are not specified.

12. In section 7.1 the same comment on max bit rate but here I think that
the RR should always send it to allow for a optimal burst speed.

13. In section 7.1 the length of the feedback message is specified in octet?
Why not use the same semantics of RFC 4585 section 6.1 

Length: 16 bits
      The length of this packet in 32-bit words minus one, including the
      header and any padding.  This is in line with the definition of
      the length field used in RTCP sender and receiver reports [3].

14. In section 7.2 " It also includes other useful information for RR." This
is a general sentence, do you need it?

15. in Section 7.2 response parameter. If the value is 1 does it require
that existence of the following optional parameters which are not needed for
value 0 or 2.

16. In section 7.2 response parameter. If the value is 2 I assume that there
is no reason to retransmit a message with this value since the previous
condition for join may not exist. (this is an assumption since you do not
explain the motivation to send this value)

17. In section 7.2 "Earliest IGMP Join Time (32 bits):  Time difference
between the arrival of the RMS-I message  and the earliest time instant when
RR could join the new multicast session (in RTP clock ticks)" How does the
RS know when "the arrival" will happen?

18. In section 7.2 what is the use of Rapid Synchronization Duration, what
happens if not specified and is there any relation to IGMP join time

19. In Section 7.2 what is the relation between Mac Burst Rate and the max
receive bit rate in RMS-R. Is this value the maximum that the RS can send or
is it the maximum he will use.

20. In section 7.3 there are two options when to send the RMS-T message. Any
recommendation or motivation to use one or the other.

21. The example in 8.2 is a bit confusing to me. I see that this is an SDP
from the multicast source. Is this an offer, and answer or is it an
declarative SDP. 

22. On the syntax of the example in 8.2 why you have the video as receive
only if this SDP is from the multicast source. Also there should be one fmt
line and the parameters should be separated by semi-colon.

Regards
Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 13 Mar 2009 08:14:44 -0700

> I read the draft and have some feedback.

Thanks for the detailed review, Roni.

> no spare bandwidth is available.

Not that it is impossible, but would not make much sense. Do you think we need rewording here?

> Is this true for all MPEG codecs and all encoding profiles.

For virtually all related to broadcast systems. The MPEG specification is quite clear about the timing requirements. There are some low-delay codecs that have quite short buffering requirements, but these tend to be video-conferencing style codecs rather than broadcast style codecs.
 
> that the solution MUST work also on the free Internet

Why do you think it must work? It can work, but bad things may happen. 
 
> the burst. I think this is discussed in the Peilin draft.

There are ways of detecting a good rate for the burst (not the optimal one). And we can discuss them in the session.
 
> that physical decomposition is for futher study.

Sounds good.
 
> I think that if the RS stops the burst by his own decision 

Not if carefully engineered.

> always require action while overlap MAY cause congestion loss.

RS can carefully be engineered to allow a minimal overlap. IMO, I think that is better than leaving a gap.

> SN and may wait or start request for retransmission.

If RS terminates proactively without an RMS-T, RR may do retransmission to fill the gap (if any).

> There is also a typo OSN should be SN

OSN is the "original seqeunce number" field (RFC 4588).

> to have a rate adaption message from RR to RS as defined in the Peilin

Not sure if I follow.

> I assume this is future text, look also at RFC 4585 application layer

For mpeg2-ts, we already have a draft:
http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-00.txt

> specifying messages in RFC 4585 section 6.3

Sure.
 
> explains what should the RS do if they are not specified.

That means RR does not care about the burst's characteristics. RS may send whatever it decides to.

> the RR should always send it to allow for a optimal burst speed.

We rather wish to keep it optional. 

> 13. In section 7.1 the length of the feedback message is 

Yes, this is already fixed for the next revision.

> Why not use the same semantics of RFC 4585 section 6.1 

That section is pretty similar to ours. Do you want us to include the common fields as well?
 
>       the length field used in RTCP sender and receiver reports [3].

Oh about the length field. Sure, we can do this. 
 
> is a general sentence, do you need it?

With future extensions, further useful information can be provided. In the existing message format, join-time, burst-duration, etc are all useful information for RR.
 
> that existence of the following optional parameters which are 

IGMP join time field must be populated in at least of the RMS-I messages. The rest is optional. This should be less cumbersome if/when we transition to TLV for these fields.

> explain the motivation to send this value)

Makes sense. But, as it is optional, I believe it is up to the implementation.
 
> RS know when "the arrival" will happen?

If you think that the one-way delay will cancel out, it fits nicely. It says "join the mcast session X clock ticks or ms after you received this message."

> happens if not specified and is there any relation to IGMP join time

If you wanna allow a small overlap, the igmp join time should indicate a time a little bit earlier than the the burst will terminate. So, it is related. But, other implementations may not use it and rather prefer "real-time join" signaling.
 
> is it the maximum he will use.

The max bitrate RS will use has to be no larger than the max receive bitrate RR indicates in the RMS-R message. The requested message rate may exceed some threshold (like aggregate access network bandwidth) that is known by the RS but not known by the RR.
 
> recommendation or motivation to use one or the other.

This is implementation specific. Related to your earlier question whether to allow a small overlap or leave a gap.

> from the multicast source. Is this an offer, and answer or is it an

It is a declarative SDP.

> line and the parameters should be separated by semi-colon.

Did not know that. Will fix it.

I hope I have not skipped any question.

BR,
-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Fri, 13 Mar 2009 19:10:47 +0200

Ali,
Inline
Thanks
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, March 13, 2009 5:15 PM
To: Roni Even; IETF AVT WG
Subject: RE: Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02

> no spare bandwidth is available.

Not that it is impossible, but would not make much sense. Do you think we
need rewording here?

Roni: yes.

> Is this true for all MPEG codecs and all encoding profiles.

For virtually all related to broadcast systems. The MPEG specification is
quite clear about the timing requirements. There are some low-delay codecs
that have quite short buffering requirements, but these tend to be
video-conferencing style codecs rather than broadcast style codecs.

Roni: So this sentence is not correct, MPEG is not only MPEG 2 for broadcast
it can be MPEG 4 part 10for video conferencing.

Roni: When you write an IETF document it should work on the free Internet. 
 
> the burst. I think this is discussed in the Peilin draft.

There are ways of detecting a good rate for the burst (not the optimal one).
And we can discuss them in the session.

Roni: I could not find in the dpcument how you get what is optimal rate to
start the burst

Sounds good.

> always require action while overlap MAY cause congestion loss.

RS can carefully be engineered to allow a minimal overlap. IMO, I think that
is better than leaving a gap.

Roni: I agree so write it.

> SN and may wait or start request for retransmission.

If RS terminates proactively without an RMS-T, RR may do retransmission to
fill the gap (if any).

Roni: In this specific case it will happen according to the document because
the RR wanted to get a specific packet. I think that the least is to explain
this case or allow for RR to ask the RS to wait for RMS-T in the RMS-R.

Roni: so write "Original Sequence Number (OSN)"

Not sure if I follow.

Roni: my view is that a message from RR in the case when it gets an RTP flow
without RMS-I will solve this state.

Roni: I read this draft and can give separate feedback. 

Sure.
 
> explains what should the RS do if they are not specified.

That means RR does not care about the burst's characteristics. RS may send
whatever it decides to.

Roni: Clarify in the text

Roni: See my comment on 4 above

> Why not use the same semantics of RFC 4585 section 6.1 

That section is pretty similar to ours. Do you want us to include the common
fields as well?

Roni: OK
 
> is a general sentence, do you need it?

With future extensions, further useful information can be provided. In the
existing message format, join-time, burst-duration, etc are all useful
information for RR.
 
> that existence of the following optional parameters which are 

IGMP join time field must be populated in at least of the RMS-I messages.
The rest is optional. This should be less cumbersome if/when we transition
to TLV for these fields.

Roni: Why do you need any parameter for th2 0 and 2 cases. Why not have all
parameters from RS for the 1 case, this gives the RR the option if to use
them or not. I am not sure why they are optional if they supply information
to RR.

> explain the motivation to send this value)

Makes sense. But, as it is optional, I believe it is up to the
implementation. 

Roni: When you make something optional, this may mean to a reader that it is
not needed except in certain cases, but you do not specify the benefit for
having an optional parameter.
 
> RS know when "the arrival" will happen?

If you think that the one-way delay will cancel out, it fits nicely. It says
"join the mcast session X clock ticks or ms after you received this
message."

Roni: How does the RS know when the RR will get the message. If I read the
draft and try to calculate this value as it is written I will not know how
to calculate this number.

> happens if not specified and is there any relation to IGMP join time

If you wanna allow a small overlap, the igmp join time should indicate a
time a little bit earlier than the the burst will terminate. So, it is
related. But, other implementations may not use it and rather prefer
"real-time join" signaling.

Roni: Explain this is the text.
 
> is it the maximum he will use.

The max bitrate RS will use has to be no larger than the max receive bitrate
RR indicates in the RMS-R message. The requested message rate may exceed
some threshold (like aggregate access network bandwidth) that is known by
the RS but not known by the RR.

Roni: Clarify this in the text. 

> recommendation or motivation to use one or the other.

This is implementation specific. Related to your earlier question whether to
allow a small overlap or leave a gap.

Roni: See my comment on your response above.

It is a declarative SDP.

Roni: Explain in the text. Is this solution only for declarative or does it
allow also offer/ answer exchange.

BR,
-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 13 Mar 2009 13:12:55 -0400

Just a clarification on the video buffering discussion.
 
> > significant amount of content to be available in the 
> decoder buffers 
> > prior to starting to decode the content."
> For virtually all related to broadcast systems. The MPEG 
> specification is quite clear about the timing requirements. 
> There are some low-delay codecs that have quite short 
> buffering requirements, but these tend to be 

All video coding standards, including both MPEG ones and ITU-T ones, specify
video buffering models, sometimes named hypothetical reference decoder
(HRD), sometimes named video buffer verifier (VBV). For most, if not all, of
the video codecs, the amount of data to be availalbe in the pre-decoding
buffer or coded picture buffer is decoded by the initial pre-decoding buffer
or coded picture buffer delay as well as the bitrate that data flows into
the buffer. The initial delay and the bitrate values can both be configured
and included in the bitstream by the encoder during encoding according to
the required end-to-end delay for the target application scenario(s). 

Therefore, the sentence in question should still be informativeas, yet more
accurate and not confusing, if it is changed to something as follows:

"For example, standard video decoders typically require an amount, sometimes
a significant amount, of coded video data to be available in the
pre-decoding buffers prior to starting to decode the video bitstream."

BR, YK

> Sent: Friday, March 13, 2009 11:15 AM
> Subject: Re: [AVT] Review of 
> > 1. In section 1 " The feedback target starts a unicast 
> retransmission 
> > RTP session and sends the Reference Information to the 
> receiver over 
> > that session.  If there is spare bandwidth, the feedback target may 
> > also burst the Reference Information at a faster than natural rate."
> > 
> > suggesting here that the RR may use the unicast stream for 
> the whole 
> > time if no spare bandwidth is available.
> 
> > 3. In section 5 "Rapid synchronization is an optimization 
> of a system 
> > that must continue to work correctly whether or not the 
> optimization 
> > is effective, or even fails due to lost control messages, 
> congestion, 
> > or other problems.  This is fundamental to the overall design 
> > requirements surrounding the protocol definition and to the 
> resource 
> > management schemes to be employed  together with the 
> protocol (e.g., 
> > QoS machinery, server load management, etc).  In particular, the 
> > system needs operate within a number of constraints."
> > 
> > Do you require resource management scheme as part of the 
> solution, I 
> > think that the solution MUST work also on the free Internet
> 
> > 4. In section 5 " Similarly, using a TCP (or TCP-like) 
> approach with a 
> > 3-way handshake and slow-start  to avoid inducing congestion would 
> > defeat the purpose of attempting rapid synchronization in the first 
> > place by introducing many RTTs of delay."
> > I think that calls for some mechanism to find the optimal rate for 
> > starting the burst. I think this is discussed in the Peilin draft.
> 
> There are ways of detecting a good rate for the burst (not 
> the optimal one). And we can discuss them in the session.
>  
> > co-located in this draft make sense and the text should 
> state it and 
> > suggest that physical decomposition is for futher study.
> 
> Sounds good.
>  
> > 6. In 6.2 step 6 " RS may know when it needs to stop the 
> unicast burst 
> > based on the burst parameters , or RR may explicitly let RS 
> know the 
> > sequence number of the first RTP packet it received from 
> the multicast 
> > session, or RR may request RS to terminate the burst immediately."
> > 
> > I think that if the RS stops the burst by his own decision 
> may cause a 
> > gap.
> 
> > The question is what is better to have a gap and fill it using 
> > retransmit or having both unicast and multicast 
> simultaneously for a 
> > short time. Gap WILL always require action while overlap MAY cause 
> > congestion loss.
> 
> RS can carefully be engineered to allow a minimal overlap. 
> IMO, I think that is better than leaving a gap.
> 
> > 7. In the same step 6 " In the latter case, RR SHALL include the 
> > sequence number of the first RTP packet received in the SSM 
> session in 
> > the RMS-T message, and RS SHOULD terminate the burst after it sends 
> > the RTP burst packet whose OSN field in the RTP 
> retransmission payload 
> > header matches this number minus one."
> > 
> > receiving RMS-T. The RR may never receive the packet in with the 
> > requested SN and may wait or start request for retransmission.
> 
> > 8. In 6.4 "In the case RR starts receiving an RTP burst but it does 
> > not receive a corresponding RMS-I message  within a 
> reasonable amount 
> > of time, RR MAY either discard the burst data and stop the burst by 
> > sending an RTCP BYE message to RS, or decide not to 
> interrupt the RTP 
> > burst and be prepared to join the primary multicast session at an 
> > appropriate time it determines or indicated in a subsequent RMS-I 
> > message."
> > 
> > I think that since another RMS-I is not mandatory this will 
> be a good 
> > reason to have a rate adaption message from RR to RS as 
> defined in the 
> > Peilin draft.
> 
> Not sure if I follow.
> 
> > 9. In section 7 "Specific payload formats are not defined in this 
> > document, but a framework is presented that allows payload-specific 
> > information to be included in the exchange ."
> > 11. In section 7.1 you have the MIN RMS and Max RMS buffer fill 
> > explaining what the RS behavior should be if specified but 
> there is no 
> > text that explains what should the RS do if they are not specified.
> 
> That means RR does not care about the burst's 
> characteristics. RS may send whatever it decides to.
> 
> > 12. In section 7.1 the same comment on max bit rate but 
> here I think 
> > that the RR should always send it to allow for a optimal 
> burst speed.
> 
> > 13. In section 7.1 the length of the feedback message is 
> specified in 
> > octet?
> 
> >       The length of this packet in 32-bit words minus one, 
> including 
> > the
> > 14. In section 7.2 " It also includes other useful information for 
> > RR." This is a general sentence, do you need it?
> 
> With future extensions, further useful information can be 
> provided. In the existing message format, join-time, 
> burst-duration, etc are all useful information for RR.
>  
> > 15. in Section 7.2 response parameter. If the value is 1 does it 
> > require that existence of the following optional parameters 
> which are 
> > not needed for value 0 or 2.
> 
> IGMP join time field must be populated in at least of the 
> RMS-I messages. The rest is optional. This should be less 
> cumbersome if/when we transition to TLV for these fields.
> 
> > 16. In section 7.2 response parameter. If the value is 2 I 
> assume that 
> > there is no reason to retransmit a message with this value 
> since the 
> > previous condition for join may not exist. (this is an assumption 
> > since you do not explain the motivation to send this value)
> 
> > 17. In section 7.2 "Earliest IGMP Join Time (32 bits):  Time 
> > difference between the arrival of the RMS-I message  and 
> the earliest 
> > time instant when RR could join the new multicast session (in RTP 
> > clock ticks)"
> > How does the
> If you think that the one-way delay will cancel out, it fits 
> nicely. It says "join the mcast session X clock ticks or ms 
> after you received this message."
> 
> > 18. In section 7.2 what is the use of Rapid Synchronization 
> Duration, 
> > what happens if not specified and is there any relation to 
> IGMP join 
> > time
> 
> If you wanna allow a small overlap, the igmp join time should 
> indicate a time a little bit earlier than the the burst will 
> terminate. So, it is related. But, other implementations may 
> not use it and rather prefer "real-time join" signaling.
>  
> > 19. In Section 7.2 what is the relation between Mac Burst 
> Rate and the 
> > max receive bit rate in RMS-R. Is this value the maximum 
> that the RS 
> > can send or is it the maximum he will use.
> 
> The max bitrate RS will use has to be no larger than the max 
> receive bitrate RR indicates in the RMS-R message. The 
> requested message rate may exceed some threshold (like 
> aggregate access network bandwidth) that is known by the RS 
> but not known by the RR.
>  
> > 20. In section 7.3 there are two options when to send the RMS-T 
> > message. Any recommendation or motivation to use one or the other.
> 
> This is implementation specific. Related to your earlier 
> question whether to allow a small overlap or leave a gap.
> 
> > 21. The example in 8.2 is a bit confusing to me. I see that 
> this is an 
> > SDP from the multicast source. Is this an offer, and answer 
> or is it 
> > an declarative SDP.
> 
> It is a declarative SDP.
> 
> > 22. On the syntax of the example in 8.2 why you have the video as 
> > receive only if this SDP is from the multicast source. Also there 
> > should be one fmt line and the parameters should be separated by 
> > semi-colon.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 14 Mar 2009 16:13:33 -0700

Hi Roni, 

Snipping off the text we are already in agreement.

> > retransmission RTP
> > the whole time if

Will do.
 
> specification is

We will incorporate the text YK provided.
  
> > approach with a 3-way

There is no way to find the optimal burst rate. Optimality varies based on its definition. And pretty much everybody has a different definition. Thus, I don't think we need to get into that discussion much in this document.
  
> > be a good reason
 
What type of message from RR?
  
> RMS-I messages.

Not every implementation uses all this information. Different implementations depend on different fields. See below.
 
> > assume that there

When something is optional in our draft, it means not all implementations need that field. For example, an implementation may never need to use "IGMP join time" field, if it opts to use real-time signaling, i.e., "join now" field when needed.

I don't think we need to discuss the pros and cons of each possible implementation. We provide the common requirements and basic design principles in Section 5. IMO it is pretty sufficient to provide the necessary insight to this problem.
  
> > difference
> nicely. It says

Why not? You should be able to compute a good estimate.
 
> > Rate and the max
> receive bitrate

This is already written in Section 7.
   
> > this is an SDP

The SDP elements we use in the example are all pre-defined in earlier documents except the "ssli" parameter to be used with "nack". Whether they allow offer/answer model or not, it is already specified in their respective specs.

As for the "ssli" parameter, the same offer/answer model rules apply from RFC 4585. I mentioned this in the revision.

BR,
-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 17 Mar 2009 15:30:36 -0400

Hi Ali, Roni, 

Just to share my understanding of one point. 

> > > not receive a corresponding RMS-I message  within a reasonable 
> > > amount of time, RR MAY either discard the burst data and stop the 
> > > burst by sending an RTCP BYE message to RS, or decide not to 
> > > interrupt the RTP burst and be prepared to join the primary 
> > > multicast session at an appropriate time it determines or 
> indicated 
> > > in a subsequent RMS-I message."
> > > 
> > > I think that since another RMS-I is not mandatory this will be a 
> > > good reason to have a rate adaption message from RR to RS 
> as defined 
> > > in
> > the Peilin
> > > draft.
> > 
> > Not sure if I follow.
> > 
> > Roni: my view is that a message from RR in the case when it gets an 
> > RTP flow without RMS-I will solve this state.
>  

Independent of the use of RTCP BYE, I think that having a message, as
explained in the following, from the RR would be useful, and is
complementary to the design in
draft-versteeg-avt-rapid-synchronization-for-rtp-02.

The message simply contains a bitrate value, indicating a burst bitrate
desired by the RR. The RR may derive the value according to its buffer
fullness, its knowledge of the charateristics of incoming bitstreams, as
well as its knowledge of the underlying network situations. The RR may also
perform certain probing actions to get the status of the underlying network.
The RS may use this indicated value for sending the burst, or may adjust the
value according to the RS' knowledge to the charateristics of the bitstreams
to be sent out, as well as other information. In either case, the RS may
send an RMS-I to indicate the bit rate being used. 

This allows the analysis of a desired burst rate to be performed by 1) the
RS, 2) the RR, or 3) the RS and the RR in combination. Such a flexibility
would enable the RS to be scalable to the number of RRs it needs to serve.
When the number of RRs for one RS is small, the system can be configured to
let the RS have more RCTP receiver reports and hence more information for
analysis of a desired burst rate. When the number of RRs for one RS is big,
the system can be configured to let the RS have less RTCP receiver reports
but let the RRs to perform the analysis of a desired burst rate. At the same
time,  the computation burden to the RS for simultaneously analyzing desired
burst rates for all the invovlved RRs can be avoided. 

The process is more or less similar to the Reference Picture Selection
Indication (RPSI) message specified in RFC 4585. The analysis of a desired
reference picture to use may be performe either by the sender (according to
detailed RTCP receiver reports) or by the receiver (in this case detailed
RTCP receiver reports are not needed). 

BR, YK