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
