Comments to date on DRAFT REVISED AES67-xxxx AES standard for audio applications of networks - High-performance streaming audio-over-IP interoperability
, published 2018-02-14 for comment.
The comment period has closed. There are no unresolved comments.
Comment received from Magnus Danielson, 2018-03-14
After reviewing the AES67-xxxx draft I have the following comments.
1) PTP Synchronization context has changed. While AES67-2013 anticipated SMPTE ST 2059, it has now arrived and it futher used in SMPTE ST 2110 which also includes an AES67 profile. The AES67 readers should be made aware of this additional context.
Proposed text:
Clause 4.2:
add to end of clause:
NOTE: AES67 as included into the SMPTE ST2110-30 and thus using SMPTE ST2110-10 PTP timing profile needs to follow SMPTE ST 2059-1 and ST 2059-2. A summary of PTP profiles exists in AES-R16-2016.
Annex A.2.2:
add after first paragraph:
NOTE: AES67 as included into the SMPTE ST2110-30 and thus using SMPTE ST2110-10 PTP timing profile needs to follow SMPTE ST 2059-1 and ST 2059-2. A summary of PTP profiles exists in AES-R16-2016.
2) Media profile identification needs to be updated on publishing.
Annex A.2.1:
AES67-2013 needs to be replaced with AES67-2018.
3) Significant issues of using AES67 implementation in WAN context. Fortunately relative small adjustments will provide basic support hints, as solutions already exists. This was the basis of my VidTrans 2018 presentation. This is experienced built on many years of testing many implementations over various distances, and the increasing use thereof in TV productions amongst others.
Clause 7.2.2:
add to end of clause:
NOTE: Longer packet delivery times may be supported to accommodate wide area (WAN) scenarios where minimum delay can be significant.
Clause 7.4:
add to end of clause:
NOTE: For wide area network (WAN) use, the minimum delivery time of the network can be significant due to the distance and the speed of light in cables. For such scenario an estimation of minimum time can be used. Alternatively a synthonization mode can be used to time out samples based in receive time-stamps or buffer fill-level only. For both these methods the receive buffer only compensates experienced jitter.
Clause 7.5:
Add after first paragraph:
NOTE: For LAN implementations minimum delivery times is assumed to be 0 s. For WAN scenarios this should either be set or estimated usign a minimum delay estimator. Such alternatives should be selectable receiver mode for that set of channels. Some implementation can support significant delays assuming minimum delay of 0, but then utilizing a huge memory buffer effectively not being used.
Response from K. Gross, 2018-04-05
Magnus,
Thank you for reviewing and commenting on our AES67 draft revision. Your comments have been disscussed in the SC-02-12-M task group and the following dispositions have been agreed to to address these comments.
1) AES R16 gives the synchronization standards context requested here. The draft has been revised to add an informative reference to AES R16 to Annex F of the draft.
2) As an editorial matter, we have changed the "AES67-2013" reference in A.2.1 to "AES67-2018"
3) This comment elicited considerable discussion of WAN applications for AES67 and we have initiated a project within the task group to explore this further. However, the stated scope of AES67 is local-area networks to enterprise-scale networks with wide-area networks and the public Internet specifically excluded. The standard adequately addresses the issues raised in these comments for in-scope networks and so the suggested changes are felt to be unnecessary.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
Comment received from Normunds Veselis, 2018-03-20
The proposed draft comes into conflict with an existing standard IEEE 1588-2008 (PTP). In draft AES67, Table A.1 first item and PICS clause A.2.2-4 both specify that the allowed range of the attribute "defaultDS.domainNumber" is to be 0-255. IEEE 1588-2008 only allows range 0-127 for this attribute, whereas numbers 128-255 are reserved.
Proposing to change the text of AES67 as follows:
Change 1: "Table A.1 – attribute values for use with Media profile"
"Attribute": defaultDS.domainNumber
"Values":
Current edition: The default initialization value shall be 0. Other values (0 to 255) are allowed.
Proposed change: The default initialization value shall be 0. The configurable range shall be 0 to 127.
"Feature":
Current edition: defaultDS.domainNumber range 0-255
Proposed change: defaultDS.domainNumber range 0-127
"Notes":
Current edition: Mark as supported if all other values (0 to 255) are allowed
Proposed change: Mark as supported if all values 0 to 127 are allowed
Response from K. Gross, 2018-04-05
Normunds,
Thank you for reviewing and commenting on our AES67 draft revision.
The Media profile should not use IEEE 1588 reserved domain numbers unless the reserved numbers are reserved for use by PTP profiles which does not appear to be the case here. We have revised the draft to include your proposed changes.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
Comment received from Tom Levno, 2018-03-21
We offer the following comment with reference to aes67-r-141107-draft-rev-cfc-rc4.doc
With regard to the following
“6 Transport
6.0 ...
6.1 Network layer
Media packets shall be transported using IP version 4 as defined in RFC 791.
NOTE 1 Although care has been taken in the design of this standard to facilitate future support for IPv6, support for IPv6 is outside the scope of this revision of the standard.”
We suggest the following substitution.
“6 Transport
6.0 ...
6.1 Network layer
Media packets shall be transported using IP version 4 as defined in RFC 791 or using IP version 6 as defined in RFC 8200.”
In view of the Internet Architecture Board's "Statement on IPv6," November 7, 2016 [1], and Internet Engineering Task Force (IETF) Best Current Practice (BCP) 177, "IPv6 Support Required for All IP-Capable Nodes," [2] we believe it is inappropriate for the AES to standardize a protocol that is not compatible with dual-stack (IPv4 and IPv6) or IPv6-only hosts.
We recognize that some implementers may choose to disregard BCP 177 and continue to produce IPv4-only products, but considering the stated positions of the IAB and IETF, the exhaustion of the IPv4 address pools at all Regional Internet Registries, and the difficulties encountered by NTC's clients in assigning unique IPv4 addresses within large enterprises, we believe implementers of AES 67 should be free to meet marketplace demands for IPv6 compatibility, if they choose.
Thank you for reviewing and commenting on our AES67 draft revision.
The AES does intend to revise the standard to support IPv6 and you are welcome to join the SC-02-12-M task group to assist us in doing so. As AES67 is designed for use on local and campus area networks where private addressing is typically used and not on the public internet where IPv4 address exhaustion exists, we beleive the other important updates included in this revision should not be delayed waiting for IPv6 capability to be included.
Kevin Gross - AVA Networks
Vice chair AESSC working group SC-02-12 on Audio Applications of Networks
