Re: Heads up -- unifying of multipath options.

[Christian Huitema <[e-mail]>]

On 6/15/2022 12:07 PM, Michael Eriksson wrote:

> In my response to Christian Huitema, I suggest a design that fully supports client-side zero-length connection IDs but only uses multiple PN spaces. In addition to (noticeably) reduced complexity, it has these advantages:
>
>    1.  Support for full use of ECN also for paths with zero-length connection IDs
>    2.  Enabling (or at least simplifying) hardware offload when using zero-length connection IDs


This discussion makes me wonder whether we have consensus for a unified 
multipath option. The authors believe that we do, but Michael clearly 
does not believe it. If we go back to the drawing board, then another 
unified option is possible, centered on the "single space" option. It 
would require adding a "path report" frame to convey congestion control 
information for the path, something like:

PATH_REPORT {
     path_identifier,
     time stamp(i),
     last received time stamp on path(i),
     delay since last time stamp(i),
     ECN Counts (..)
}

This would give us lots of benefits compared to the current solutions:

* easier hardware offload, as there is only on number space and one 
encryption context,
* keep using 64 bit nonce, removing the need for multipath-specific 96 
bits nonce and new APIs,
* solve the "rtt per path" measurement issue,
* solve the "ECN per path" measurement issue,
* full support of zero-length CID,
* remove the interaction between CID and number space, no need to start 
a new number space on NAT rebinding or CID renewal,
* common code for unipath and multipath,
* and of course, single multipath option.

Maybe we should investigate that.

-- Christian Huitema