On Tue, 14 Jun 2022 14:16:49 -0700, Christian Huitema wrote:
> On 6/13/2022 6:33 AM, Michael Eriksson wrote:
> > [...]
> >
> > What you suggest is to use both single and multiple PN spaces,
> > which I think is a mistake. The main reason is the increased
> > complexity and double implementation.
>
> The proposal does not suggest to use both single and multiple number
> spaces "in general". It actually suggests that multiple number
> spaces is the default. The proposal makes an exception for the
> zero-length identifier case, because we actually got feedback about
> the importance of that scenario from several implementations, and
> also because these implementations expressed their preference for
> using a single number space in that case.
Yes, so a fully functional multipath stack would of course need to
handle zero-length connection IDs. With your design, that implies
handling both single and multiple PN spaces which I argue is quite
complex (PR #103 is full of special case handling when using
zero-length connection IDs). I want to stress that I showed a design
where multiple PN spaces is enough to also support zero-length
connection IDs.
While I appreciate the experience and knowledge collected from
existing implementations, I don't think that we should limit the
design options to what has already been done in these implementations.
> The proposal carefully outlines options for "pure multipath"
> implementations that don't want to handle the extra complexity:
>
> * on the receiving data part, the implementations can avoid the
> complexity by simply using non-zero-length CID. This is entirely
> under the implementation control.
>
> * on the sending data part, the implementations can avoid the
> complexity by either not negotiating multipath if the peer uses
> zero-length CID, or falling back to a degraded mode in which the
> implementation uses just one path at a time.
>
> I do believe this is the right compromise between the competing
> suggestions of multiple implementations.
How would you handle a connection that is set up with an explicit
(non-zero-length) connection ID, but where a path with zero-length
connection ID is added later? Or would that be forbidden (which would
be an artificial limitation)?
> > Zero-length connection identifiers
> > The stated need for a single PN space is to support zero-length
> > connection identifiers (CIDs). I think that multiple PN spaces can
> > be used also for zero-length CIDs if the IP address and port
> > number ("socket" in practice) is used for demultiplexing on the
> > receiver side.
> >
> > Zero-length CIDs are very seldom, if ever, used on the server
> > side. The client will normally use separate local network
> > interfaces (e.g., cellular and Wi-Fi) for the different paths, and
> > thus have separate sockets for the different paths anyway. The
> > server can handle a NAT rebinding, since the different paths are
> > separated by the connection ID and the event is handled as in RFC
> > 9000 (i.e., path validation).
>
> The "multiple sockets" assumption is not true. Many implementations
> use a single UDP socket, and use parameters of `sendmsg` to specify
> the outgoing interface and the outgoing source address.
Aha, in that case the multipath application would have to use
recvmsg() or recvfrom() to see on which path packets arrive.
> [...]
>
> Identifying path by IP and port numbers is rather fragile,
> especially in the presence of NAT and load balancers.
Well, identifying *connections* with zero-length connection ID by IP
address and port number seems to work fine also "in the presence of
NAT and load balancers", why wouldn't it work for paths?
> > [...]
> >
> > Summary
> >
> > I suggest that only multiple PN spaces are used for multipath
> > QUIC. I have shown how zero-length CIDs can be used on the client
> > side and argue that they will not be used on servers anyway.
>
> Well, we disagree.
Yes, we do and that's fine. We're having a technical discussion to
create the best possible protocol for multipath QUIC.
/me
