Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK

[Jaikiran Pai]

Hello Geliang,

Just a few initial observations:

On 23/09/25 3:04 pm, Geliang Tang wrote:
> Dear OpenJDK Maintainers,
>
> We are writing to propose the integration of Multipath TCP (MPTCP)
> support into OpenJDK. In response to Alan's feedback in earlier
> discussions [1], we have developed a Java-based implementation that
> utilizes the setOption method to enable MPTCP before binding or
> connecting a socket, as illustrated below:
>
>    Socket c = new Socket();
>    c.setOption(ExtendedSocketOptions.TCP_MPTCPIFY, true);
>    c.connect(new InetSocketAddress(loop.getHostAddress(), port));
>
> The name 'TCP_MPTCPIFY' was chosen to align with 'mptcpize' tool in
> mptcpd and 'mptcpify' in BCC. The complete implementation can be found
> in [2].
I realize it's still a bit early to discuss naming of this option, but 
if we do go ahead with this approach of introducing an 
ExtendedSocketOption, then maybe calling it TCP_MULTIPATH might be more 
suitable.
> This email outlines the technical background and aims to facilitate
> further discussion on the proposed approach.

Looking at the linked github diff in your mail, the biggest difference 
between existing (Extended)SocketOptions and this new proposed one is 
that, as far as I can tell, this new one isn't a socket option and 
instead is a protocol value that is used when constructing the socket():

 > fdm = socket(domain, type, IPPROTO_MPTCP);

I don't yet know if fitting this into the existing ExtendedSocketOptions 
may end up being tricky for long term maintenance of this (internal) 
API. The other question this raises is, are applications allowed to call 
Socket.getOption(...) for this option and then expect it to return 
true/false depending on whether multicast TCP was set for that socket? I 
briefly glanced at the proposed diff and I couldn't spot any changes in 
the ExtendedSocketOptions.getOption(...) code to deal with this option. 
But that too I think is a trivial thing for later.

The bigger question, I think, is whether constructing a "socket()" with 
a specific "protocol" value in this manner by trying to adjust the 
implementation in the code which deals with socket options is the right 
thing to do. I realize that this proposal of prototyping it as a socket 
option was suggested in response to your first email, so I am not saying 
this direction should be abandoned, I just haven't fully grasped if this 
can cause us problems with this approach.

I have several other questions, both implementation details as well as 
the basics of multipath TCP, but I haven't yet read up on all the 
material that's been linked in your email. So I'll catch up on that first.

-Jaikiran