[AVT] Inter-stream synchronization and startup sync latency

[Randell Jesup <[e-mail]>]

Colin Perkins <[e-mail]> writes:
>The issue with start-up latency, waiting to receive the first RTCP SR
>packet sent to a multicast group, is a general limitation of RTP, and  not
>something specific to the SVC payload format. Accordingly, if  it's
>becoming a problem, it should be solved in a general manner, not  as part
>of the SVC payload format specification.
>
>Use the existing mechanisms: don't try to reinvent them for each new
>payload format.

I agree - but that means someone has to generalize a solution to startup
latency, and that might not be feasible without a significant change to the
architecture of RTP/RTCP, or without a very large shoehorn.

No one has put forward a general solution, and unless/until someone does
we'll see this happen again and again.

As I see it, there are two primary issues here:
1) Delay between start of stream reception and getting TS<->NTP mappings
   for that stream.  (I.e. current RTCP reception delay.)
2) Delay in getting cross-stream synchronization (currently, occurs once
   all streams have passed case 1 and have valid NTP mappings).

These are complicated by RTCP bandwidth and timing issues in multicast
sessions, though that's just a matter of degree.

Case 1 is affected by fundamentals of RTP/RTCP design: first that RTCP are
unreliable, and second that the timings for RTCP AVP mean that a
lost/missed RTCP packet means a 2.5-7.5 second delay before the next one,
or longer.  AVPF can certainly help this, if bandwidth doesn't become an
issue and if the sender knows it's a "good time" to send extra/early RTCP
(like when it knows a listener just joined).  The separation of RTP from
RTCP on differnt ports can add to the problem in some cases, since they
might take different paths or RTCP might be blocked (by a firewall/router).

One thing for people to remember when trying to solve this problem (SVC
people for example) is that part of the reason for using RTCP/NTP for
synchronizing channels is that the streams might come from different
sources, and still need to be synchronized (think multiple microphones, or
multiple cameras at a game, or a conference call).  That doesn't mean you
can't design something that can improve on the current solution, but that
you need to think about other cases and if possible find a way to help them
as well.


As for solutions to the problem I've laid out....  I don't know.  Solutions
that fit in the current framework all have issues; solving this problem
*might* require something outside of what RFC 3550 envisions/allows.

Possibilities:

* Signal initial Timestamp->NTP mappings for streams
  This may have the most possible wins and least downside, but it's not
  without serious issues.  It preserves the security aspects of random
  timestamps (not that they're huge), and is backwards-compatible.  It
  allows first-packet synchronization in many cases.

  Downsides:
  * If you signal it as a sender (I'll send with this mapping), then
    you have issues with conferences (need multiple mappings by sender
    SSRC/etc in the signaling), and you can still have an unsynchronized
    period if a 200 OK is lost, for example.
  * If you signal it as a receiver, then there are compatibility issues and
    there are some issues with multiple senders.  It probably won't work in
    any multicast setup (true or pseudo).  To handle the multiple streams
    and non-multicast multiple senders:
    * Have all the streams use the same TS<->NTP mapping.  This might have
      security or other downsides.  Comments?
    * Have each sender use the TS<->NTP mapping provided by the receiver
      with some type of hashing function to generate a TS<->NTP mapping
      based on their SSRC value. 

* Implictly synchronized streams
  This is what some SVC people have proposed, where the inter-stream
  synchronization is implicit in the timestamps.  The advantage again is
  compatibility (may not matter) and conciseness.

  Downsides:
  * Only can work for single-source sets of streams.  This may make it
    non-viable for some conferencing situations.
  * Provides only inter-stream sync - though the advantage is that a single
    RTCP for any of the TS-synced streams would sync all of them to NTP
    implicitly.
  * May cause security issues (I'm not really sure of this, and I don't
    think it's a significant issue in practice, but some real crypto mavens
    should vet that).  I *suspect* we're ok if the starting point is still
    random.
  * Requires some type of signaling of the relationship between the
    streams.  This could be implicit in an SVC-only solution, but would
    probably need to be explicit in a general solution.

Others?

>On 9 Jan 2008, at 09:19, BABONNEAU Gerard RD-MAPS-REN wrote:
>> Consequently, no CL-mode is possible in both cases either with a  common
>> TimeStamp or with RTCP/SR/NTP to synchronize sessions. As  said Colin, it
>> is easy to send an SR per session before starting a  unicast VOD. But the
>> problem is fussy about multicast IPTV  programs, because the main
>> challenge for all the video provider is  to reduce the zapping
>> latency. Lots of efforts aims to gain  hundreds of milliseconds, and a
>> new service that adds seconds of  latency (to synchronize SR) is not
>> credible. The risk could be the  burying of SVC for such kinds of
>> services.
>>
>> I believe that both processing for TS may be usefull according to
>> services. I suggest to define an additional field in the SDP to  precise
>> that RTP session share the same TS (per default, the  synchronization use
>> RTCP/SR); may be:
>>         a=fmtp: share-ts=1
>>
>> Moreover, to allow RTCP SR based synchronisation, I would replace  the
>> second MUST by SHALL in current 05 draft section 7.I.d: "All  RTP
>> sessions MUST use the same RTP Timestamp scale and SHALL use  the same
>> RTP timestamp for packets in the different RTP session  containing NAL
>> units of the same sampling time instance."
>>
-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[e-mail]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt