Subject: [AVT] New version of RTCP for IDMS

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 14 Jan 2011 16:15:13 +0000

Hi all,

We have just submitted a new version of our internet draft describing an RTCP XR block for Inter-Destination Media Synchronization (IDMS).

http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03

We have tried to include all feedback received both from the mailing list as well as from IETF 79 in Beijing.

Major changes include, apart from numerous clarifications and rewrites:

- an example/tutorial section that we hope will help make clear how IDMS can be used in practice.
- an 'Implementation Considerations' section that adresses a number of issues that were raised on the mailing list, including how to deal with NTP synchronization in different use cases, echo cancellation and the issue of reporting versus controlling.
- the removal of the mixer functionality

In the past there have been some concerns about whether RTCP XR blocks are the best solution for IDMS and if a new RTCP block wouldn't be better. Also, some questions were raised about the advantage of having both client->server and server->client communication with the same XR block. On these issues we feel it is important to understand that the proposed IDMS system is not a control protocol; client are not told how to synchronize their playback to others. The proposed XR block only informs clients of the slowest playback within their synchronization group, how they deal with this information, if at all, is up to themselves. In this way, IDMS is not that different from how RTCP is used to deal with synchronization between audio and video streams on the same terminal.

I look forward to your comments.

Kind regards,

Ray van Brandenburg
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Jan 2011 09:46:24 +0000

> http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03
...
> In the past there have been some concerns about whether RTCP XR blocks are the best solution for IDMS and if a new RTCP block wouldn't be better. Also, some questions were raised about the advantag…

RTCP uses a special-purpose packet type (SR) to information receivers of the synchronisation parameters, separate to the reception reports. 

RTCP XR is appropriate for receivers to report on their synchronisation state. If IDMS were a peer-to-peer protocol, with each receiver directly determining its playout based on the reported state from receivers, then this would be sufficient for controlling playout too. However, if there is a server-to-client control message that informs receivers of their synchronisation point, that should, I believe, follow the previous RTCP approach, and be coded as a separate packet type.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 18 Jan 2011 13:43:17 +0000

Hi Colin,

Thanks for your comments.

> RTCP XR is appropriate for receivers to report on their synchronisation state. If IDMS were a peer-to-peer protocol, with each receiver directly determining its playout based on the reported state…

What exactly do you mean by 'previous RTCP approach'?

The main reason we went with an RTCP-XR report block was that we believed it would be less controversial to add an XR block type than a completely new RTCP packet type. In RFC5968 (which I believe you authored) it says that the only valid reason to create a new RTCP packet type is if the required functionality would not be appropriate as part of one of the current packet types (such as XR-). In the description of the XR- packet type in the same document it says the XR blocks are appropriate for "for transporting new metrics regarding media transmission or reception quality". So I think we should have a discussion about whether the IDMS block fits this description. 

I believe the DLRR XR report block introduced in RFC3611, is somewhat similar in nature to the server->client IDMS block in that it is also a server-to-client block that helps receivers get information on network delay. 

Regards,

Ray van Brandenburg

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 18 Jan 2011 18:49:14 -0500

Hi Ray, 

I think the draft is in good shape and provides a lot of additional information. 

I have one suggestion for adding some flexibility. 

I continue to be concerned about using device NTP time as the basis for system playout sync. A device playout stack may not normally have a mechanism to force an NTP update prior to a session - and this draft recommends that it do an NTP update. Secondly the NTP local time is not in general a monotonic increasing clock. It will (after some amount of playout) drift in one direction or the other and shift when the next NTP update arrives. 

One way to avoid this concern would be to use local free-running monotonically increasing clocks and use some other mechanism to determine the path delay from source to each player. NTP may work well enough most of the time - but in cases where that is not good enough - providing the local free running clock in the XR would provide the added information needed for a synch source which could determine path delays to make the necessary sync decisions. 

I am therefore suggesting that an additional data element be added to the end of the report - a free running local device time. 

Regards, 

Peter Musgrave

On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote:

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 19 Jan 2011 11:30:06 +0000

Hi Peter,

> I think the draft is in good shape and provides a lot of additional information. 

Thanks!

> I am therefore suggesting that an additional data element be added to the end of the report - a free running local device time. 

I understand your concern and agree that free-running clocks would be a possible solution. Would it be OK with you if we rename the 7th and 8th words of the XR block to '64bit timestamp' instead of 'NTP timestamp'? Applications can then decide whether this timestamp should be filled using NTP, local device times or another timing solution such as GPS or PTP (precision time protocol). This way the block becomes NTP-independent while not having to add additional elements making it unnecessarily big. 

Regards,

Ray van Brandenburg

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: woensdag 19 januari 2011 0:49
To: Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: Re: [AVT] New version of RTCP for IDMS

Hi Ray, 

Regards, 

Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 19 Jan 2011 06:42:46 -0500

Hi Ray, 

I like that idea, but then I think having a flag field to indicate if it is e.g. NTP or "vendor specific" might be useful from an interop perspective.

Peter

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 19 Jan 2011 11:57:35 +0000

Hi Peter,

I agree there should be some way to indicate what type of timestamp is used. Apart from a flag field, for which there are some bits left, another option would be to have this information in an SDP parameter, since we also use that to indicate the chosen group-sync identifier.  

Ray

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: woensdag 19 januari 2011 12:43
To: Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: Re: [AVT] New version of RTCP for IDMS

Hi Ray, 

Peter

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 19 Jan 2011 07:03:04 -0500

You're right, an SDP parameter is way better....for now I think all we need are values ntp and local.

This does however open up a negotiation issue which will require clarification. If a device supports both - how does it say so, who decides etc.

Peter

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Jan 2011 22:13:50 +0000

On 19 Jan 2011, at 11:30, Brandenburg, R. (Ray) van wrote:
> I understand your concern and agree that free-running clocks would be a possible solution. Would it be OK with you if we rename the 7th and 8th words of the XR block to '64bit timestamp' instead of 'NTP timestamp'?

In RFC3550, absolute timestamps of this sort are represented using the format of NTP, even though implementations are not required to run NTP [RFC3550 section 4]. I'd suggest this draft follow the same approach: use an NTP-format timestamp in the RTCP packets, with signalling to specify what clock is used to populate that timestamp. Saves receivers having to learn how to parse different timestamp formats.

> Applications can then decide whether this timestamp should be filled using NTP, local device times or another timing solution such as GPS or PTP (precision time protocol). This way the block becomes NTP-independent while not having to add additional elements making it unnecessarily big. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Jan 2011 22:27:03 +0000

Hi,

On 18 Jan 2011, at 13:43, Brandenburg, R. (Ray) van wrote:
...
> What exactly do you mean by 'previous RTCP approach'?

A separate RTCP packet type, in the same way RTCP SR packets are their own packet type.

> The main reason we went with an RTCP-XR report block was that we believed it would be less controversial to add an XR block type than a completely new RTCP packet type. In RFC5968 (which I believe…

As I said, I think using RTCP XR is appropriate for receivers to provide feedback to the sender on receipt and presentation times for RTP packets. 

I don't think an RTCP XR block is appropriate to, as your draft phrases it, "indicate synchronization settings instructions to a receiver". That seems to be providing guidance on when to playout the media, rather than conveying a metric on how well media playout is doing. This message from MSAS to SC would be better expressed as a new RTCP packet type, I think.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 20 Jan 2011 08:29:45 +0000

> In RFC3550, absolute timestamps of this sort are represented using the format of NTP, even though implementations are not required to run NTP [RFC3550 section 4]. I'd suggest this draft follow the…

I agree, that would make sense. I will start work on some SDP parameters to specify which clock, both type and source (such as which NTP server), is used. 

Ray

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 20 Jan 2011 08:43:10 +0000

Hi,

On 19 Jan 2011, at 23:27, Colin Perkins wrote:

...

>I don't think an RTCP XR block is appropriate to, as your draft phrases it, "indicate synchronization settings instructions to a receiver". That seems to be providing guidance on when to playout the…

I agree that this sentence is somewhat misleading and leads one to believe that this IDMS message is some sort of control/command protocol. That is not our goal. The message is used to inform receivers of how media playout is doing on their slowest peer receiver. They can then use this information to possibly synchronize their own playout to this peer, although this is not required. In practice, a receiver would probably only synchronize when the playout difference crosses some threshold (e.g. for Social TV >150ms), to not cause unnecessary stutters for the user.

Ray