IEEE 1722.1 Agenda 20190516 AVBTP-DECC@LISTSERV.IEEE.ORG AVBTP@LISTSERV.IEEE.ORG IEEE 1722.1 Work Group Face To Face Meeting Thursday, May 16, 2019 Genk, Belgium Meeting time is 9AM Pacific Daylight Time In advance of joining the meeting, please review the Essential Patent Claims Announcement https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf The policies and procedures for this group can be found here: http://grouper.ieee.org/groups/1722/1/web/P1722_1_WG_PP.pdf Online Zoom Meeting address for this week: https://zoom.us/j/2268818568 One tap mobile +14086380968,,2268818568# US (San Jose) +16699006833,,2268818568# US (San Jose) Dial by your location +1 408 638 0968 US (San Jose) +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 226 881 8568 Find your local number: https://zoom.us/u/cMjKFMQnr IEEE 1722.1 Work Group Face To Face Meeting Thursday, May 16, 2019 Genk, Belgium Review outstanding issues with Milan to IEEE 1722.1 convergence Ongoing discussion: Item 1. How to best constrain the list of connected listeners a talker shall maintain. The current 1722.1 does not mandate a size for the list. Is 0 a valid size for the list? The two proposals for this Item from last week were withdrawn during the discussion and the simplest solution appears to be allowing 0 to be the valid size for the list. If there are objections to this solution, it would be helpful to have a use case to discuss. Item 2. How to best support the method Milan is using to shorten connection time by allowing a listener to respond to a CONNECT_RX_COMMAND from a controller immediately, before attempting to establish a connection to the talker. This is working as intended in the constrained environment of professional audio. How do we prevent this from breaking things while at the same time continue to use it for the advantages it provides. Discussion by the end of the meeting was centering around what would happen if the STREAM_DEST_MAC and STREAM_VLAN_ID fields are set to 0. Since a MAC address of all 0's is not a legal MAC address, the controller can know that the connection hasn't been established, but that the parameters have been written to nonvolatile storage. Informal testing of several controllers has not exposed a problem with STREAM_DEST_MAC and STREAM_VLAN_ID fields that are all zeros, but this does not mean it will always be the case. Defining that the address may be all zeros and should be ignored by devices when that happens might be the best solution for now. Please bring use cases for or against this possible solution. 20181017 (From NYC F2F) Items in Milan which cause backwards compatibility issues with the existing standards and devices: 7.1 A device which responds to an AECP command with an AECP response larger than the maximum allowed by the IEEE standard will be dropped by a standards compliant controller. Increasing descriptor sizes beyond the standard limit can result in devices failing to enumerate as controllers validate responses either for security validation or memory constraints. M M >>>>> True but benefits are higher than drawbacks. A robust implementation should not crash but just drop the too big packet. Note: we allow to increase only size of responses, so it impacts only controllers. Milan reverts 7.3.1 Section 7.3.1 of Milan specifies that the ACQUIRE_ENTITY command shall not be implemented. This violates the standard Clause 5.5.1, 5.6.1, and 5.7.1 which states that Talkers and Listeners and Responders shall implement the AQUIRE_ENTITY command. This command is required in order to support use cases in a shared networking environment. It is optional for a controller to use AQUIRE_ENTITY to grab excusive control of a device. This a controller definition issue, not a Endpoint issue. If this requirement was added because of the observed behaviour of the Audio/Midi Setup checkboxes on macOS, then this was probably due to a misunderstanding between the different use cases for the macOS GUI. In a Pro A environment it is expected that the macOS would behave only as a talker and/or listener through the virtual entity mechanism (see avbutil --virtual-entity). M M >>>>> We should change the standard so that ACQUIRE_ENTITY becomes optional. It’s actually a feature which is oriented specifically to the Consumer application rather than a general feature. It’s even a dangerous feature for the Pro Audio market. 7.3.10 The GET_STREAM_INFO response AECPDU is specific to the Milan connection management protocol. This command should be redefined within the Milan Vendor Unique protocol instead of redefining existing fields and reserved fields which are directly related to ACMP. M M >>>>> What about the CONNECTED flag? ------ bring up as a question in a future meeting : Marc to bring proposal 8.2.1 Section 8.2.1 states "Although the connection management protocol defined here is largely based on ACMP, it differs in some key points. Whenever the protocol defined by this specification differs from ACMP (as defined by the AVDECC standard), the definition in this specification takes precedence." Milan defines a incompatible protocol using the same PDU format and message etherType and subType and command values as the standard. M M >>>>> We did it in a way so that there is no incompatibility with the legacy ACMP. Please give a concrete example of incompatibility. (see Item 2 ) Command codes are renamed and redefined and bit fields are added and new state machine behaviour is added which is incompatible with the existing ACMP standard and existing implementations. M M >>>>> Names are not an issue for compatibility. The new state machine is not incompatible with legacy controllers and talkers. AVnu can choose to create a new protocol using the same PDU format without causing incompatibilities with the standard by requesting and using a new subtype from the IEEE 1722 working group or by encapsulating this PDU format inside a vendor defined AECP message. The current Milan spec for ACMP puts AVnu in the position of claiming open standards conformance yet violating interoperability and conformance with the standard without any perceived benefit. Milan does not claim conformance with existing 1722.1. We recommend that the Milan ACMP variant be encapsulated in the vendor defined AECP message. It is highly recommended that devices implement standard ACMP in addition to the Milan ACMP variant. M M >>>>> Our proposal is to include Milan ACMP state machine in the next 1722.1 revision to update, clarify and fix the legacy state machine. 9.2.1 It is up to the controller to interpret the AEM_PERSISTENT_ACQUIRE_SUPPORTED, GENERAL_CONTROLLER_IGNORE, and ENTITY_NOT_READY flags. Milan controllers should respect the GENERAL_CONTROLLER_IGNORE flag, as this is a mechanism intended to tell them to ignore the device. The AEM_PERSISTENT_ACQUIRE_SUPPORTED flag has no effect on a Milan controller that is not using AQUIRE_ENTITY. M M >>>>> These requirements affect only Milan endpoints, not general AVDECC entities. The requirement about AEM_PERISTENT_ACQUIRE_SUPPORTED is not necessary but is implicit as ACQUIRE_ENTITY is prohibited. ---------------- no change needed to either spec. 9.3.1 If a PAAD-AE has two AVB_INTERFACEs the specification in Milan 9.3 would cause ADPDU to be transmitted with non-synchronized available_index values. Controllers which utilize the available_index value to detect devices that rebooted without sending a departing message will see this device as constantly departing. M M >>>>> Controllers should keep track of ADP messages independently on each port (interface_index field). --- Milan was incorrect See Table 7-2 Offset 36 Length 4 Name available_index Description: The available index of the AVDECC Entity. This is the same as the available_index field in AVDECC Discovery Protocol. See 6.2.1.16. -------------- change entry in table to make it unambigious : This is the same as the available index field in the most recently transmitted ADPDU -------------- Bring this up in next call... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! see Rev 1 6.2.5.2.1. txEntityAvailable() 6.2.5.2.2. txEntityDeparting() If the AVDECC Entity has more than one enabled network port, then the same ADPDU is sent out each port. This is an error because the ADPDU will have a different interface index for each port. Other Recommendations It is recommended that a standard 1722.1 control descriptor be added to the entity model using an Avnu specific control type which identifies either Avnu/Milan capabilities. For instance this could be a LINEAR_UINT64 unitless value which contains flags identifying the facets of the Milan protocol that are supported and is as an indication that the device implements the Milan AECP Vendor Unique Protocol for additional control or queries. M M >>>>> Drawback of the CONTROL: you have to enumerate the entity to get it, while you can send the GET_MILAN_INFO command immediately after receiving the ADP ENTITY_AVAILABLE message. There are other minor technical issues which are not pressing and can be addressed as comments on the document.