[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] NewVersion:draft-versteeg-avt-rapid-synchronization-for-rtp-02
Hi YK,
This time, I got your email, so it is my turn.
> > > 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?
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.
> > > 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?
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.
> > > 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)?
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.
> > > 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.
Right, setting twose two bytes to 0 will not help us with anything. This is an open issue. We need to work this out.
> > > 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.
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.
> > 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.
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
> 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
> >
>
>
>