 Thank you for coming So welcome. My name is Davide and I work for Red Hat in the networking services team Today we are going to see how we are extending packet drill The goal is to do unit testing and sanity testing for the MPTCP protocol Yes, there has been already an MPTCP talk yesterday made by Paolo where he displayed all the All the efforts in doing the upstreaming process and it was kind of successful because we saw that And that's a very nice thing today we are going to cover up some use cases and How it looks like from the user perspective and of course we will see how we can test the MPTCP So and that's what we are going to do a quick overview of the MPTCP status and Some inner workings of packet drills and then if we will have time We will see if you have any questions and answers and they are there can be for them. So Don't be shy so Are we talking about something really new not because the MPTCP specification? published since many years and Moreover, there is an out-of-tree module that can be built and You can already use MPTCP on your computer and If you have some Android devices also, you can use MPTCP and of course, there's iOS uses it natively What is new here is the protocol version which is a Very new the RFC has been published a few weeks ago so there is version one and it's an IETF standard and What's new is of course the official implementation for the Linux kernel, which is going to be merged gradually in the next weeks Then what will become the next development will be the user space part manager, which will handle the control plane Maybe something to do the flow scheduling in the correct way Yes, I put some References on the bottom of my slides So in case you want just download the presentation and have a look at the sources so this is an open source project and It wouldn't happen without a community. So first of all I have really to thank the MPTCP open source community and I Would like also to thank you if you are willing to contribute to any of these tools and to the Linux kernel and of course to pack a Okay, so Yesterday, there was the question was the use case for MPTCP There's this there is this nice diagram from the IETF Slides back in 2000 and 12 I guess and this is the typical use case for MPTCP So you have a smart phone client There is a web server and you can make use of both the mobile connection and the Wi-Fi connection together To have a somehow better experience. So It's the typical use case What Wi-Fi mode to mobile and over? So in this case when you have two different path to reach your server You can improve your experience if your socket can survive after failure and Maybe you can also have a better experience if socket can aggregate the capacity of different links in order to achieve a better throughput It's not like So it's like a l4 bonding. It's not like New thing. There are other different solutions to the same problem As CTP is one of them and multi path quick is another and Well, now we have three Okay, so how do we Use MPTCP for real that sees typically From the program as point of view what you have to do to use the MPTCP protocol The stack registers to the kernel using as a protocol for IPv4 and IPv6 so You have to call socket using the new IP Proto MPTCP Which has be extended to 16 bits in order to cope with the this new value Then After the socket is created there you can operate the socket like it was a regular TCP socket and This is the example for what happens to a server so you just Bind the to the address listen and then when an incoming connection Connection is detected by the kernel you accept the connection and then you can read and write bytes from the socket This example is taken from the case of test. So we already have case of test in the Netnext kernel tree if you want to see an example of client and server, please check out the sources. Oh by the way MPTCP socket can also be monitored like regular TCP socket. So Once socket is created then the stock will create regular TCP socket To carry the traffic and this is done using the TCP ULP infrastructure When a ULP creates a TCP socket, you can just monitor it using SS command and What you will find here is The ULP Relative Information At the moment you will only see this thread but the message already contains some more stuff That can be used to troubleshoot your connection. Moreover, we are going to implement the support for innet the other and With that it will be possible to know which process sees are opening MPTCP socket. So once MPTCP starts transmitting packets you can use TCP dump to Sniff the packets and you will see MPTCP related information in the TCP dump output There's also wireshark support and this is an example of 3-way yam shake Where the MPTCP client and server exchange their keys This is an example of MPTCP v0, but soon TCP dump Will accept the pull request that implements support for MPTCP v1. So it's code is already there Okay So now that we know how packet MPTCP can Be operated and how packets are there. We can just use this information to do some basic testing Why we are doing this because of sanity because we are Touching the TCP protocol and we need to ensure that TCP will be the bug free even after our our modification and also to test the MPTCP protocol and assess the Correct implementations versus the IATF standard. So let's see how packet drill is and how it works So a packet drill has been developed by Google To do unit tests for the TCP protocol as you probably know the TCP protocol has many extensions Many options that are obtained that are optionals and there is a test suite for that So it provides a coverage for most Probably all the TCP features and for the socket API with packet drill There is already out of three part of the project that is meant to do the unit testing for the out-of-three module We cannot use that tree at all for the MPTCP net next because the socket API is different and Moreover, that one does not support v1 yet probably will not support V1 at all because we are trying to make this Working for both versions out of tree and in tree Okay now How packet drill works? so So this is a typical command line that I do in order to run a script packet tree is made with a A program that passes a script the program uses a packet socket to inject packets and to sniff packets from the kernel that we are testing and There's the possibility within the same scripts to send system calls So you can open a socket you can listen you can find you cannot check you can read write you can to pull everything can be done in the same script and This is a typically what happens the script does the passing then packet will read the line and Determines whether to send any bound packets the terminologies that inbound packets are packets directly directed to the camera Or just receive an open packets So from the kernel to packet ring and this is done with a dissection so it can understand whether the packet is correct And then of course we packet which you can send system calls to the kernel under test Now this is an example with the TCP protocol It's not a real test done by the TCP I just Be able to explain this so It's a server Transes a server we open a socket bind and listen and then on This packet we send a sim packet and start the trip we ensure so the camera is a server and packet drill acts as a client Once the connection is accepted. I try to forge a bad packet. It's this purple one. This is a bad packet why anybody knows it's a bad packet because It does not act anything So it has no flags It does not act and the standard says that this is a bad packet and we should discard the details from this how do I test this by Checking how many packets are in the socket queue? if the expected back there Packets in the queue are there. This is the expected there and the test goes on Now I send the same packet With the good flex, so I And it acts Exactly the data that have been received now. I repeat the same To check So this is a correct way and now I can read this 1000 bytes and The test passes Yes, it passes Okay So what we do now with mptcp I Took the out-of-tree code and re-based over the latest drop from Google and I did some modification to have it dealing with the mptcp socket with the new number and after that We have the support for the version one of the protocol and Started adding some tests. We have the test for the mp capable option We are the test for the DSS and basic support for the DSS, which is the data plane So by the way, this one is the repository where you can download the latest packet here is Something similar to the test you watch it before but it's related to the free way and shake of an mptcp socket So as you can see there is a server on the first four lines and There is a three-way and shake but now we can see that we are dissecting and Injecting mptcp option in the mp capable So also in this case I have to put a bad packet and The very first test was to try to inject a packet with the wrong mptcp version Here the standard mandates that we should fall back to tcp, so not resetting the connection But fall back to tcp and not talk mptcp anymore for this socket So I still checked the connection and I check if the data plane is functional So I'm able to write and read bytes from this socket But I will not transmit nor receive any DSS option Okay the DSS option so The DSS option as you probably know Controlls the traffic plane, so it controls the mapping of data between the tcp level and the mptcp level doing a test we want to control if the data sequence signaling is correct and so This is an example of testing the DSS option after the three-way yank shake we do a write and We expect a packet having the DSS option that acts And then we do a read and check if the Data arc increases by the number of data that we read So in this case the mptcp specification allows different formats for the DSS adder, so There are many options you can use DSN and the DAC values made of 32 or 64 bits In any combination, so it's very very likely to find bugs here Okay now What about mpt join because mptcp is multi-bots And we want to test multi-bots Amounts the mptcp option mp join can be used to join an existing connection So once an mptcp socket is open You can create another flow and you will see the mpt join option in the packet well This is done in the out-of-tree module using a sort of hint, which is this green work that you see there um So and the out-of-tree module tends to open a different socket from user space for each subflow and Then join them them together So typically the out-of-tree module Wants to send An heat to the passer saying okay this packet is Destinated to socket number five. Of course this cannot be done in the Netnext mptcp implementation because since we are using the tcp ULP Sockets are handled by the kernel and the user will only hold the mptcp socket handle so This one cannot be part of the netnext implementation We are implementing a way to Allow testing multiple sockets simultaneously that would improve also the capability of testing tcp and Of course it will allow to test the mpt join Next to come what we'll be next we will be Implement the join scenarios Like I said before and then we will implement what is missing from the code to the spec So we are we'll be testing the other option MP reset option also the ladder and of course once we add a new option We will increase the test coverage we expect the test coverage to be very very big and Like I said before any contribution is very welcome So if you find out some tests that can fit Packet referendity simply please do a poor request Okay, I think That's all do you have any question one candy one candy. Okay first first first you Okay, so the question is What is the state of mptcp protocol versus IPv6 connectivity? Yes, so the out of three modular resist registers It sells as a protocol bought for a finite and a finite six so It's meant to work with the IPv6 IPv6 protocol since the very beginning This applies to v0 and v1 But probably you will only see v1 if you test an official new cabinet because Implementation is starting from v1 protocol By the way, if you run packet drill, it's possible to see to test with the same script IPv4 IPv6 and IPv6 map up to 4 so there is a good script that tested all Other question Okay, so the question is do you plan to enhance IPerf or IPerf3 or netperf maybe also to add support for mptcp theoretically Yes, that would be an option. So it Would just be a poor request in order to support the new IP protocol version on the socket and that's it, but Our plan is also to have this Supported in a seamless way. So using a BPF program you can overload the socket method Catching the new IP protocol and ptcp value. So once you see 262 in the IP protocol the BPF program changes it to b6 and so using the same API you use a tcp program, but for real the kernel is doing mptcp So that's it. That is what we are thinking about The idea is to make a BPF program on top of our C group On top of our C group B2 Sorry don't get the question You can send us a thousand back and so as soon as you do a right In a pocket to a script If the if you are writing enough bytes then the kernel will send many many bytes and It's supposed GSO so and TSO. So if you send a big amount of the data and the kernel as TSO on you will see a mega packet there You can turn off TSO Send a big amount of data and we will have to dissect As many packets as They fit to the size that you sent Sorry, you have to take hands, but otherwise the questions are not good Okay, so the question is what about Scapi because Scapi can do the same thing as packet drill Yes, but it cannot do system calls So it's very likely that you Can do a Scapi script with the exact same functionality as packet drill but if you look at If you look at this This one Doing a writer reader with Scapi is not that easy You can inject a packet Build a packet and inject it over an F packet, but you cannot test the system calls So the advantage packet is that you test packets and system calls together questions. Thanks a lot