From 637735bd89a1df5439104534346dfe7efb1c4b39 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 17 Sep 2023 00:18:11 +0000 Subject: [PATCH] Script updating archive at 2023-09-17T00:18:11Z. [ci skip] --- archive.json | 145 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 113 insertions(+), 32 deletions(-) diff --git a/archive.json b/archive.json index f4531ff..09de852 100644 --- a/archive.json +++ b/archive.json @@ -1,6 +1,6 @@ { "magic": "E!vIA5L86J2I", - "timestamp": "2023-09-05T00:16:15.487359+00:00", + "timestamp": "2023-09-17T00:18:08.524858+00:00", "repo": "mengelbart/rtp-over-quic-draft", "labels": [ { @@ -1722,9 +1722,17 @@ ], "body": "Related to #13 but also applicable to the rest of the specification.\r\n\r\nRTP over QUIC is an application layer mapping for RTP applications. \r\n\r\nWhen using STOP_SENDING or RESET_STREAM, the code has to be an application-layer error code, and you don't have one. Without that, people will just pick random numbers (or worse, send 0 for everything). \r\n\r\nDefining codes isn't too hard, we should put some thought into gradeful or abrupt conditions that can be communicated via error codes", "createdAt": "2023-03-28T05:30:40Z", - "updatedAt": "2023-07-27T22:44:05Z", + "updatedAt": "2023-09-15T15:22:48Z", "closedAt": null, - "comments": [] + "comments": [ + { + "author": "SpencerDawkins", + "authorAssociation": "COLLABORATOR", + "body": "@LPardue - do you plan to provide text for this issue by the next AVTCORE interim? ", + "createdAt": "2023-09-15T15:22:48Z", + "updatedAt": "2023-09-15T15:22:48Z" + } + ] }, { "number": 77, @@ -2038,7 +2046,7 @@ "id": "I_kwDOFUmh7s5mLgfc", "title": "Using streams, datagrams, and per-RTP-frame streams with RoQ", "url": "https://github.com/mengelbart/rtp-over-quic-draft/issues/93", - "state": "OPEN", + "state": "CLOSED", "author": "SpencerDawkins", "authorAssociation": "COLLABORATOR", "assignees": [ @@ -2049,8 +2057,8 @@ ], "body": "We may need a short section explaining the ROQ-specific tradeoffs", "createdAt": "2023-05-17T16:52:12Z", - "updatedAt": "2023-09-01T14:46:48Z", - "closedAt": null, + "updatedAt": "2023-09-15T15:07:17Z", + "closedAt": "2023-09-15T15:07:17Z", "comments": [ { "author": "SpencerDawkins", @@ -2192,13 +2200,28 @@ "mengelbart" ], "labels": [ - "NextInterim" + "Discussion required" ], "body": "STOP_SENDING/RESET_STREAM currently does not allow sending media frames on a new QUIC stream if they were previously sent on a QUIC stream that received STOP_SENDING/RESET_STREAM. We need to figure out if that is a problem if there are dependencies between those media frames.", "createdAt": "2023-07-27T23:20:10Z", - "updatedAt": "2023-07-27T23:20:10Z", + "updatedAt": "2023-09-15T15:20:23Z", "closedAt": null, - "comments": [] + "comments": [ + { + "author": "mengelbart", + "authorAssociation": "OWNER", + "body": "Consider the following scenario: A sender sends a group of pictures consisting of media frames A, B and C, where A is a keyframe, B depends on A, and C depends on B:\r\n\r\n`A <- B <- C`\r\n\r\nThe sender starts sending frames A and B on QUIC stream 1 but receives STOP_SENDING before it can send frame C. According to the draft (and RFC 9000), it now has to send RESET_STREAM on QUIC stream 1 and continue to send frame C on a different QUIC stream. Additionally, it MUST NOT retransmit frames A or B on *any* QUIC stream. If A or B was lost, sending frame C does not make sense since the receiver cannot decode it.\r\n\r\nSome options are:\r\n\r\n* Drop C and continue with the next frame that is decodable independently from A and B (and C)\r\n * Problem: may unnecessarily drop frames\r\n* Send C as an independently decodable frame\r\n * may not always be possible because it depends on interaction with the encoder.\r\n* Allow dependencies to be retransmitted on different streams\r\n * Problem: Potentially results in situations where the receiver asks to stop, but the sender continues sending the same frames anyway, just on different QUIC streams.\r\n\r\n*Side note:* The real problem here is the receiver sending STOP_SENDING without knowing what trouble it is causing the sender. Maybe receivers should not try to be smart about what they read from streams and where to stop.\r\n\r\n*Comments on CLOSE_STREAM and ENOUGH:* These would enable the sender and receiver to agree on where exactly the receiver can stop reading from the current QUIC stream. We could then allow the sender to send everything following that offset on a different QUIC stream. However, we still have to solve the problem regarding STOP_SENDING.\r\n", + "createdAt": "2023-09-15T10:37:17Z", + "updatedAt": "2023-09-15T10:37:17Z" + }, + { + "author": "SpencerDawkins", + "authorAssociation": "COLLABORATOR", + "body": "As of this moment, [Reliable QUIC Stream Resets](https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/) is an adopted QUIC WG draft, and [Signaling That a QUIC Receiver Has Enough Stream Data](https://datatracker.ietf.org/doc/draft-thomson-quic-enough/) is still individual, but our understanding from @marten-seemann is that ENOUGH may be included in [Reliable QUIC Stream Resets](https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/).", + "createdAt": "2023-09-15T15:19:11Z", + "updatedAt": "2023-09-15T15:19:11Z" + } + ] }, { "number": 113, @@ -2212,13 +2235,12 @@ "mengelbart" ], "labels": [ - "NextInterim", "external doc", "Discussion required" ], "body": "Assuming that CLOSE|_STREAM moves forward ...", "createdAt": "2023-07-27T23:56:46Z", - "updatedAt": "2023-08-11T16:04:47Z", + "updatedAt": "2023-09-15T15:21:13Z", "closedAt": null, "comments": [] }, @@ -2283,7 +2305,7 @@ "id": "I_kwDOFUmh7s5tz2Xx", "title": "Reasoning for not mandating a rate adaptation algorithm", "url": "https://github.com/mengelbart/rtp-over-quic-draft/issues/116", - "state": "OPEN", + "state": "CLOSED", "author": "gchandok", "authorAssociation": "NONE", "assignees": [ @@ -2294,8 +2316,8 @@ ], "body": "\r\n\r\nA rate adaptation algorithm can be plugged in to adapt the media\r\n bitrate to the available bandwidth. This document does not mandate\r\n| any specific rate adaptation algorithm, _because the desired response\r\n| to congestion can be application and codec-specific. For example,\r\n| adjusting quantization in response to congestion may work well in\r\n| many cases, but if what's being shared is video that includes text,\r\n| maintaining readability is important._\r\n|\r\n| As of this writing, the IETF has produced two Experimental-track rate\r\n| adaptation specifications, Network-Assisted Dynamic Adaptation (NADA)\r\n| [RFC8698] and Self-Clocked Rate Adaptation for Multimedia (SCReAM)\r\n| [RFC8298]. \r\n\r\n\r\n**Rate adaptation mechanisms like NADA/SCREAM don\u2019t necessarily mandate how the encoder handles the rate changes. That handling may be codec specific so makes sense to leave it out. So the argument and example (in italics) don\u2019t seem appropriate in this section. Rate adaptation mechanism RFCs you mention above talk about how the sending rate should be computed, what feedback is needed and how traffic should be paced / shaped which are not codec specific. You can just say that application may pick a rate adaptation mechanism of its choice and this document does not mandate it. That should be sufficient**", "createdAt": "2023-08-09T01:24:54Z", - "updatedAt": "2023-09-01T10:21:06Z", - "closedAt": null, + "updatedAt": "2023-09-15T15:08:44Z", + "closedAt": "2023-09-15T15:08:44Z", "comments": [ { "author": "SpencerDawkins", @@ -5368,13 +5390,13 @@ "labels": [], "body": "", "createdAt": "2023-08-29T13:02:44Z", - "updatedAt": "2023-08-29T13:02:45Z", + "updatedAt": "2023-09-15T18:39:14Z", "baseRepository": "mengelbart/rtp-over-quic-draft", "baseRefName": "main", - "baseRefOid": "37090ca2ea9f361aee5cfdd7fcb2c001ca5f3751", + "baseRefOid": "feda06569c34b2f31c8acf72027bcd2491dbf274", "headRepository": "mengelbart/rtp-over-quic-draft", "headRefName": "fix/80-rtcp-tables-appendix", - "headRefOid": "f82883716bc74dceed233c2311e64ebb05444b8f", + "headRefOid": "a18316a38e9281a2bb02192c6d7bdbf506092fd9", "closedAt": null, "mergedAt": null, "mergedBy": null, @@ -5387,7 +5409,7 @@ "id": "PR_kwDOFUmh7s5ZVCfe", "title": "Distinguish between adapting media stream contents and media stream \u2026", "url": "https://github.com/mengelbart/rtp-over-quic-draft/pull/121", - "state": "OPEN", + "state": "MERGED", "author": "SpencerDawkins", "authorAssociation": "COLLABORATOR", "assignees": [ @@ -5396,26 +5418,42 @@ "labels": [], "body": "\u2026rate adaptation\r\n\r\nAlso corrected (I think) formats of multiple references to compact header extensions and SDES compact header extensions.\r\n\r\ncloses #116 ", "createdAt": "2023-09-01T11:09:42Z", - "updatedAt": "2023-09-01T11:26:27Z", + "updatedAt": "2023-09-15T15:08:44Z", "baseRepository": "mengelbart/rtp-over-quic-draft", "baseRefName": "main", "baseRefOid": "37090ca2ea9f361aee5cfdd7fcb2c001ca5f3751", "headRepository": "mengelbart/rtp-over-quic-draft", "headRefName": "issue-116", "headRefOid": "88dd572ed45950637ebcf328700cc6c89045ce7a", - "closedAt": null, - "mergedAt": null, - "mergedBy": null, - "mergeCommit": null, + "closedAt": "2023-09-15T15:08:43Z", + "mergedAt": "2023-09-15T15:08:43Z", + "mergedBy": "SpencerDawkins", + "mergeCommit": { + "oid": "feda06569c34b2f31c8acf72027bcd2491dbf274" + }, "comments": [], - "reviews": [] + "reviews": [ + { + "id": "PRR_kwDOFUmh7s5hE9jO", + "commit": { + "abbreviatedOid": "88dd572" + }, + "author": "mengelbart", + "authorAssociation": "OWNER", + "state": "APPROVED", + "body": "", + "createdAt": "2023-09-15T10:47:13Z", + "updatedAt": "2023-09-15T10:47:13Z", + "comments": [] + } + ] }, { "number": 123, "id": "PR_kwDOFUmh7s5ZWO7i", "title": "Describe considerations for streams, datagrams, and a mixture", "url": "https://github.com/mengelbart/rtp-over-quic-draft/pull/123", - "state": "OPEN", + "state": "MERGED", "author": "SpencerDawkins", "authorAssociation": "COLLABORATOR", "assignees": [ @@ -5424,19 +5462,62 @@ "labels": [], "body": "closes #93 \r\n\r\nNote that the \"- No link definition for link ID 'rfcnnnn' warnings are fixed in PR #121", "createdAt": "2023-09-01T14:52:42Z", - "updatedAt": "2023-09-01T14:52:43Z", + "updatedAt": "2023-09-15T15:07:17Z", "baseRepository": "mengelbart/rtp-over-quic-draft", "baseRefName": "main", "baseRefOid": "37090ca2ea9f361aee5cfdd7fcb2c001ca5f3751", "headRepository": "mengelbart/rtp-over-quic-draft", "headRefName": "issue-93", - "headRefOid": "319112907808b9c6baa0a85cb7c348d0a859a588", - "closedAt": null, - "mergedAt": null, - "mergedBy": null, - "mergeCommit": null, + "headRefOid": "feef2b167cd03e43d01b7653c538324f6bc8a416", + "closedAt": "2023-09-15T15:07:16Z", + "mergedAt": "2023-09-15T15:07:16Z", + "mergedBy": "SpencerDawkins", + "mergeCommit": { + "oid": "e487461701ad44d64aea12192b879f3ba1867a22" + }, "comments": [], - "reviews": [] + "reviews": [ + { + "id": "PRR_kwDOFUmh7s5hE_Qa", + "commit": { + "abbreviatedOid": "3191129" + }, + "author": "mengelbart", + "authorAssociation": "OWNER", + "state": "APPROVED", + "body": "", + "createdAt": "2023-09-15T10:52:17Z", + "updatedAt": "2023-09-15T10:52:23Z", + "comments": [ + { + "originalPosition": 19, + "body": "```suggestion\r\n* DATAGRAM frames belong to a QUIC connection as a whole. There is no QUIC-level way to multiplex/demultiplex DATAGRAM frames within a single QUIC connection. Any multiplexing identifiers must be added, interpreted, and removed by an application, and they will be sent as part of the payload of the DATAGRAM frame itself.\r\n```", + "createdAt": "2023-09-15T10:52:17Z", + "updatedAt": "2023-09-15T10:52:23Z" + } + ] + }, + { + "id": "PRR_kwDOFUmh7s5hE_yt", + "commit": { + "abbreviatedOid": "3191129" + }, + "author": "mengelbart", + "authorAssociation": "OWNER", + "state": "COMMENTED", + "body": "", + "createdAt": "2023-09-15T10:53:37Z", + "updatedAt": "2023-09-15T10:53:37Z", + "comments": [ + { + "originalPosition": 19, + "body": "I think adding that it is part of the payload makes it clear that it will not be in any header field of the frame, like the length would be, for example.", + "createdAt": "2023-09-15T10:53:37Z", + "updatedAt": "2023-09-15T10:53:37Z" + } + ] + } + ] } ] } \ No newline at end of file