If we're starting the discussion on Multipath, it's likely that starting new email threads would be a good idea.
Beyond that ... On Wed, Sep 30, 2020 at 5:28 AM Olivier Bonaventure < [email protected]> wrote: > The main benefit of putting multipath inside the transport is that the > application does not need to handle the problems that occur on any of > these paths. The transport has access to round-trip-times and loss > measurements and has all the information required to manage the > different paths efficiently. > >From the beginning of time, people who needed some, but not all, of TCP's transport capabilities were left using UDP, and figuring out the transport capabilities in their own applications, with greater or less great success. The quote I've heard so many times is that many UDP-based applications ended up adding so many TCP-like transport capabilities that they might just as well have used TCP. We've had to write BCPs about that - guidelines for UDP usage, with https://tools.ietf.org/html/rfc8085 replacing https://tools.ietf.org/html/rfc5405 ten years later being the most obvious example, but also circuit breakers, like https://datatracker.ietf.org/doc/rfc8083/ (a Proposed Standard) and https://datatracker.ietf.org/doc/rfc8084/. Meanwhile, we've had to try to solve the "some but not all of TCP" problem in transport ANYWAY - first with SCTP and DCCP, and now with QUIC. So, I was hoping that we could learn from that example, and do work on multipath within transport, so that the world would not be full of applications managing multiple paths with greater or less success. Do the right thing, of course. Best, Spencer
