[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] NewVersion:draft-versteeg-avt-rapid-synchronization-for-rtp-02
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.
> > 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?
Missed. I guess you meant "updated by RMS-I messages", which are sent by RS
and received by RR?
> > 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.
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?
> > 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)?
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)?
> > 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?
> >
> [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.
>
> --- 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.
>
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.
> > Section 7.2.
> >
> > How does RR utilize the Max Burst Bitrate conveyed in the RMS-I
> > message?
> >
> [David] Not sure I understand the question. It uses it to figure out
> the amount of buffering needed, among other things.
>
> --- 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.
>
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.
> 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?
>
> [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
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb at cisco.com]
> Sent: Wednesday, March 11, 2009 11:46 AM
> 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-
>
> 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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] 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,
>
> 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.
>
> ---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.
> 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?
> ---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.
>
> "needs operate" -> "needs to operate".
> ---bvs ---- agreed
>
> 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"
>
> ---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.
>
> Same as above, "or in-band" should be removed.
>
> ---bvs --- will fix
>
> 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?
>
> ---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.
> 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".
>
> --- bvs --- will fix
>
> 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?
>
> --- bvs --- will fix, bytes/octets is almost certainly the
> correct unit.
>
> 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?
>
> --- 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.
> 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.
>
> --- 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.
>
> How does RR utilize the Max Burst Bitrate conveyed in the
> RMS-I message?
>
> --- 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.
> 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.
>
> ---bvs will fix. This may also change if we go to TLV encoding
>
> 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?
>
> --- 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
>
> > -----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
>