
Upstreaming multipath TCP - pabs3
https://lwn.net/SubscriberLink/800501/c42e5c5e9243637b/
======
Animats
We had that in the early days of TCP. Then Berkeley broke it.

Originally, an IP address identified a destination host, not an interface
card. Didn't matter over what device a packet arrived. The BSD people, though,
tied IP addresses to the network interface, so it mattered over which device a
packet arrived. This simplified outbound routing in BSD, but broke multipath
TCP.

~~~
rocqua
There are good reasons for layer 3 addresses to be network interface specific.
In fact, that is how layer 3 is supposed to work. After all, each interface is
potentially connected to acdifferent network. Hence, routing to those
interfaces is different, and layer 3 is about routing.

The mistake instead is that TCP is not fully layer 4. They are entangled with
layer 3. Specifically, a TCP socket is defined by an (IP, port) pair. Where
the IP is layer 3. As such, it is fundamentally impossible to persist a TCP
connection accross multiple IPs.

There is no reason for this. If instead a socket were identified as (uuid,
port) then after I change my ip address, I can continue receiving packets sent
to (uuid, port). And the other side will still recognize packets from me,
because only my IP changed, not the connection uuid.

You'd maybe need to add some spoofing defenses, but we need those in current
TCP too.

~~~
paulsutter
You might want to be careful lecturing John Nagle on TCP ;)

(intended in the most lighthearted way possible!)

~~~
alxlaz
Watching people try to teach John Nagle how to do networking is half the
reason why I like reading the HN forums :-).

I'm not one to defer to authority too easily, but it's my experience that,
when someone with enough experience says something that sounds out of this
world, it's a good idea to think about it for a bit.

~~~
Animats
There are arguments for unique IP addresses for interfaces. I'm just amused at
the addition of yet another layer of address indirection.

~~~
alxlaz
Certainly, I'm convinced that neither you, nor the fine folks at BSD were/are
clueless about these things. I think it's important to know why these
decisions were made, and what trade-offs were involved, so that I don't get
dogmatic about them.

------
dooglius
A shame this has to be done within the kernel. There was never much reason to
implement TCP handling in ring zero.

~~~
mehrdadn
I've never seen anyone explain how keep-alive is supposed to work in user-
mode, and this worries me in HTTP/3\. If your program blocks on something in
user-mode, should the connection really die? Doing it in the kernel avoids
that. e.g. I know I want to be able to stop my program and continue it in a
debugger without breaking network connections and I would be surprised if
other people didn't care for this.

~~~
dooglius
A separate thread? I assume that's all the kernel would be doing anyway, no
ring zero magic involved.

~~~
mehrdadn
A debugger stops every thread though?

~~~
dooglius
Fair point, I was more addressing the blocking-call concern. There are a
number of ways you could get your debugger of choice to not halt a particular
thread (this would admittedly require some extra work), but won't a typical
browser have an application-level timeout that you'd hit anyway.

~~~
mehrdadn
Browser? I'm not talking about browsers, I'm talking about every other kind of
application that tries to use a userland protocol, because that seems to be
the direction network libraries are aiming to go. I have no idea how to tell
most (all?) debuggers not to halt particular threads, but it sounds painful.
And my point is, there are consequences like this that no one seems to care
about at all, but that I would hope would've been addressed before seeing
people jump on the ship.

------
beagle3
DJB's CurveCP / MinimalT framework is probably a much better solution to the
problems MPTCP is trying to solve - and also adds security, increases address
space as well. But .. MPTCP it is; at least something is gaining wide use.

------
est
> Baerts said, so there will be no user-space access to subflows for now.

So one has to tcpdump to observe the sub flows?

> But, naturally, there are users who want their unmodified binary programs to
> start using MPTCP once it's available. There is a working, if inelegant,
> solution to this problem. A new control-group hook allows the installation
> of a BPF program that runs when a program calls socket(); it can change the
> requested protocol to IPPROTO_MPTCP and the calling application will be none
> the wiser.

Uhhhhh!

------
ksec
Does anyone know the state of MPTCP on iOS? I heard they were testing it long
ago on iOS. And then we haven't heard anything about it.

~~~
flounder3
We implemented it for Siri in iOS 7. Exposed APIs for third party developers
in iOS 11.

