[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New Version: draft-versteeg-avt-rapid-synchronization-for-rtp-02
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
> -----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
>