| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <201101211419.55476.christoph.paasch@uclouvain.be> Date: Fri, 21 Jan 2011 14:19:55 +0100 From: Christoph Paasch <christoph.paasch@...ouvain.be> To: Peter Chacko <peterchacko35@...il.com> Cc: netdev@...r.kernel.org, bonding-devel@...ts.sourceforge.net, linux-sctp@...r.kernel.org, MS PRASAD <prasad_drdo@...iffmail.com>, Lal Samuel Varghese <lalsam@...il.com>, "Gregory S. Tseytin" <tseyting@....org> Subject: Re: MultiPath TCP in the Linux Kernel Hi Peter, On Thursday, January 20, 2011 wrote Peter Chacko: > Is there any document that shows the difference of SCTP multi-streaming and > MPTCP ? SCTP team has done lot of great workin in load-balanced > multi-streaming work across multi-hopped hosts. I am curious to learn more > on your work in the context of this. MPTCP can be compared to SCTP-CMT. Regular SCTP just uses one path for a stream and thus does not increase the throughput. At http://inl.info.ucl.ac.be/mptcp/ is a master thesis from a student, where he compared plenty of different multi-path transport solutions. Have a look at the document "multi-path congestion control" from Arnaud Ongenae on this website. > Does MP-TCP make use of CM ? (Congestion Manager, created out of MIT) for > sharing congestion states across TCP ensembles ? No, MPTCP uses the coupled congestion control. However, this congestion- manager might be an interesting extension to mptcp. > How does it work with a firewall that will allow only a session that is the > reply of a SYN packet from inside firewall ? (Because other parallel > streams of TCP doesn't send SYN to the same destination, and how will the > firewall will allow the replies of this other session go through ? ) You mean the case, where a server has 2 interfaces, and a client (behind the firewall) establishes a MPTCP-session to the server? The server will tell the client about it's available addresses. Additionally, the server will try by itself the establishment of the additional subflow. This attempt will get blocked by the firewall. As the server sended its set of addresses to the client, the client will also attempt to establish a new subflow. This attempt will pass the firewall as it comes from the inside. > Is there any commerical use of this work ? Our implementation is still in alpha-state. There are still missing features, and it's not yet 100% stable. It's a major modification of the TCP/IP-stack because packets from the subflows need to get pushed up to the 'meta- connection' and reordered there. > Will this also support message level TCP packet exchange ? (So that main > strengths of SCTP are "in" to the TCP stack ). What do you mean with "message level TCP packet exchange" ? Best regards, Christoph > 2011/1/20 Christoph Paasch <christoph.paasch@...ouvain.be> > > > Hi, > > > > MultiPath TCP is not a port of SCTP. It is based on regular TCP and > > presents a > > regular socket-api to the application. Thus applications do not have to > > be modified. > > > > MPTCP opens several TCP-subflows across it's different IP-addresses, and > > lets > > the data go over these different TCP sessions. To synchronize the data- > > transfer MPTCP uses TCP-options. Thus, on the wire it looks like regular > > TCP, > > with the only difference being that there are additional TCP-options. > > > > MPTCP increases the throughput, because it uses the TCP-subflows > > simultaneously. With our implementation we got 2Gbps throughput for a > > single > > iperf-session on a machine having two 1Gb-interfaces (using > > jumbo-frames), whereas regular TCP could only go up to 1Gbps, as it only > > uses one interface. > > > > To maintain bottleneck-fairness the Coupled Congestion Control controls > > the congestion window of the individual subflows (included in the > > implementation > > since the latest release). > > http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ > > > > > > Cheers, > > Christoph > > > > P.S.: We have a public webserver running MPTCP at > > http://mptcp.info.ucl.ac.be > > So you can directly try out the power of MPTCP... ;-) > > > > On Thursday, January 20, 2011 wrote Peter Chacko: > > > SCTP already provides that , and is TCP Multi-Path is going to be a > > > port > > > > of > > > > > it or any other difference ? > > > > > > We are looking to use SCTP for this feature, but as we found it it has > > > > not > > > > > kicked off , because of its firewall issues, we are trying add > > > Multi-Pathing at application layer, sharing all the congestion > > > > states(like > > > > > CM idea) as we are building a WAN optimized storage replication module > > > as part of our cloud storage gateway development. > > > > > > Curious to see more info on this. > > > > > > Thanks > > > > > > 2011/1/20 Christoph Paasch <christoph.paasch@...ouvain.be> > > > > > > > Hi all, > > > > > > > > The IETF is developing a new transport layer solution, MultiPath TCP, > > > > which allows to efficiently exploit several Internet paths between a > > > > pair of hosts, > > > > while presenting a single TCP connection to the application layer. > > > > > > > > At the UCLouvain in Belgium we are developping the support for > > > > MultiPath > > > > > > TCP > > > > in the Linux Kernel. The implementation is a major extension to the > > > > Linux > > > > > > TCP- > > > > stack. > > > > > > > > For general information, access: > > > > http://inl.info.ucl.ac.be/mptcp > > > > https://scm.info.ucl.ac.be/trac/mptcp/ > > > > > > > > To access the git-repository: > > > > git://scm.info.ucl.ac.be/mtcp.git > > > > > > > > branches: > > > > mptcp_2.6.36 - based on Linux Kernel 2.6.36 > > > > mtcp_no_subrcvqueue - based on Linux Kernel 2.6.28 > > > > > > > > For questions, feedback,... feel free to subscribe to the mptcp-dev > > > > Mailing- > > > > List: > > > > https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev > > > > > > > > > > > > Regards, > > > > Christoph > > > > > > > > -- > > > > Christoph Paasch > > > > PhD Student > > > > > > > > IP Networking Lab --- http://inl.info.ucl.ac.be > > > > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > > > > Université Catholique de Louvain > > > > > > > > www.rollerbulls.be > > > > -- > > > > -- > > > > To unsubscribe from this list: send the line "unsubscribe netdev" in > > > > the body of a message to majordomo@...r.kernel.org > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > Christoph Paasch > > PhD Student > > > > IP Networking Lab --- http://inl.info.ucl.ac.be > > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > > Université Catholique de Louvain > > > > www.rollerbulls.be > > -- -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Université Catholique de Louvain www.rollerbulls.be -- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists