Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)
draft-ietf-avtcore-idms-13

[Ballot discuss]
revised (trimming it down after -13 addressed the 1st issue)

Another thought is what happens if one end hosts is using SRTP with an appropriate algorithm suite but the other end host doesn't?  Obviously, the correlation identifier is disclosed and I guess so is the media stream.  Is there a way for end hosts to ensure that every other end host is also using SRTP before agreeing to use this protocol?

[Ballot comment]
Thank you for addessing my Discuss ...

Which was In 2.1.  Applicability of RTCP to IDMS

  Currently, a large share of real-time applications make use of RTP
  and RTCP [RFC3550].  RTP provides end-to-end network transport
  functions suitable for applications requiring real-time data
  transport, such as audio, video or data, over multicast or unicast
  network services.  The timestamps, sequence numbers, and payload
  (content) type identification mechanisms provided by RTP packets are
  very useful for reconstructing the original media timing, and for
  reordering and detecting packet loss at the client side.

Is this "and for detecting reordering and packet loss"? I'm reading the current text as saying that these RTP mechanisms are useful for reordering RTP packets ...

In 4.  Inter-Destination Media Synchronization (IDMS) use cases

  Another potential use case for IDMS is a networked video wall.  A
  video wall consists of multiple computer monitors, video projectors,
  or television sets tiled together contiguously or overlapped in order
  to form one large screen.  Each of the screens reproduces a portion
  of the larger picture.  In some implementations, each screen may be
  individually connected to the network and receive its portion of the
  overall image from a network-connected video server or video scaler.
  Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
  potentially faster.  If the refresh is not synchronized, the effect
  of multiple screens acting as one is broken.

It's left to my imagination what "the effect is broken" means for this use case- is it that users can detect it, or it's distracting, or it causes seizures (as do pulsing/strobe lights), or ... could you nail this down a little? The first and third use cases are descriptive about the effects of nonsynchronization, so that's why I'm asking.

In 8.  RTCP Packet Type for IDMS (IDMS Settings)

  Packet Received NTP timestamp: 64 bits.  This timestamp reflects the
  wall clock time at the reference client at the moment it received the
  first octet of the RTP packet to which this packet relates.  It can
  be used by the synchronization algorithm on the receiving SC to
  adjust its playout timing in order to achieve synchronization, e.g.
  to set the required playout delay.  The timestamp is formatted based
  on the NTP timestamp format as specified in [RFC5905].  See Section 9
  for more information on how this field is used.  Because RTP
  timestamps do wrap around, the sender of this packet SHOULD use
  recent values, i.e. choose NTP timestamps that reflect current time
  and not too far in the future or in the past.

I wish "not too far in the future or in the past" could be a little more precise, but if you tell me the definition of "not too far" is use case-dependent, the current text is fine ...

[Ballot comment]
This is a nervous "No objection". I'd be a lot more comfortable if I knew that NTP folks had worked on, or at least reviewed, this document. Did that take place? If not, a review in NTP should definitely be solicited. I'm an NTP amateur, but certain parts of this document caused my eyebrows to raise.

Section 3: What does "indicate requirement levels for compliant implementations" mean exactly? That doesn't sound like what 2119 means.

Section 5, last paragraph: Though I agree with Richard that "wallclock" is now a well-used enough term in these circles to leave it in there, I think the claim that it is *necessary* for wallclocks to be synchronized is actually incorrect. It is certainly a straightforward and effective way to implement this, but I think I could alternatively come up with a pretty easy way for Alice and Bob to simply have relative offset to the media server's time, but not to each other and not to some reference time, and still be able to sync the media. See comment on section 9 below.

Section 7, third paragraph: I don't understand the SHOULDs in this paragraph. For example, in the first sentence are you saying that SCs are *only* to report on recently received packets and SHOULD NOT report on old ones? Or are you saying that it SHOULD report whenever it receives packets and not delay reports? I don't understand what this means. I have similar questions about the SHOULD in the third sentence. And since these are SHOULDs and not MUSTs, I suppose there are valid reasons to violate them. Can you give some idea of what those reasons might be?

Section 7, definitions of BT, Block Length, and SSRC, and Section 8, SSRC: The SHALLs in there are silly. Why not just use "is"? Who would think to violate these so-called "requirements"?

Section 7 and 8, Packet Presented NTP timestamp: "If this field is empty, then it SHALL be set to 0..." I don't understand what that means. Are you simply saying: "If this field is set to 0, it means that no Packet Presented NTP timestamp is available"? I don't get it.

Section 9:

  Applications performing IDMS may or may not be able to choose a
  synchronization method for the system clock, because this may be a
  system-wide setting which the application cannot change.

I agree, and it makes me wonder why the protocol is dependent on a wallclock instead of doing a relative-from-MSAS kind of scheme.

[Ballot discuss]
I'm curious if there's a new security issue introduced by this draft namely that without encryption an eavesdropper is able to deduce that more than one entity is watching/listening to the same media stream (e.g., football match, speed metal concert) based on the Media Stream Correlation Identifier in s7?  I have this funny feeling that it might not be new but is it now easier to do the correlation - I mean there's now the same information in more than one stream so now I can just look for the Media Stream Correlation Identifier right.  Assuming this is new and this draft enables correlation, the draft's security considerations section needs to be explicit about what the Media Stream Correlation Identifier would allow if not protected.  Something along the lines of the following would work, I think:

OLD:

No new mechanisms are introduced in this document to ensure
confidentiality.  Encryption procedures, such as those being
suggested for a Secure RTP (SRTP) at the time that this document was
written, can be used when confidentiality is a concern to end hosts.

NEW:

No new mechanisms are introduced in this document to ensure
confidentiality between the RTP receiver/SC and RTP sender/MSAS.
Encryption procedures, such as those being suggested for a Secure
RTP (SRTP) [REFERENCE] at the time that this document was written,
can be used when confidentiality is a concern to end hosts.  For example,
end hosts concerned that being correlated to the same stream as another
end host need to employ encryption between the RTP receiver and RTP
sender.

Another thought is what happens if one end hosts is using SRTP with an appropriate algorithm suite but the other end host doesn't?  Obviously, the correlation identifier is disclosed and I guess so is the media stream.  Is there a way for end hosts to ensure that every other end host is also using SRTP before agreeing to use this protocol?

[Ballot comment]
r/be tailored through modifications in order to/be tailored to

s4: r/goal/gooooooooooooooooal ;)

Figure 1/s7: Sync-group or SyncGroupId?

Some tweaks were agreed by the authors and the secdir reviewer, but I'll not hold a discuss on these because I trust the AD/authors will spin a new version to incorporate them now (based on other requested changes) or during AUTH48.

[Ballot discuss]
-- Section 14.1 --

  [Note to RFC Editor: please replace TBD with the IANA-provided RTCP
  Packet Type value for this packet type]

I think you need to tell the RFC Editor to fix it in two places in Section 8, as well.

-- Section 14.4 --
This registry is very underspecified.  You need to tell IANA what range the values can have (0 to 15).  You need to tell them that 0 is Reserved.  You need to list values 2 thru 4, with their names and ETSI reference, so they get into the registry as well.  And you need to tell them that 5 to 15 are available for assignment ("Unassigned" is the term we use for this).  You should also include a paragraph with some guidance to the Designated Expert who will review assignment requests, so she will know how to evaluate this.  Should she approve anything?  Probably not, for such a limited resource.  What criteria should she use to decide?

[Ballot comment]
- Section 2.2 --

  Finally, this
  document proposes an IANA registry for SPST values, allowing ETSI to
  register extensions to this document.

Just ETSI?  Or can anyone else use the registry as well?

-- Section 5 --
In the last paragraph: wall clocks?  Those are the clocks on the living room walls that the humans look at -- or is this a well known term of art in RTP?  I presume that Alice and Bob are not actually reporting the time they see (which is what this sounds like), and you're really talking about the ToD clocks in their clients.

-- Section 7 --

  SPST=5-15 Reserved for future use.

Reserved?  Or "Unassigned"?  Aren't they available for assignment in the IANA registry?

-- Section 11 --

"a=rtcp-idms:sync-group=0" is an empty sync group, so this says.  What does "a=rtcp-idms:" mean, and how do they differ?  Should you say this here?

[Ballot discuss]
I might be confused about this, but I needed to ask ... the Discuss should be easy to resolve, whether I'm confused or not.

In 8.  RTCP Packet Type for IDMS (IDMS Settings)

  Packet Received NTP timestamp: 64 bits.  This timestamp reflects the
  wall clock time at the reference client at the moment it received the
  first octet of the RTP packet to which this packet relates.  It can
  be used by the synchronization algorithm on the receiving SC to
  adjust its playout timing in order to achieve synchronization, e.g.
  to set the required playout delay.  The timestamp is formatted based
  on the NTP timestamp format as specified in [RFC5905].  See Section 9
  for more information on how this field is used.  Because RTP
  timestamps do wrap around, the sender of this packet SHOULD use
  recent values, i.e. choose NTP timestamps that reflect current time
  and not too far in the future or in the past.

I don't understand the SHOULD in the last sentence. If a sender doesn't do this, is IDMS still going to work?

I'm curious because I'm reading the Security Considerations discussion about inadvertent or malicious reports of two-hour delays in one device resulting in two-hour delays in other synchronized devices. Might violating this SHOULD cause the same problem?

[Ballot comment]
In 2.1.  Applicability of RTCP to IDMS

  Currently, a large share of real-time applications make use of RTP
  and RTCP [RFC3550].  RTP provides end-to-end network transport
  functions suitable for applications requiring real-time data
  transport, such as audio, video or data, over multicast or unicast
  network services.  The timestamps, sequence numbers, and payload
  (content) type identification mechanisms provided by RTP packets are
  very useful for reconstructing the original media timing, and for
  reordering and detecting packet loss at the client side.

Is this "and for detecting reordering and packet loss"? I'm reading the current text as saying that these RTP mechanisms are useful for reordering RTP packets ...

In 4.  Inter-Destination Media Synchronization (IDMS) use cases

  Another potential use case for IDMS is a networked video wall.  A
  video wall consists of multiple computer monitors, video projectors,
  or television sets tiled together contiguously or overlapped in order
  to form one large screen.  Each of the screens reproduces a portion
  of the larger picture.  In some implementations, each screen may be
  individually connected to the network and receive its portion of the
  overall image from a network-connected video server or video scaler.
  Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
  potentially faster.  If the refresh is not synchronized, the effect
  of multiple screens acting as one is broken.

It's left to my imagination what "the effect is broken" means for this use case- is it that users can detect it, or it's distracting, or it causes seizures (as do pulsing/strobe lights), or ... could you nail this down a little? The first and third use cases are descriptive about the effects of nonsynchronization, so that's why I'm asking.

In 8.  RTCP Packet Type for IDMS (IDMS Settings)

  Packet Received NTP timestamp: 64 bits.  This timestamp reflects the
  wall clock time at the reference client at the moment it received the
  first octet of the RTP packet to which this packet relates.  It can
  be used by the synchronization algorithm on the receiving SC to
  adjust its playout timing in order to achieve synchronization, e.g.
  to set the required playout delay.  The timestamp is formatted based
  on the NTP timestamp format as specified in [RFC5905].  See Section 9
  for more information on how this field is used.  Because RTP
  timestamps do wrap around, the sender of this packet SHOULD use
  recent values, i.e. choose NTP timestamps that reflect current time
  and not too far in the future or in the past.

I wish "not too far in the future or in the past" could be a little more precise, but if you tell me the definition of "not too far" is use case-dependent, the current text is fine ...

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtcore-idms-09..  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there are three actions which we must complete.

First, in the RTCP Control Packet types (PT) subregistry of the Real-Time Transport Protocol (RTP) Parameters registry located at:

www.iana.org/assignments/rtp-parameters/rtp-parameters.xml

a new RTCP Control Packet type will be registered as follows:

Value: [ TBD-at-registration ]
Abbrev: IDMS
Name: Inter-destination Media Synchronization
Reference: [ RFC-to-be ]

Second, in the RTCP XR Block Type subregistry of the RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry located at:

http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml

the registration for the block type 12 - Inter-destination Media Synchronization Block - will have its reference changed from:

[http://www.etsi.org/deliver/etsi_ts/183000_183099/183063/][ETSI 183 063][Miguel_Angel_Reina_Ortega]

to:

[ RFC-to-be ]

Third, in the att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new att-field media level only registration will be made as follows:

Type: att-field (media level only)
SDP Name: rtcp-idms
Reference: [ RFC-to-be ]

We understand that these three actions are the only ones required to
be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Inter-destination Media Synchronization using the RTP Control Protocol
  (RTCP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a new RTP Control Protocol (RTCP) Packet Type
  and RTCP Extended Report (XR) Block Type to be used for achieving
  Inter-Destination Media Synchronization (IDMS).  IDMS is the process
  of synchronizing playout across multiple geographically distributed
  media receivers.  Using the RTCP XR IDMS Reporting Block defined in
  this document, media playout information from participants in a
  synchronization group can be collected.  Based on the collected
  information, an RTCP IDMS Settings Packet can then be send to
  distribute a common target playout point to which all the distributed
  receivers, sharing a media experience, can synchronize.

  Typical use cases in which IDMS is usefull are social TV, shared
  service control (i.e. applications where two or more geographically
  separated users are watching a media stream together), distance
  learning, networked video walls, networked loudspeakers, etc.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

This is a standard track RFC defining new RTCP packets and procedures for
synchronizing media between multiple sites.

The title page header indicates it.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:

Technical Summary:

This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP
Extended Report (XR) Block Type to be used for achieving Inter-Destination
Media Synchronization (IDMS). IDMS is the process of synchronizing playout
across multiple geographically distributed media receivers. Typical use
cases in which IDMS is usefull are social TV, shared service control (i.e.
applications where two or more geographically separated users are watching
a media stream together), distance learning, networked video walls,
networked loudspeakers, etc.

Working Group Summary:

This document went through a working group last call. There were comments
and the document was updated to resolve all comments. The work started in
ETSI and since it have to do with RTCP it was brought to the IETF AVTCore
WG. The last issue that took some time was to update the ETSI document
clarifying that the change control will be at the IETF.

Document Quality:

The document got good reviews from AVTcore members.

Personnel:

Roni Even is the Document Shepherd and the Responsible Area Director is
Richard Barnes.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.


The shepherd reviewed the document very carefully in all the versions
including the last one 09.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

This document got good review by mutiple people from AVTcore and all
comments were addressed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,
XML, or internationalization? If so, describe the review that took place.

No need for any such review.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for
it. In any event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes, the shepherd has confirmed with all authors.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

There was a strong consensus to start this work at the IETF when it was
brought. Multiple people contributed to the work and as a result the WG
identified two new work items that are addressed in other new documents
which are currently in progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

No ID nits in this document.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

Not applicable

(13) Have all references within this document been identified as either
normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-avtcore-clksrc-03 that will
start WGLC very soon.

(15) Are there downward normative references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call
procedure.

no

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).

This document defines a new extension URI to the RTP Compact Header
Extensions sub-registry of the Real-Time Transport Protocol (RTP)
Parameters registry. The registration was reviewed by the document shepherd
and it follows the registration requirements.



No new IANA registries are defined.



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

No new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.

There is an ABNF definition for using the new RTCP packet using RFC3264
offer answer. This is common for any new RTCP packe