Bill,
Since there is another draft on the same topic which will be
presented, it will be helpful to agree on one draft as a starting point for a
WG document, assuming you want one.
So it will be productive if the time will be suitable at least to
the contributors of both drafts.
Regards
Roni
From: Bill Ver Steeg
(versteb) [mailto:versteb at cisco.com]
Sent: Wednesday, March 11, 2009 6:29 PM
To: ron.even.tlv at gmail.com; yekuiwang at huawei.com; Ali C. Begen (abegen);
avt at ietf.org
Cc: Dave Oran (oran)
Subject: Re: [AVT] NewVersion:
draft-versteeg-avt-rapid-synchronization-for-rtp-02
Yes, the intent
is for an open technical session. We are coordinating schedules of the existing
contributors, and will have a suggested time. It is looking like monday, maybe
tuesday. We will let you know.
Bvs
----- Original Message -----
From: Roni Even <ron.even.tlv at gmail.com>
To: Bill Ver Steeg (versteb); 'Ye-Kui Wang' <yekuiwang at huawei.com>; Ali
C. Begen (abegen); 'IETF AVT WG' <avt at ietf.org>
Cc: Dave Oran (oran)
Sent: Wed Mar 11 12:10:54 2009
Subject: RE: [AVT]
NewVersion: draft-versteeg-avt-rapid-synchronization-for-rtp-02
Bill,
I hope that this breakout session is open, in this case I would suggest that
you will give people a couple of optional time slots to select.
Regards
Roni Even
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
On Behalf Of Bill
Ver Steeg (versteb)
Sent: Wednesday, March 11, 2009 5:46 PM
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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt