Re: [AVT] NewVersion: draft-versteeg-avt-rapid-synchronization-for-rtp-02

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