Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

[Ye-Kui Wang <yekuiwang at huawei.com>]

Some more comments in addition to those from others posted earlier.

   Section 1:

   Two backwards compatible extensions to the basic
   RTP synchronisation mechanism are proposed:

   o  An enhancement to the Extended RTP Profile for RTCP-based Feedback
      (RTP/AVPF) [2] is defined to allow receivers to request additional
      RTCP SR packets, providing the metadata needed to synchronise RTP
      flows.  This can reduce the synchronisation delay when joining
      sessions with large RTCP reporting intervals, or in the presence
      of packet loss.

   o  Two RTP header extensions are defined, to deliver synchronisation
      metadata in-band with RTP data packets.  These extensions provide
      synchronisation metadata that is aligned with RTP data packets,
      and so eliminate the need to estimate clock-skew between flows
      before synchronisation.  They can also reduce the need to receive
      RTCP SR packets before synchronising flows. 

The two extensions seem to be a bit contradicting to each other. The benefit
of the first is to allow receivers to request more SR packets, while one can
be reduce the need of SR packets. How to use them both? If only one should
be used at a time, when to use which? Are both really needed?

   Section 2.1.2:

        Session| Number of receivers (single sender assumed):
      Bandwidth|  2     3     4     5     10   100   1000  10000
             --+------------------------------------------------
         8 kbps| 2.73  4.10  5.47  5.47  5.47  5.47  5.47  5.47
        16 kbps| 2.50  2.50  2.73  2.73  2.73  2.73  2.73  2.73
        32 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
        64 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
       128 kbps| 1.41  1.41  1.41  1.41  1.41  1.41  1.41  1.41
       256 kbps| 0.70  0.07  0.07  0.07  0.07  0.07  0.07  0.07
       512 kbps| 0.35  0.35  0.35  0.35  0.35  0.35  0.35  0.35
         1 Mbps| 0.18  0.18  0.18  0.18  0.18  0.18  0.18  0.18
         2 Mbps| 0.09  0.09  0.09  0.09  0.09  0.09  0.09  0.09
         4 Mbps| 0.04  0.04  0.04  0.04  0.04  0.04  0.04  0.04

   Figure 1: Average RTCP Reporting Interval (seconds)

It seems that the number 0.70 for 512 kbps with 2 receivers is typo (of
0.07)? 

   Section 3.2. 

Two variants of RTP header extension are specified, with the difference
being whether to signal the 8 MSBs of the integer part of the NTP timestamp.
I think having either but only one of the two variants, preferrably the one
without the 8 MSBs, is enough. 

BR, YK

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Colin Perkins
> Sent: Monday, March 09, 2009 3:43 PM
> To: avt at ietf.org WG
> Subject: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> 
> The changes in this version are primarily editorial; we're 
> aware that not all the open issues have been addressed yet. 
> Any further comments are welcomed.
> 
> Chairs: we'd like this to be considered as an AVT working 
> group draft, as indicated privately.
> 
> Cheers,
> Colin
> 
> 
> 
> 
> Begin forwarded message:
> > From: Internet-Drafts at ietf.org
> > Date: 9 March 2009 17:15:02 GMT
> > To: i-d-announce at ietf.org
> > Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> > Reply-To: internet-drafts at ietf.org
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> > 	Title           : Rapid Synchronisation of RTP Flows
> > 	Author(s)       : C. Perkins, T. Schierl
> > 	Filename        : draft-perkins-avt-rapid-rtp-sync-03.txt
> > 	Pages           : 17
> > 	Date            : 2009-03-09
> >
> > This memo outlines how RTP multimedia sessions are 
> synchronised, and 
> > discusses how rapidly such synchronisation can occur.  We show that 
> > most RTP sessions can be synchronised immediately, but that 
> the use of 
> > video switching multipoint conference units (MCUs) or large source 
> > specific multicast (SSM) groups can greatly increase the initial 
> > synchronisation delay.  This increase in delay can be 
> unacceptable to 
> > some applications that use layered and/or multi-description codecs.
> >
> > This memo updates the RTP Control Protocol (RTCP) timing rules to 
> > reduce the initial synchronisation delay for SSM sessions.  A new 
> > feedback packet is defined for use with the Extended RTP 
> Profile for 
> > RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to 
> > rapidly request resynchronisation.  Two new RTP header 
> extensions are 
> > defined to allow rapid synchronisation of late joiners, and 
> guarantee 
> > correct timestamp based decoding order recovery for layered 
> codecs in 
> > the presence of clock skew.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp-
> > sync-03.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > Content-Type: text/plain
> > Content-ID: <2009-03-09100610.I-D at ietf.org>
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce at ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>