Re: [quicwg/multipath] separate Path IDs from Connection IDs (Issue #214)

[Bill Gage <[e-mail]>]

Thank you for the pointer to your earlier work - there are indeed many 
similarities.

As you noted, one of the biggest problems in these proposals is loss 
detection and recovery, particularly the determination of a viable PTO 
interval due to the different RTT observed on different paths. [see 
sidebar below]

As you also noted, these problems are solvable but require the use of 
more sophisticated algorithms that make the implementation more complex.

It appears that the current -06 draft is the result of  trying to 
simplify the implementation but at the expense of diverging from RFC9000 
in some pretty fundamental ways. I'm not sure that is the right direction.

I would advocate for an approach that preserves RFC9000 procedures (such 
as those listed below), provides extensions for managing the use of 
paths, and provides a toolkit, through extensions if necessary, that 
implementations may use to deal with the different characteristics of 
different paths. The toolkit may, for example, incorporate path delay 
measurements into the multipath protocol using extension frames, similar 
to https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag/. It 
looks like your previous implementation experiences could contribute 
greatly to that toolkit.

Perhaps the drifting away from RFC9000 that you indicated below was the 
result of trying to reuse QUIC connections as the basis for multipath 
operations rather than addressing  path management separately from 
connection  management?

Cheers...

=========
[As a sidebar I will note that the examples you give in your "simple 
multipath" draft, which are echoed in the current -06 draft, cite the 
use of geosynchronous satellites with 1-way propagation delays on the 
order of 100 msec. Non-terrestrial networks are moving towards the use 
of LEO constellations and high altitude platforms where the 1-way 
propagation delays are on the order of 1 msec and 0.1 msec respectively. 
This, of course, does not include delays resulting from forwarding 
to/from ground stations and over inter-satellite links.]

[I will also note that the use of multipath for increased throughout is 
becoming less of an issue with each successive generation of wireless 
standards. Other use cases for multipath - both wired and wireless - may 
eventually dominate.]

/bill


On 2023-11-11 9:02 p.m., Christian Huitema wrote:
> 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., [e-mail] 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
>>  >
>>  >
>>