[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 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
> -----Original Message-----
> 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:
> 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
>
>