11–20 of 104 posts
That sounds .. quite restrictive. Is the only requirement on a middlebox to just forward the MPTCP options as-is?
Why does this require explicit opt in by applications if there’s transparent fallback? Wouldn’t it make most sense for the kernel to do it transparently for every TCP connection so that it can make more global decisions about path aggregation / link preference?
If you look at the older multipath TCP implementation, prior to the upstreaming, it was intended to be fully transparent to the application, which I think makes more sense for the intent of the protocol. Sure, in many cases MPTCP may be better with application-guided logic, but having a standard system approach (e.g. establish sub-flows on an LTE connection for automatic failover, but don't send any data along those sub-flows) would have worked for 95% of cases.
[1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
I've heard about MPTCP back in 2013. It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http…
> I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.
You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far.
[1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
I've heard about MPTCP back in 2013. It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http…
> I've heard about MPTCP back in 2013. > I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far. [1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
(SCTP over DTLS, that is...)
Too bad there is no link to projects using mptcp, such as Openwrt derivatives. PS: I mentored a student for 2 years at GSOC to patch Openwrt with mptcp: https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...
I'd think support on web servers and mobile devices would be most important...
I've heard about MPTCP back in 2013. It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http…
> I've heard about MPTCP back in 2013. > I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far. [1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
I've heard about MPTCP back in 2013. It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http…
> I've heard about MPTCP back in 2013. > I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. You might also be interested in SCTP[1] from the year 2000, which also hasn't gotten any traction so far. [1]: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
Probably partly because middleware boxes (e.g., firewalls) either didn't/don't support it and/or rules were written to only support "TCP" (as opposed to 'stream') or "UDP" (as opposed to 'dgram'; see also "DCCP").
Too bad there is no link to projects using mptcp, such as Openwrt derivatives. PS: I mentored a student for 2 years at GSOC to patch Openwrt with mptcp: https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...
Why does this require explicit opt in by applications if there’s transparent fallback? Wouldn’t it make most sense for the kernel to do it transparently for every TCP connection so that it can make more global decisions about path aggregation / link preference?
Imagine you have an application which checks the clients IP (eg. against a whitelist) at the time of connection and then assumes it doesn't change...