[AVTCORE] Fwd: [mengelbart/rtp-over-quic-draft] RoQ Implementation Experience (Issue #219)
Bernard Aboba <bernard.aboba@gmail.com> Tue, 21 May 2024 13:27 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14AC14F74E for <avt@ietfa.amsl.com>; Tue, 21 May 2024 06:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaB-U3u-3SVG for <avt@ietfa.amsl.com>; Tue, 21 May 2024 06:27:11 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDF6C14F739 for <avt@ietf.org>; Tue, 21 May 2024 06:27:11 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6f4ed9dc7beso3260467b3a.1 for <avt@ietf.org>; Tue, 21 May 2024 06:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716298031; x=1716902831; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=7tV1poE2MhqqJPhJbgZD48MQwyTvgJ62okxb3Zn4J5E=; b=NeKZOGm68IAnyohUCygjMP6tRJGHIv122q/hmoJlhkN4ZiSIoU52i4KKOtAzyFaP5q kyf0Ms0ZlwUtd2ob1j+G2qMk75IyqqVrgiY5Mp5xYZ1mNysiwRde1n3L6EbrpfXK8pl6 rMdB7DIVmvoo9ZF5x9O1D9cAHXZKARcZuw37y8EtJbUdPNFSsStj3kCHKUyNsSjzF9HJ Dn3IXcpFDVeqQMtl7uE2EgxTpBY0CURu7xWJIA52euc/OtQ/J7o/5kP1BUwJJBTp2aRe yVDm3bJuQLdgY84HPpgN/LGmyxkg1KEpNYsljZOmQyIBDssgTFcv0uUyG7OXACUFVaVz WtRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716298031; x=1716902831; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7tV1poE2MhqqJPhJbgZD48MQwyTvgJ62okxb3Zn4J5E=; b=dfnDb6N7npYq0dVnNuoAbCNSBBf789CTxYeonALXxnGDzIgTTRAHpingd/WpbR6ENB E7bDPK7urKNkIKFvVpbuBf2ZV6zdv+0pRIcKZu04O8dNSmSmsaQtCytIGe0R6fJGdFCR DvhhVI45kcwB05w1JV82O6nW+LYRJu96PkZqSBK+sgZRNee6IRWdd1I8AepN1R62f0cs DegVODXjzjqLu27jf1KxFxkOf8V8zPuZ198Myc7yKQO6FqV+BQ5d17Nqs+ZDS5SgRany soJdovoaM6fy/gziADUtr5CX2ThoKml8CLG4sr/Y1EiiW1wwQlaXpLIvAGC8swGXNE20 jwHw==
X-Gm-Message-State: AOJu0YyxeI08+blQq2WhmUmWb9Zi+RCIL7w6Wrw59NEC2NJ0gQ6lv6Lw QTG6kmf2ZeStQfuZ/CbCi9605u/cqIR+y4OptvElockQlDOFn5SiUbX0rY1Yu0un3qK671pEvNe Nth+EZSwaVO6PovCjidRZnwdJuZBf4xqz
X-Google-Smtp-Source: AGHT+IGfp0g4M3buWU4Dp2in2xMR6O+CfsI42YYyaecUNR0ziX91YJQWG7/BqbLC/AIgy6SFctyM4vRRwLgSo1FpzjQ=
X-Received: by 2002:a05:6a00:8d06:b0:6f3:e9bc:cc3d with SMTP id d2e1a72fcca58-6f69fb7dc1emr11705933b3a.3.1716298030514; Tue, 21 May 2024 06:27:10 -0700 (PDT)
MIME-Version: 1.0
References: <mengelbart/rtp-over-quic-draft/issues/219@github.com> <mengelbart/rtp-over-quic-draft/issues/219/2122236739@github.com>
In-Reply-To: <mengelbart/rtp-over-quic-draft/issues/219/2122236739@github.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 21 May 2024 06:26:59 -0700
Message-ID: <CAOW+2dsM10pFGm39DKRe0PLkBd5kYVT7DqSTfeGoMhAN4F54_Q@mail.gmail.com>
To: IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000700b4e0618f6c61e"
Message-ID-Hash: OXDVA5MIKMVFA52MFHKFC2UF3JQGNBHG
X-Message-ID-Hash: OXDVA5MIKMVFA52MFHKFC2UF3JQGNBHG
X-MailFrom: bernard.aboba@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-avt.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [AVTCORE] Fwd: [mengelbart/rtp-over-quic-draft] RoQ Implementation Experience (Issue #219)
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/QJY9w2K212Aqjk6r1CT8NFkCsYY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Owner: <mailto:avt-owner@ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Subscribe: <mailto:avt-join@ietf.org>
List-Unsubscribe: <mailto:avt-leave@ietf.org>
Speaking just for myself, updating Appendix C would be fine with me. ---------- Forwarded message --------- From: Mathis Engelbart <notifications@github.com> Date: Tue, May 21, 2024 at 2:55 AM Subject: Re: [mengelbart/rtp-over-quic-draft] RoQ Implementation Experience (Issue #219) To: mengelbart/rtp-over-quic-draft <rtp-over-quic-draft@noreply.github.com> Cc: Author <author@noreply.github.com> There are at least two different implementations. BBC has published a set of Gstreamer plugins <https://github.com/bbc/gst-roq> implementing RoQ. I don't know how much of the draft it implements. The implementation linked in Appendix C <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-10#appendix-C> is the implementation we used for the initial experiments focusing on congestion control which we presented when we started working on the draft. That implementation <https://github.com/mengelbart/rtp-over-quic> is not up to date with the current draft, mainly because the stream mapping does not use a length field. Since that implementation is somewhat outdated and includes a lot of features that are not related to RoQ, we moved the RoQ-specific parts to a new library. The new library <https://github.com/mengelbart/roq> is up to date with the latest draft and only includes the RoQ encapsulation for streams and datagrams. Reading the document, it is not clear how. much of the specification was implemented. I think we can update Appendix C to answer these questions, or alternatively add a new regular (sub)section to the draft. What would you prefer? Answers regarding our (new) implementation: Section 1.1 says: " This document describes an application usage of QUIC ([RFC9308]). As a baseline, the document does not expect more than a standard QUIC implementation as defined in [RFC8999], [RFC9000], [RFC9001], and [RFC9002], providing a secure end-to-end transport. Beyond this baseline, real-time applications can benefit from QUIC extensions such as unreliable DATAGRAMs [RFC9221], which provides additional desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking). " [BA] Does this imply that the RoQ implementation only supported QUIC reliable streams and not "RoQ datagrams"? No, our implementation supports both. Section 3 "RoQ allows the use of both QUIC streams and QUIC DATAGRAMs to transport real-time data, and thus, if RTP packets are to be sent over QUIC DATAGRAMs, the QUIC implementation MUST support QUIC's DATAGRAM extension." [BA] Does the RoQ implementation support both QUIC streams as well as QUIC datagrams? Yes, our implementation supports both. "[RFC9221] does not provide demultiplexing between different flows on DATAGRAMs but suggests that an application implement a demultiplexing mechanism if required. An example of such a mechanism would be flow identifiers prepended to each DATAGRAM frame as described in Section 2.1 of [I-D.draft-ietf-masque-h3-datagram]. RoQ uses a flow identifier to replace the network address and port number to multiplex many RTP sessions over the same QUIC connection." [BA] Was the demultiplexing mechanism for DATAGRAMS implemented? We implemented the flow identifier, and it is used in streams and datagrams as described in section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-10#section-5> Section 3.1.5 " This document defines a flow identifier for multiplexing multiple RTP and RTCP ports on the same QUIC connection to conserve ports, especially at NATs and firewalls. Section 5.1 describes the multiplexing in more detail. " [BA] Was the flow identifier implemented for multiplexing multiple RTP and RTCP ports on the same connection? Yes, the flow identifier can be used to multiplex multiple RTP and RTCP streams on the same connection. "A sender can use these capabilities to more effectively exploit multiple paths between sender and receiver with no action required from the application, even if these paths have different path characteristics. " [BA] Was any experimentation done with multi-path QUIC? No. Section 3.2 "Indeed, an application can use both QUIC streams and DATAGRAM encapsulations on the same QUIC connection." [BA] Were streams and DATAGRAM encapsulations both implemented? Yes, our implementation supports both and allows using both simultaneously, given that the datagram extension was negotiated. Section 3.2 " There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC STREAM frames. " [BA] We have seen implementations that do include a default priority between DATAGRAM and STREAM frames. One question that has arisen is whether the choice (prioritizing DATAGRAM vs. STREAM frames) affects whether RTCP should be encapsulated in STREAM or DATAGRAM frames. Did the RoQ implementation look at the influence of default priority? The tests with our initial implementation used RTCP over datagrams and we did not further investigate the influence of priorities between streams or datagrams. That is something we should look at in future experiments. " DATAGRAM frames do inherit the QUIC connection's congestion controller. This means that although there is no frame-level flow control, DATAGRAM frames can be delayed until the controller allows them to be sent or dropped (with an optional notification to the sending application). Implementations can also delay sending DATAGRAM frames to maintain consistent packet pacing (as described in Section 7.7 of [RFC9002]), and can allow an application to specify a sending expiration time, but these capabilities are not mandated by the standard and might not be present in all implementations." [BA] This is another area where there appears to be significant variation between QUIC implementations. Did the RoQ implementation have experience with the effect of these differences (e.g. delay in sending vs. dropping on expiration)? No. " * If the use of DATAGRAMs was critical for the application, the endpoint can simply close the QUIC connection, allowing someone or something to correct this mismatch, so that DATAGRAMs can be used. * If the use of DATAGRAMs was not critical for the application, the endpoint can negotiate the use of QUIC streams instead. " [BA] Did the RoQ implementation support one of these policies? Our implementation exposes an API that allows applications to send RTP over streams or datagrams. If datagrams cannot be sent, an error will be exposed to the application, and it is the choice of the applications to close the connection or try using streams. The behavior also depends on what was signaled out of band. 3.3. Supported RTP Topologies [BA] Did the RoQ implementation attempt support for RoQ to RTP/UDP translation? No. Section 4 "This allows different RTP sessions, which might use different RTP profiles, to be carried within the same QUIC connection." [BA] Did the RoQ implementation support carrying multiple RTP sessions within the same QUIC connection? Our implementation supports multiplexing using the flow identifier, but we did not run any experiments with multiple sessions on the same connection. Section 4.1 " Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier. [BA] What is an example of a "non-compatible experiment"? Would this be a RoQ implementation that doesn't interoperate with the RoQ implementation code? Also, curious about whether we should expect implementations of the published RFC using the "roq" ALPN to interoperate. I would consider the first implementation we presented as now being incompatible because it does not use a length field for RTP packets sent on a stream. That will be an interoperability issue because a receiver expecting the length field cannot know where RTP packets start or end. Unfortunately, it was implemented before the addition of this subsection and thus now uses the "rtp-mux-quic" ALPN, but that is no longer used in the current draft. This subsection is to be removed before publication. I would expect RoQ implementations to interoperate with other RoQ implementations, and I would expect implementations using the "roq" ALPN to implement the final RFC and be interoperable. Section 5 "Senders MAY combine both modes by sending some RTP packets over the same or different QUIC streams and others in DATAGRAMs." [BA] Did the RoQ implementation include support for both modes? If so, what happened if a RoQ peer did not support both? For example, if the RoQ implementation supported DATAGRAMS and sent RTP/RTCP using them, but did not receive DATAGRAM frames from the peer, only STREAM frames? Would it switch to use of STREAM frames? Or would communication fail? Our implementation supports both modes. If the QUIC peer announces support for receiving datagrams, the application using our implementation can send datagrams. If the peer does not announce support for the datagram extension, the application cannot send datagrams, and the API will return an error. Sending and receiving datagrams are independent, thus if a sender sends datagrams but does not receive datagrams, it will not switch to streams and communication will not fail (since it can only send datagrams if the peer announced support). Section 5.1 "RTP packets of different RTP sessions MUST use distinct flow identifiers. If endpoints wish to send multiple types of media in a single RTP session, they can do so by following the guidance specified in [RFC8860]." [BA] Was support for multiple RTP sessions implemented? See above, our implementation supports multiplexing using flow identifiers, but we did not run any tests using multiple sessions. "A single RTP session can be associated with one or two flow identifiers. Thus, it is possible to send RTP and RTCP packets belonging to the same session using different flow identifiers. RTP and RTCP packets of a single RTP session can use the same flow identifier (following the procedures defined in [RFC5761]), or they can use different flow identifiers." [BA] Did the RoQ implementation support sending RTP and RTCP using different flow identifiers? Yes, see above. " The association between flow identifiers and RTP streams MUST be negotiated using appropriate signaling. The signaling happens out of band and thus a stream or DATAGRAM with a given flow identifer can arrive before the signaling finished. In that case, an endpoint cannot associate the stream or DATAGRAM with the corresponding RTP stream. " [BA] Did the RoQ implementation require creation of the association via signaling? We did not implement signaling. In our test applications, parameters were static. There have been RTP implementations in which an event is triggered on arrival of a non-signaled flow identifier, allowing the application to decide whether to accept the incoming stream or not. If the incoming stream is accepted, the mapping between flow id and SSRC could be authorized. This allows for the handling of incoming streams without signaling, or if the signaling has not yet arrived. For example, if the application feels it can render the incoming stream (subject to the limits described in the rest of the paragraph) it can choose to do so. "If the number of buffered streams exceeds the limit on buffered streams, the endpoint MUST send a STOP_SENDING with the error code ROQ_UNKNOWN_FLOW_ID. " [BA] Was this implemented? This was added very recently. It is implemented in our implementation, but we did not extensively test it (yet). Section 5.2 " A RoQ sender can open new QUIC streams for different RTP packets using the same flow identifier. " [BA] Was this implemented? Yes, see above. — Reply to this email directly, view it on GitHub <https://github.com/mengelbart/rtp-over-quic-draft/issues/219#issuecomment-2122236739> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGFO2YRCUCYCSXWKV6KNBDZDMKXTBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVEZTKNZRGQ3TCMJYQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSGMYDGNRRHA3TSNNHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .
- [AVTCORE] Fwd: [mengelbart/rtp-over-quic-draft] R… Bernard Aboba