Subject: QUIC Issues discussed in Tokyo - confirming consensus

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Feb 2019 15:21:19 +1100

We discussed a *large* number of issues in the Tokyo interim. Congratulations to everyone. To refresh people's minds:

* The project boards we drove discussion from:  https://github.com/quicwg/base-drafts/projects
* The draft minutes:  https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md
* Individual issues:  https://github.com/quicwg/base-drafts/issues/{issue_number}

Please have a look through the issues listed below and respond if you agree with their disposition, as noted below each group.

* The following issues need more discussion (on-list or in-repo):

- 2344: Frames that are allowed in 0-RTT packets
- 2223: When can you coalesce connections
- 253: HTTP/QUIC without Alt-Svc?

* The following issues are pending proposals (usually, PRs, or progress on an already-existing PR) -- along with the responsible party or parties:

- 2308: handling of coalesced packets with decryption errors creates DoS opportunity - marten
- 2214: simultaneous key update can lead to deadlock - mt, marten, ekr, victor, kazuho
- 1834: Flow control for post-handshake CRYPTO messages - mt
- 2170: Embed QUIC version in expansion - mt and EKR
- 1773: Build a version negotiation mechanism that mostly doesn't add round trips - editors, based upon #2133
- 2145: Don't change CID on peer CID change - mt
- 2084: Discuss requirement that connection IDs not be correlatable - editors
- 2143: Be more conservative about migration? - editors
- 1994: endpoints don't know how many connection IDs the peer is willing to store - marten
- 2342: Spoofed connection migration as a DoS vector - editors
- 2360: 0-RTT flow control limits can't be increased - editors
- 2267: loss of only two packets can lead to an unrecoverable situation - editors
- 2309: Migration before handshake completed is very messy - christian
- 2275: Varint h3 unidirectional stream types - editors
- 2253: Consider making h3 frame types varint - editors
- 2233: Why are setting identifiers not varints? - editors
- 2228: How do I generate an RST? - editors
- 2258: Initial maximum table size needs clarification - editors
- 2100: Avoid creating QPACK codec streams when unnecessary - editors
- 2371: Assign QPACK error codes? - editors

* The following issues already have text incorporated into the editors' drafts:

- 2101: Should retiring all CIDs be an error?
- 1990: encoding of CONNECTION_CLOSE reason phrases
- 2347: nothing can be sent when receiving a packet just after the idle close timer expires
- 2118: Allow PMTU probing of a path suspected of not supporting PMTU of 1280
- 2395: HTTP/3 uses LTV unlike TLS or QUIC transport 
- 2276: Disallow changes of table size after 0-RTT
- 2363: The initial table capacity is zero
- 2112: Largest Reference algorithm can produce invalid values
- 1951: Disconnect with Initial Injection
- 2397: "Invariant check" for any inbound LH packet - editors
- 2348: Specify IPv6 flow label for QUIC - christian

^^ If you disagree with these resolutions, please say so on the mailing list or in the issue before 2019-02-22; after that, they will be marked as `has-consensus`. If your feedback is editorial, please say so explicitly, so we don't block on it.

* The following issues were felt to be able to be closed with no (or just editorial) action for quicv1/h3:

- 2329: Actions to take when Reserved Bits are not Zero
- 1874: Formal analysis of the protocol
- 1810: Timing issues in version downgrade attack prevention - overcome by events
- 1795: Define a safe algorithm for changing CID in response to a change in CID - dup of #2145
- 2159: Why are we bothering to number CIDs?
- 2026: Can Initial/0-RTT CIDs safely be used for routing?
- 2372: PATH_* frames should not be ACK-eliciting
- 203: Connection migration should be indistinguishable from a new connection
- 2319: Error code for acknowledgment of a packet that was never sent
- 1989: frame type field of CONNECTION_CLOSE provides little value
- 2151: Where can you send CONNECTION_CLOSE
- 1638: Dead path timeout
- 1243: ICMP and ICMPv6 PMTUD with asymmetric connection-ids
- 279: Public Troubleshooting Flags
- 632: On-path calculation of loss and congestion
- 602: End-to-Path Close Signal
- 2299: consider making the varint encoding unique
- 2049: minimum payload size requirement creates awkward special case
- 219: Increasing initial flow control window for streams
- 969: ACK Frames should be in Increasing Packet Number Order
- 1482: Extension poster-child
- 1993: Introduce a bit to indicate the server doesn't do IP-based authentication
- 279: Public Troubleshooting Flags
- 655: 1-RTT stateless rejects
- 718: Retain use of SETTINGS_ENABLE_PUSH
- 2232: Should receipt of multiple promises really be an error?
- 2291: Allow extra data after self-terminating h3 frames
- 2229: Can I send non-data frames on CONNECT streams?
- 2224: Why do control streams need to be typed?
- 2396: HTTP/3 frame encodings are unnecessarily difficult to serialize and parse
- 2230: When can PUSH_PROMISE frames be sent?
- 1885: DATA frame encoding is inefficient for long dynamically generated bodies
- 371: ALTSVC Frame
- 2384: What scheme should be used for HTTP/3?
- 2226: Why do I have to explicitly cancel after GOAWAY
- 1420: encoder stream can deadlock

^^ If you disagree with these resolutions, please say so on the mailing list or in the issue before 2019-02-22; after that, the non-editorial issues will be marked as `has-consensus`, and the editorial issues will be presumed to be indeed editorial. If your feedback is editorial or otherwise non-critical, please say so explicitly, so we don't block on it.

Cheers,

--
Mark and Lars, WG Chairs

--
Mark Nottingham   https://www.mnot.net/