QUIC multi-stream

xep-0467.xml

@@ -49,12 +49,28 @@
       <li>Client or server MUST set the ALPN (&rfc7301;) TLS extension, and MUST use &tls-ech; if available.</li>
       <li>The ALPN protocol MUST be '<strong>xmpp-client</strong>' when negotiating an c2s connection.</li>
       <li>The ALPN protocol MUST be '<strong>xmpp-server</strong>' when negotiating an s2s connection.</li>
-      <li>The client or server MUST use <link url='https://datatracker.ietf.org/doc/html/rfc9000#section-9'>QUIC Connection Migration</link> which allows for a single QUIC session and therefore multiple XMPP connections to migrate between IPs without reconnecting. Use of &xep0198; is therefore optional but encouraged if reconnection might occur over another transport like TLS or WebSocket.</li>
-      <li>QUIC supports uni-directional and bi-directional streams, but XMPP MUST only use bi-directional streams. Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake.  This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.</li>
+      <li>The client or server MUST use <link url='https://datatracker.ietf.org/doc/html/rfc9000#section-9'>QUIC Connection Migration</link> which allows for a single QUIC session and therefore multiple XMPP connections to migrate between IPs without reconnecting. The timeout SHOULD be set to the maximum 600 seconds.</li>
+      <li>QUIC supports uni-directional and bi-directional streams, but XMPP MUST only use bi-directional streams. Multiple bi-directional MAY be opened in one session after authentication (for S2S) or resource binding (C2S), and MUST be treated with the same security and authentication as negotiated in the initial XMLStream.</li>
     </ol>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
-  <p>Perhaps the most compelling benefit of QUIC over TCP+TLS is connection migration especially for mobile devices which swap between mobile and WiFi often.  Multiple connections per QUIC session is also helpful for clients with multiple accounts or servers with multiple streams to each other.  The handshake and especially 0-rtt mode will be faster than STARTTLS, and in theory, QUIC in general should be faster than TLS, though perhaps not enough to matter for XMPP.</p>
+  <section2 topic="Connection Migration">
+    <p>The entire QUIC connection can be migrated to a different source IP address. This allows mobile devices to seamlessly switch between mobile data and WiFi, without renegotiation. This takes the place of the session resumption in &xep0198;, which MUST NOT be used.</p>
+  </section2>
+  <section2 topic="Multiple Streams">
+    <p>QUIC allows the use of multiple streams. A QUIC connection still maps to a single XMLStream, and the initial bidirection stream (id=0) SHALL be used to setup and make ready this XMLStream. Until the XMLStream is ready for general stanza exchange, further bidirectional QUIC streams MUST NOT be opened. For S2S XMLStreams, this will be after SASL authentication, whereas for C2S XMLStreams this will be after resource binding. It is advised to support &xep0388; and &xep0387; to streamline these, though there is no interoperability issue if the older forms are used.</p>
+    <p>Once multiple streams are opened, it is MANDATORY that both peers continue to follow the ordering rules defined in Section 10.1 of &rfc6120;, however stanzas sent in different QUIC streams have no fixed order relative to those sent in other QUIC streams. The sending peer MUST therefore use a single QUIC stream for all stanzas sent between a pair of two bare jids. For example, when sending a stanza from sender@example.net/resource to receiver@example.com, and another from sender@example.net/other to receiver@sender.com/xyzzy, both stanzas MUST be sent within the same QUIC stream. Multiple "pairs" of Jids MAY share the same QUIC stream, with the degenerate case - all pairs sharing the same QUIC stream - being the case where no additional QUIC streams are opened. This mapping of bare jid pairs to QUIC streams MUST NOT be enforced by the receiver; the receiver MUST simply process all stanzas received over a QUIC stream in the order they were sent in the same way they would if a single QUIC stream (or TCP) were used.</p>
+    <p>In the C2S case, all stanzas sent to the user's own bare jid and also to the server's jid itself MUST be sent on the same QUIC stream, and this SHOULD be the initial stream (id=0).</p>
+    <p>Top Level Elements other than Stanzas, such as CSI, stream errors, etc, MUST be sent on the initial stream (id=0) only.</p>
+    <p>There is no "stream open" or "stream close" sent on streams other than the initial stream (id=0).</p>
+    <p>There is no requirement that the peer use the same QUIC streams for the same bare jid pairs, though again in C2S the initial stream (id=0) SHOULD be used for all stanzas sent from the user's own bare jid and also from the server's jid itself. In the general case, though, this means that (for example) an &lt;iq type='result'/> MAY come back on a different QUIC stream than the &lt;iq type='get'/> that elicited it.</p>
+    <p>Conceptually, there remains a single XMLStream for an entire QUIC connection, and the XMLStream state therefore applies to all QUIC streams within the QUIC connection. Stanzas received on a QUIC stream are processed by taking each complete stanza and injecting it into the XMLStream at that point. An incomplete stanza received on any QUIC stream (including the initial stream) is buffered until such time as the data arrives to complete it.</p>
+    <p>The benefits of doing this are that individual streams do not block each other on low bandwidth or packet loss. Eliminating this blocking effect, called Head Of Line Blocking, means that higher-volume chatrooms (for example) do not slow down the transmission of perhaps more urgent low volume messages. Because of this effect, peers MAY use QUIC's ability to proritise specific QUIC streams for finer control, though this is out of scope for this document.</p>
+  </section2>
+  <section2 topic="Stream Management">
+    <p>Because of multiple streams, the state of the XMLStream cannot be captured with a simple counter. This means that &xep0198; cannot apply to QUIC connections, and &xep0198; MUST NOT be advertised or negotiated. Luckily, QUIC provides its own mechanism equivalent to resumption. For stanza-level acknowledgements, however, there is no equivalent immediately available.</p>
+    <p>Open Question: What do we do instead? A lighter &lt;a xmlns='urn:xmpp:quic:0'/> perhaps? Or do we build something more heavyweight which just handles stanza acknowledgements, but includes MAM ids etc?</p>
+  </section2>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
     <p>QUIC provides AT LEAST the same level of security as STARTTLS and Direct TLS, and far more privacy with &tls-ech; (which can and should be used with Direct TLS, but this isn't a MUST). QUIC provides more security than STARTTLS if &rfc7590; is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the QUIC, STARTTLS and Direct TLS logic as well.</p>