[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



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?
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
there any benefits for dispersing Reference Information. The drawback is 
clear; it introduces additional delay for tuning-in.
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. 


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


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

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


I'll let Ali fix this - he's holding the pen.


  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.


Ditto.


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


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


ACK - I think that would be consistent.


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


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


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


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


  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.
Good catch - hangover from the prior encoding scheme that used fixed- length fields. 


  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?


From the SR you get after joining the multicast.


[end]

BR, YK


-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] 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

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

As usual, comments are welcome.
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]

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.


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt




_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt