{"action":"created","issue":{"url":"https://api.github.com/repos/quicwg/base-drafts/issues/1439","repository_url":"https://api.github.com/repos/quicwg/base-drafts","labels_url":"https://api.github.com/repos/quicwg/base-drafts/issues/1439/labels{/name}","comments_url":"https://api.github.com/repos/quicwg/base-drafts/issues/1439/comments","events_url":"https://api.github.com/repos/quicwg/base-drafts/issues/1439/events","html_url":"https://github.com/quicwg/base-drafts/issues/1439","id":331401895,"node_id":"MDU6SXNzdWUzMzE0MDE4OTU=","number":1439,"title":"Improve ACK_ECN frame encoding (e.g., use bit-vector)","user":{"login":"kazuho","id":41567,"node_id":"MDQ6VXNlcjQxNTY3","avatar_url":"https://avatars2.githubusercontent.com/u/41567?v=4","gravatar_id":"","url":"https://api.github.com/users/kazuho","html_url":"https://github.com/kazuho","followers_url":"https://api.github.com/users/kazuho/followers","following_url":"https://api.github.com/users/kazuho/following{/other_user}","gists_url":"https://api.github.com/users/kazuho/gists{/gist_id}","starred_url":"https://api.github.com/users/kazuho/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kazuho/subscriptions","organizations_url":"https://api.github.com/users/kazuho/orgs","repos_url":"https://api.github.com/users/kazuho/repos","events_url":"https://api.github.com/users/kazuho/events{/privacy}","received_events_url":"https://api.github.com/users/kazuho/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2018-06-12T01:08:31Z","updated_at":"2018-06-13T07:33:22Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The encoding of ACK_ECN frame (proposed in #1372) has following issues.\r\n\r\n* size of ACK_ECN frame becomes bigger as more and more packets are exchanged, since the counters represent the total number of packets being exchanged using the connection\r\n* requires the receiver of the ACK_ECN frames to detect duplicates to avoid duplicate packet injection attacks\r\n* does not have full protection against duplicate packet injection attacks, since detection on the receiver cannot be perfect\r\n\r\nAs discussed in Kista, these issues are not blockers for merging #1372, but we might want to consider adopting different encoding scheme to address them."},"comment":{"url":"https://api.github.com/repos/quicwg/base-drafts/issues/comments/396842800","html_url":"https://github.com/quicwg/base-drafts/issues/1439#issuecomment-396842800","issue_url":"https://api.github.com/repos/quicwg/base-drafts/issues/1439","id":396842800,"node_id":"MDEyOklzc3VlQ29tbWVudDM5Njg0MjgwMA==","user":{"login":"gloinul","id":11295323,"node_id":"MDQ6VXNlcjExMjk1MzIz","avatar_url":"https://avatars3.githubusercontent.com/u/11295323?v=4","gravatar_id":"","url":"https://api.github.com/users/gloinul","html_url":"https://github.com/gloinul","followers_url":"https://api.github.com/users/gloinul/followers","following_url":"https://api.github.com/users/gloinul/following{/other_user}","gists_url":"https://api.github.com/users/gloinul/gists{/gist_id}","starred_url":"https://api.github.com/users/gloinul/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gloinul/subscriptions","organizations_url":"https://api.github.com/users/gloinul/orgs","repos_url":"https://api.github.com/users/gloinul/repos","events_url":"https://api.github.com/users/gloinul/events{/privacy}","received_events_url":"https://api.github.com/users/gloinul/received_events","type":"User","site_admin":false},"created_at":"2018-06-13T07:33:22Z","updated_at":"2018-06-13T07:33:22Z","author_association":"CONTRIBUTOR","body":"@kazuho \r\n\r\n> The core idea here is to use that mechanism to determine if a PN with the CE bit set is acknowledged for the first time. Use of a bit-vector is one of the possible approaches.\r\n\r\nBut, that doesn't work unless you are able to ACK each duplication in separate ACKs, as well as having no redundancy in the ACKing. I think that will make QUIC work very poorly if any ACK packet loss is experienced. There need to be some redundancy to ensure that ACK loss, doesn't equal forward loss from the senders perspective. \r\n\r\n> I would suggest detecting bleaching on the receiver side. If the receiver notices bleaching, it can send an ACK frame instead. I'd assume that that could (or should) be done in the encoding proposed in #1372 as well.\r\n\r\nI don't see that working reliably during capability checking, especially not when we add ECN black hole mitigation into the mix. It is the sender that knows which of the packets that are marked during the capability check. If all packets are marked, then yes a trustworthy receiver could detect bleaching. But then we need a signal where the receiver tells the sender to stop mark.\r\n\r\nI think I see one advantage for something like the bit-vector reporting of CE marks. That is in cases where one doesn't use the normal ECN marking scheme, such as L4S. L4S marks at much higher frequency, thus more CE marks will be received. In this case immediate ACK on CE marks will result in a bit excessive ACK rates. So, from my perspective this would be a reason for a solution with more detailed CE information. However, I don't see your proposal working out when it comes to duplication handling nor the capability checks. \r\n\r\nMy strawman if one like to address providing more detailed information on which packets are CE marked, ensure robustness around recovery periods and ensure that sender side verifications work is the following:\r\n\r\n* Receiver side suppression of duplicates\r\n* An ACK format for ECN where \r\n  - ECT(0) and ECT(1) are counters. However, they are variable encoding only the least number of bits needed to detect roll over, i.e. receiver track ACKs of ACKs to determine how many bits this needs to be. \r\n  - ECN-CE marks as bit-vector. Only needing to go as far back as there are CE marks. i.e. bit-vector may be shorter than full PN space covered by ACK. Truncation can be considered.\r\n* ACKs are assumed to have redundancy, either all the way to latest ACK of ACKs or at least across the last couple of ACKs. \r\n* ACK loss handling for when there are wholes in ACK information received by the sender due to ACK loss and ECN-CE vector truncation. This is to handle continuous verification. ACK holes will trigger loss response also. \r\n\r\nI would note that these changes would be geared toward making ACKing possible to be delayed in general to as happen as seldom as only four times per RTT assuming having something to ACK in each interval. \r\n"}}
{"actor":{"display_login":"gloinul"}}