Bill, your solution looks very similar to the "simple multipath"
proposal:
https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/. That
proposal was incorporated as an option in the early drafts that resulted
in the current proposal, see for example
https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/00/.
Much like stated in your draft, the simple multipath proposal allowed
simultaneous use of multiple paths per connection, without requiring
changes in encryption, connection ID, etc.
After much debate, the working group looked at the pros and cons of the
two approaches. The main argument against the simple proposal was the
efficiency of loss recovery. My implementation came close to the
performance of the "multiple name space" version, within 1% for most key
scenarios, but while this did not require changes in the protocol, it
did requires quite a bit of additional complexity in the handling of
loss recovery and acknowledgements, and there still were holes. For
example, in the absence of per path acknowledgement, we cannot get
precise estimates of per path timers. We also cannot get good estimates
of per path ECN. Solving that would require adding new per-path control
frames. Doable, but then we are quickly drifting apart from the idea of
simple multipath with changing the RFC 9000 implementation.
The picoquic code still supports the simple multipath option. You can
use it to experiment if you want. And I will be happy to give you details...
-- Christian Huitema
On 11/11/2023 3:01 PM, Bill Gage wrote:
This document is in response to discussions of issue 214 in the QUIC
multipath GitHub: https://github.com/quicwg/multipath/issues/214
The current MPQUIC draft (-06) binds a connection identifier to a path
by using the sequence number of a connection identifier as an implicit
path identifier. To simplify implementation, the current MPQUIC draft
introduces the concept of multiple application data packet number spaces
with a different number space for each connection (path). This is in
contrast to RFC9000 where there is a single application data packet
number space.
Issue 214 proposed separating path IDs from connection IDs. This
document uses that separation of identifiers to propose a different path
model for Multipath QUIC using explicit path identifiers, enabling a
multipath management framework that retains the principles and
operations of RFC9000.
The multipath operations described in this document do not change the
basic operations described in RFC9000. In particular, none of the
following procedures described in RFC9000 are affected by the use of
multiple paths:
+ connection management (e.g. the use of NEW_CONNECTION_ID frames and
subsequent rotation of connection identifiers);
+ key management (e.g. use of key phase bit) and derivation of AEAD
parameters;
+ packet loss detection and loss recovery (e.g. using type 0x02 ACK
frames without ECN counts).
However, changes to RFC9002 procedures are required to deal with
path-dependent characteristics such as path MTU size, RTT and congestion.
Cheers ...
/bill
On 2023-11-11 5:49 p.m., [email protected] wrote:
> A new version of Internet-Draft draft-gage-quicmp-pathmodel-00.txt
has been
> successfully submitted by Bill Gage and posted to the
> IETF repository.
>
> Name: draft-gage-quicmp-pathmodel
> Revision: 00
> Title: An Alternate Path Model for Multipath QUIC
> Date: 2023-11-11
> Group: Individual Submission
> Pages: 14
> URL: https://www.ietf.org/archive/id/draft-gage-quicmp-pathmodel-00.txt
> Status: https://datatracker.ietf.org/doc/draft-gage-quicmp-pathmodel/
> HTML:
https://www.ietf.org/archive/id/draft-gage-quicmp-pathmodel-00.html
> HTMLized:
https://datatracker.ietf.org/doc/html/draft-gage-quicmp-pathmodel
>
>
> Abstract:
>
> The path model used in the current MPQUIC draft binds a connection
> identifier to a path. In fact, the sequence number of a connection
> identifier is used as an implicit path identifier. This has a
number
> of consequences that may cause MPQUIC to diverge from the principles
> of RFC9000. One of these consequences, for example, is to associate
> each connection with a different application data packet number
space
> rather than maintaining a single application data packet number
space
> across all connections as defined in RFC9000.
>
> This document proposes a different path model for Multipath QUIC
> using explicit path identifiers, enabling a multipath management
> framework that retains the principles and operations of RFC9000.
>
>
>
> The IETF Secretariat
>
>
