search

includeos / IncludeOS

A minimal, resource efficient unikernel for cloud services
https://www.includeos.org
Apache License 2.0
4.9k stars 359 forks source link

Multipath TCP #1490

Open victorstewart opened 7 years ago

victorstewart commented 7 years ago

Any word on when Multipath TCP is coming / if it's in the works? :)

ingve commented 7 years ago

@AndreasAakesson or @AnnikaH could probably give you the latest information about anything TCP-related in IncludeOS.

AndreasAakesson commented 7 years ago

Hello. We haven't really looked at it nor made a decision about it. I don't think it will be something we would make a priority atm, but we would gladly appreciate contributions in form of drafts, pull requests or just ideas :)

naeemk commented 5 years ago

A not so unrelated question: does the current TCP implementation do congestion control? that's probably something you want to have before mptcp! ;)

ingve commented 5 years ago

@AndreasAakesson knows everything about the current TCP implementation, so I'm sure he can update us about the status of congestion control.

AndreasAakesson commented 5 years ago

We do have New Reno implemented (this is pretty deep coupled with our TCP implementation). Selective ACK is also more recently implemented, but not yet integrated with congestion control (I know there are some improvements you can do here).

naeemk commented 5 years ago

Sure, Linux uses CUBIC CC though, but it also makes sense to go with the IETF standard (NewReno). For long-term future, since this is likely to run on hypervisor potentially in a DC environment, it'd be good to have DCTCP (and ECN) support too. Also won't hurt to add (again in the long-run) some sort of LBE CC to the set for any background traffic (backups, large non-latency-sensitive data transfers) you don't want to get in the way of latency-sensitive/regular traffic .

AndreasAakesson commented 5 years ago

Many things I haven't heard about here hehe. Sounds like you have a lot of insight :) The reason for New Reno is just a result of working through RFCs - where 5681 is listed as core functionality. ECN is of course something we want/should have.

I think the first thing that has to be done tho is to make the TCP implementation more flexible for the choice of different congestion controls - today it isn't and it's some/a lot work due to New Reno being so integrated in so many parts of TCP.

If you want I'd would really like if you could create separate issues for each of these things so we can keep better track of it :) You interested in implementing any of them?

naeemk commented 5 years ago

Many things I haven't heard about here hehe. Sounds like you have a lot of insight :) The reason for New Reno is just a result of working through RFCs - where 5681 is listed as core functionality. ECN is of course something we want/should have.

Totally agree on that. Basic ECN support for networking can be useful specially you need it if your datacenter is doing DCTCP-like transfer where ECN-marking/response is defined differently than the RFC3168. My colleagues at the IETF have been working on defining a more accurate (fine-grained) ECN feedback here: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn

I think the first thing that has to be done tho is to make the TCP implementation more flexible for the choice of different congestion controls - today it isn't and it's some/a lot work due to New Reno being so integrated in so many parts of TCP.

I agree. FreeBSD (and Linux) use a modular CC for their TCP congestion control where you can plug in/out different modules and get the desired algo.

If you want I'd would really like if you could create separate issues for each of these things so we can keep better track of it :)

I agree. I'll generate some issues later (or go head directly and make them)

You interested in implementing any of them?

It sounds something really fun for me to take on though my unpaid timeslots are strictly unlimited these days.