From ea5842c642498234da9459b644a0a2121a6b867e Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 31 Jul 2020 19:36:06 +0000 Subject: [PATCH] Script updating archive at 2020-07-31T19:36:05Z. [ci skip] --- archive.json | 271 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 243 insertions(+), 28 deletions(-) diff --git a/archive.json b/archive.json index 1a7c4cdb0e..1af283c89d 100644 --- a/archive.json +++ b/archive.json @@ -1,6 +1,6 @@ { "magic": "E!vIA5L86J2I", - "timestamp": "2020-07-31T01:33:19.472156+00:00", + "timestamp": "2020-07-31T19:36:01.179889+00:00", "repo": "quicwg/base-drafts", "labels": [ { @@ -115916,7 +115916,7 @@ "id": "MDU6SXNzdWU2NjcxNTA5OTQ=", "title": "QUIC/ALPN Version Specific Transport Parameters", "url": "https://github.com/quicwg/base-drafts/issues/3965", - "state": "OPEN", + "state": "CLOSED", "author": "nibanks", "authorAssociation": "MEMBER", "assignees": [ @@ -115928,8 +115928,8 @@ ], "body": "## Problem\r\n\r\nCurrently when a client offers multiple ALPNs when connecting to a QUIC server, it still only offers a single QUIC transport parameters set. This implicitly requires (assumes?) that the single TP set is (must be) valid for every protocol version offered. The same is true for QUIC versions when version negotiation is added.\r\n\r\n## Possible Solution\r\n\r\nWe should allow for the client to offer different settings for different QUIC version or ALPNs (or the corresponding combinations?). If we made a change here, I'd also prefer the solution to **not be dependent on any further TLS changes**, as this would make the solution much more disruptive. It has been suggested on Slack that the ALPS TLS extension might be good for this, but the fact that it would require TLS changes is a non-starter for QUIC v1.\r\n\r\nOne possible solution for fixing this is to modify the format of the existing TPs to a list of { quic_version, alpn, TPs }, and allow for quic_version to be zero and/or alpn to be empty to indicate unrestricted applicability of these TPs (to all versions/ALPNs).\r\n\r\n## Specific Examples of Problem\r\n\r\n- App protocol v1 does not allow server initiated bidi-streams, and it's explicitly an error to set an initial stream count greater than zero. App protocol v2 now has a use for these streams and requires the client to send a count greater than zero.\r\n\r\n- A server supports two related protocols, P1 and P2, but each protocol has a slight different interpretation of unidirectional streams, and require different initial counts to be set.\r\n\r\n- QUIC version 2 wishes to remove or redefine a particular transport parameter.\r\n\r\n## Why Should this be in Version 1?\r\n\r\nIf we don't take a change/fix for this in version 1, it restricts the kinds of changes to TPs we can make in future QUIC versions.", "createdAt": "2020-07-28T15:08:07Z", - "updatedAt": "2020-07-29T11:47:57Z", - "closedAt": null, + "updatedAt": "2020-07-31T19:34:55Z", + "closedAt": "2020-07-31T19:34:55Z", "comments": [ { "author": "DavidSchinazi", @@ -403484,13 +403484,13 @@ ], "body": "This was never explicit for the client as it is usually not possible.\r\n\r\nCloses #3855 in a way that perhaps was not anticipated.", "createdAt": "2020-07-08T06:15:38Z", - "updatedAt": "2020-07-31T01:32:23Z", + "updatedAt": "2020-07-31T04:33:40Z", "baseRepository": "quicwg/base-drafts", "baseRefName": "master", "baseRefOid": "ae8cb066a1763c37ed6f5f05fa8bf71599330c55", "headRepository": "quicwg/base-drafts", "headRefName": "1rtt-before-complete", - "headRefOid": "0c08ec7232ef506e1a153cfd33edb1a25936664d", + "headRefOid": "c92c8928798b82f0fafb9d83cf03d65d2b043698", "closedAt": null, "mergedAt": null, "mergedBy": null, @@ -403539,7 +403539,7 @@ "originalPosition": 15, "body": "I'm not sure I understand the logic here. If the client receives the 1-RTT keys at the same time as the handshake completes, how can it possibly use them before that?", "createdAt": "2020-07-16T01:18:50Z", - "updatedAt": "2020-07-31T01:32:23Z" + "updatedAt": "2020-07-31T04:33:40Z" } ] }, @@ -403559,7 +403559,7 @@ "originalPosition": 15, "body": "Note the \"generally\". It is - in theory - possible for a client to receive keys for TLS before it has completed the handshake. The simplest example is that the client has all the messages necessary, but the server certificate hasn't been authenticated yet (which is a condition for handshake completion). As certificate authentication can take time, there is potentially a time where the client could generate keys and use them without being sure of what the server identity is. Most TLS stacks don't allow that to happen, but it isn't a guarantee that is made anywhere.", "createdAt": "2020-07-16T01:25:39Z", - "updatedAt": "2020-07-31T01:32:23Z" + "updatedAt": "2020-07-31T04:33:40Z" } ] }, @@ -403592,7 +403592,7 @@ "originalPosition": 13, "body": "```suggestion\r\nA client typically receives 1-RTT keys at the same time as the handshake\r\n```", "createdAt": "2020-07-27T16:16:19Z", - "updatedAt": "2020-07-31T01:32:23Z" + "updatedAt": "2020-07-31T04:33:40Z" } ] }, @@ -403612,13 +403612,33 @@ "originalPosition": 15, "body": "Some editorializing might help. How about \"Even if it has 1-RTT keys, a client MUST NOT ..\"", "createdAt": "2020-07-27T23:38:13Z", - "updatedAt": "2020-07-31T01:32:23Z" + "updatedAt": "2020-07-31T04:33:40Z" }, { "originalPosition": 6, "body": "```suggestion\r\nTherefore, the server's use of 1-RTT keys before the handshake is complete is\r\nlimited to sending data. A server MUST NOT process incoming 1-RTT protected\r\n```", "createdAt": "2020-07-27T23:38:17Z", - "updatedAt": "2020-07-31T01:32:23Z" + "updatedAt": "2020-07-31T04:33:40Z" + } + ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4ODY4NTQ0", + "commit": { + "abbreviatedOid": "758eb2a" + }, + "author": "janaiyengar", + "authorAssociation": "CONTRIBUTOR", + "state": "APPROVED", + "body": "a nit, but LGTM", + "createdAt": "2020-07-31T01:43:22Z", + "updatedAt": "2020-07-31T01:43:32Z", + "comments": [ + { + "originalPosition": 16, + "body": "```suggestion\r\ncompletes. Even if it has 1-RTT secrets, a client MUST NOT process\r\n```", + "createdAt": "2020-07-31T01:43:22Z", + "updatedAt": "2020-07-31T04:33:40Z" } ] } @@ -408449,7 +408469,7 @@ ], "body": "There is an issue in current congestion avoidance pseudocode\r\nwhen `max_datagram_size * acked_packet.sent_bytes < congestion_window`\r\ncwnd increment effectively becomes zero, especially because most\r\nimplementations use integer operation to calculate cwnd.\r\n\r\nThis happens when `acked_packet.sent_bytes` is a small value or\r\n`congestion_window` is very big. It may lead to too conservative\r\ncwnd growth during congestion avoidance.\r\n\r\nTo fix the issue, I propose to use a TCP ABC style cwnd growth\r\nduring congestion avoidance: https://www.rfc-editor.org/rfc/rfc3465.html#section-2.1\r\n\r\nBasically it stores accumulated acked bytes in a new\r\nvariable `bytes_acked` and increase cwnd by `max_datagram_size` when\r\n`bytes_acked` reaches to cwnd.", "createdAt": "2020-07-16T17:11:23Z", - "updatedAt": "2020-07-31T00:37:35Z", + "updatedAt": "2020-07-31T19:33:02Z", "baseRepository": "quicwg/base-drafts", "baseRefName": "master", "baseRefOid": "e903869c58f95b154f01560761501dd8d097981e", @@ -408544,6 +408564,13 @@ "body": "FWIW, I should add that this is how quicly implements it. If I remember correctly, that it's also how Chrome implements it.", "createdAt": "2020-07-23T01:39:59Z", "updatedAt": "2020-07-23T01:39:59Z" + }, + { + "author": "junhochoi", + "authorAssociation": "CONTRIBUTOR", + "body": "neqo is implmenting this logic too https://github.com/mozilla/neqo/pull/875", + "createdAt": "2020-07-31T19:18:49Z", + "updatedAt": "2020-07-31T19:18:49Z" } ], "reviews": [ @@ -409076,6 +409103,26 @@ "updatedAt": "2020-07-31T00:37:35Z" } ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU5NDE2MTY5", + "commit": { + "abbreviatedOid": "1a09b63" + }, + "author": "janaiyengar", + "authorAssociation": "CONTRIBUTOR", + "state": "COMMENTED", + "body": "", + "createdAt": "2020-07-31T19:33:01Z", + "updatedAt": "2020-07-31T19:33:02Z", + "comments": [ + { + "originalPosition": 29, + "body": "Yes, this is a change in how the sender works, but it's not a significant difference. And it is in the pseudo code in the appendix, not in the text. \r\n\r\nLet's be clear that we are defining something that we are calling Reno for QUIC, knowing fully well that it's just one of many controllers that people will attempt. The current pseudo code is not a reference, it is one way of doing Reno. What this PR proposes is what a number of implementations already do.\r\n\r\nI don't think there's much more to see here. I'm fine with not including the PR, or with including the PR. Most implementations are likely to implement it the way the PR does, but the current pseudo code is also good in that it is algorithmically clear.\r\n", + "createdAt": "2020-07-31T19:33:02Z", + "updatedAt": "2020-07-31T19:33:02Z" + } + ] } ] }, @@ -411623,7 +411670,7 @@ ], "body": "", "createdAt": "2020-07-23T08:07:52Z", - "updatedAt": "2020-07-30T20:36:52Z", + "updatedAt": "2020-07-31T05:40:13Z", "baseRepository": "quicwg/base-drafts", "baseRefName": "master", "baseRefOid": "8919206b422be7b3073d993086b4092d82328876", @@ -411690,6 +411737,13 @@ "body": "Thanks, @mt! The diff still looks quite terrible. Where did you push to?", "createdAt": "2020-07-30T20:36:51Z", "updatedAt": "2020-07-30T20:36:51Z" + }, + { + "author": "martinthomson", + "authorAssociation": "MEMBER", + "body": "I fixed the branch, merged to master, and pushed directly. It's naughty, but I've found that sometimes you have to do this or you spend forever debugging git.", + "createdAt": "2020-07-31T05:40:12Z", + "updatedAt": "2020-07-31T05:40:12Z" } ], "reviews": [ @@ -413440,7 +413494,7 @@ ], "body": "", "createdAt": "2020-07-24T11:52:45Z", - "updatedAt": "2020-07-28T01:10:45Z", + "updatedAt": "2020-07-31T14:15:37Z", "baseRepository": "quicwg/base-drafts", "baseRefName": "master", "baseRefOid": "42aed511f0e3931533b35106b182c8f2dd885095", @@ -414709,7 +414763,7 @@ "id": "MDExOlB1bGxSZXF1ZXN0NDU4NTkyMjk3", "title": "Transport Parameters are not APLN Specific", "url": "https://github.com/quicwg/base-drafts/pull/3973", - "state": "OPEN", + "state": "MERGED", "author": "nibanks", "authorAssociation": "MEMBER", "assignees": [], @@ -414719,18 +414773,28 @@ ], "body": "Closes #3965.\r\n\r\nCall out that since transport parameters are not ALPN specific, when the client offers several, that application protocols should not put restrictions on them that might back them into a corner for future versions.", "createdAt": "2020-07-29T17:55:05Z", - "updatedAt": "2020-07-30T21:09:47Z", + "updatedAt": "2020-07-31T19:35:01Z", "baseRepository": "quicwg/base-drafts", "baseRefName": "master", "baseRefOid": "ca51fd116c60868e392720170768807380119032", "headRepository": "nibanks/base-drafts", "headRefName": "pr/tp-not-alpn-specific", - "headRefOid": "95c5919d77740e9761de84a0daf7e3d46feb24bf", - "closedAt": null, - "mergedAt": null, - "mergedBy": null, - "mergeCommit": null, - "comments": [], + "headRefOid": "967fcd53056273cdf59b2aa5c06c05caa0787417", + "closedAt": "2020-07-31T19:34:55Z", + "mergedAt": "2020-07-31T19:34:55Z", + "mergedBy": "janaiyengar", + "mergeCommit": { + "oid": "c8e6cf3d37742ecede14c3d22e645574e78a7196" + }, + "comments": [ + { + "author": "janaiyengar", + "authorAssociation": "CONTRIBUTOR", + "body": "@martinthomson should take a look.", + "createdAt": "2020-07-31T01:40:51Z", + "updatedAt": "2020-07-31T01:40:51Z" + } + ], "reviews": [ { "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU3OTI4MzQ1", @@ -414748,7 +414812,7 @@ "originalPosition": 9, "body": "Regarding the last sentence, how about saying something like: _Application protocols SHOULD NOT introduce prohibitive requirements that prevent other application protocols from working._\r\n\r\nI am not sure if this problem can be scoped to different versions of one protocol. While that could be the case for HTTP, there could be cases where a client might ask for using different protocols that provide the same service. To give an example, a client might send send an ALPN of (\"h3\" (for doing DNS over HTTP), \"dns\" (for doing DNS over QUIC)) to a DNS server.", "createdAt": "2020-07-29T21:59:47Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] }, @@ -414768,7 +414832,7 @@ "originalPosition": 9, "body": "@kazuho I'm not sure how you'd go about not making _prohibitive requirements_ for other protocols without understanding the set of all other possible protocols **or** by setting no requirements at all.", "createdAt": "2020-07-29T22:06:11Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] }, @@ -414788,7 +414852,7 @@ "originalPosition": 9, "body": "@nibanks If that's unclear, saying something like the following might be better: \"should not introduce restrictions to the transport parameters, as doing so might prevent clients from offering multiple application protocols.\"\r\n\r\nI think that addresses the two examples that you laid out in the original comment of #3965.", "createdAt": "2020-07-29T23:15:04Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] }, @@ -414808,7 +414872,7 @@ "originalPosition": 9, "body": "There is a difference between requirements and recommendations. We do recommend in HTTP/3 that a certain number of unidirectional stream be available, but it is [just a recommendation](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-6.2-4).\r\n\r\nI think that this could be clearer then:\r\n\r\n> Protocol negotiation with Application Layer Protocol Negotiation (ALPN; see {{?ALPN=RFC7301}}) allows clients to offer multiple application protocols with connection attempts. The single set of transport parameters offered by a client apply to all application protocols that the client offers. Application protocols can make recommendations about the values for transport parameters, such as suggesting minimum values for stream or flow control limits. Application protocols that place hard constraints on transport parameters could make it impossible for clients to attempt a connection that includes other application protocols with different constraints.", "createdAt": "2020-07-30T02:19:42Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] }, @@ -414828,7 +414892,7 @@ "originalPosition": 9, "body": "I'd like to make some editorial suggestions to martin's proposal, but I like that text.", "createdAt": "2020-07-30T12:24:03Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] }, @@ -414848,9 +414912,160 @@ "originalPosition": 12, "body": "```suggestion\r\nApplication Layer Protocol Negotiation (ALPN; see {{?ALPN=RFC7301}}) allows\r\nclients to offer multiple application protocols during connection\r\nestablishment. The transport parameters that a client includes during the\r\nhandshake apply to all application protocols that the client offers. Application\r\nprotocols can recommend values for transport parameters, such as the initial\r\nflow control limits. However, application protocols that require values for\r\ntransport parameters will make it impossible for a client to offer multiple\r\napplication protocols with conflicting requirements.\r\n```", "createdAt": "2020-07-30T20:58:13Z", - "updatedAt": "2020-07-30T21:09:47Z" + "updatedAt": "2020-07-31T14:19:40Z" } ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4ODY3NTc3", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "janaiyengar", + "authorAssociation": "CONTRIBUTOR", + "state": "APPROVED", + "body": "Thanks for patiently working through, Nick!", + "createdAt": "2020-07-31T01:39:51Z", + "updatedAt": "2020-07-31T01:39:51Z", + "comments": [] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4ODY5ODY4", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "ianswett", + "authorAssociation": "CONTRIBUTOR", + "state": "APPROVED", + "body": "", + "createdAt": "2020-07-31T01:48:03Z", + "updatedAt": "2020-07-31T01:48:03Z", + "comments": [] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4OTI4MDk4", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "martinthomson", + "authorAssociation": "MEMBER", + "state": "APPROVED", + "body": "It is not certain that requirements on transport parameter values will cause problems.", + "createdAt": "2020-07-31T05:42:06Z", + "updatedAt": "2020-07-31T05:43:03Z", + "comments": [ + { + "originalPosition": 10, + "body": "```suggestion\r\ntransport parameters could make it impossible for a client to offer multiple\r\n```", + "createdAt": "2020-07-31T05:42:07Z", + "updatedAt": "2020-07-31T14:19:40Z" + }, + { + "originalPosition": 11, + "body": "```suggestion\r\napplication protocols if these requirements conflict.\r\n```", + "createdAt": "2020-07-31T05:42:32Z", + "updatedAt": "2020-07-31T14:19:40Z" + } + ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4OTM2NzQ5", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "kazuho", + "authorAssociation": "MEMBER", + "state": "COMMENTED", + "body": "LGTM modulo the point below.", + "createdAt": "2020-07-31T06:09:13Z", + "updatedAt": "2020-07-31T06:09:22Z", + "comments": [ + { + "originalPosition": 9, + "body": "```suggestion\r\nflow control limits. However, application protocols that require specific values for\r\n```\r\n\r\nI think we are talking about the requirement of values rather than if TP take values.", + "createdAt": "2020-07-31T06:09:13Z", + "updatedAt": "2020-07-31T14:19:40Z" + } + ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4OTQwMDgw", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "martinthomson", + "authorAssociation": "MEMBER", + "state": "COMMENTED", + "body": "", + "createdAt": "2020-07-31T06:18:41Z", + "updatedAt": "2020-07-31T06:18:41Z", + "comments": [ + { + "originalPosition": 9, + "body": "Or\r\n```suggestion\r\nflow control limits. However, application protocols that constrain values for\r\n```", + "createdAt": "2020-07-31T06:18:41Z", + "updatedAt": "2020-07-31T14:19:40Z" + } + ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU4OTQwMjQx", + "commit": { + "abbreviatedOid": "95c5919" + }, + "author": "martinthomson", + "authorAssociation": "MEMBER", + "state": "COMMENTED", + "body": "", + "createdAt": "2020-07-31T06:19:11Z", + "updatedAt": "2020-07-31T06:19:12Z", + "comments": [ + { + "originalPosition": 9, + "body": "Or\r\n\r\n```suggestion\r\nflow control limits. However, application protocols that set constraints on values for\r\n```", + "createdAt": "2020-07-31T06:19:11Z", + "updatedAt": "2020-07-31T14:19:40Z" + } + ] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU5MjEzMzA0", + "commit": { + "abbreviatedOid": "967fcd5" + }, + "author": "kazuho", + "authorAssociation": "MEMBER", + "state": "APPROVED", + "body": "", + "createdAt": "2020-07-31T14:22:17Z", + "updatedAt": "2020-07-31T14:22:17Z", + "comments": [] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU5MjM2Mzk4", + "commit": { + "abbreviatedOid": "967fcd5" + }, + "author": "DavidSchinazi", + "authorAssociation": "CONTRIBUTOR", + "state": "APPROVED", + "body": "", + "createdAt": "2020-07-31T14:51:26Z", + "updatedAt": "2020-07-31T14:51:26Z", + "comments": [] + }, + { + "id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDU5NDE2Nzg1", + "commit": { + "abbreviatedOid": "967fcd5" + }, + "author": "janaiyengar", + "authorAssociation": "CONTRIBUTOR", + "state": "APPROVED", + "body": "", + "createdAt": "2020-07-31T19:34:15Z", + "updatedAt": "2020-07-31T19:34:15Z", + "comments": [] } ] },