https://www.nsnam.org/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Natale 2026-04-15T12:54:13Z User contributions MediaWiki 1.39.8 https://www.nsnam.org/mediawiki/index.php?title=GSOC2019Projects&diff=11465 2019-03-04T16:28:49Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2019 Google Summer of Code project ideas for ns-3.<br /> <br /> <br /> * [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br /> * [[GSOC2019StudentGuide |ns-3's 2019 GSoC Student guide]]<br /> * [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]<br /> * [[GSOC2019StudentApplicationTemplate |2019 GSoC Student application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Student Selection Process]]<br /> * ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.<br /> <br /> ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-18. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br /> <br /> === Org admins ===<br /> <br /> Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br /> <br /> === Mentors ===<br /> <br /> Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2019, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.<br /> <br /> The current list of prospective mentors for 2019 (depending on project selection) includes Zoraze Ali, Abhijith Anilkumar, Gabriel Arrobo, Biljana Bojovic, Ankit Deepak, Lorenza Giupponi, Alexander Krotov, Natale Patriciello, Manoj Kumar Rana, Mohit Tahiliani, and Dizhi Zhou.<br /> <br /> === Students: how to participate ===<br /> <br /> For students interested in applying to ns-3 for GSOC, please go through the following list to get started:<br /> * Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br /> * Read [[GSOC2019StudentGuide |ns-3's GSoC Student guide]].<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [http://www.nsnam.org/ns-3-29/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br /> * Once it is posted, look through the [[GSOC2019StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br /> * Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br /> * In parallel, make sure you prepare a patch as per the [[GSOC2019PatchRequirement | Patch Requirement Guidelines]] (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.<br /> <br /> Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2019. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.<br /> &lt;/blockquote&gt;<br /> <br /> === Mentors: how to participate ===<br /> <br /> The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:<br /> <br /> * The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.<br /> * The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.<br /> * There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to students:''' These ideas are not listed in any priority order. <br /> <br /> ==== Improvement of usability and maintainability of LTE schedulers ====<br /> <br /> Mentors: Zoraze Ali, Biljana Bojovic<br /> <br /> The LTE scheduler is a key RAN feature that allows to analyze many information received at eNB MAC layer and take fundamental decisions in terms of the radio resurces to be allocated. The LTE module offers multiple schedulers, characterized by a high number of lines, many of which are duplicated. This complicates the maintainability of the code, since every time that something needs to be changed in the scheduler, needs to be changed in all the schedulers. And also complicates the usability, since the structure of the code is monolithic, while the user often needs to just get access to some input information, and change the scheduler policy in order to test different scheduler solutions. The proposal of this project is to reorganize the schedulers' structure in a more modular way, in order to overcome the duplication of lines of code and facilitate the usability of this important LTE functionality.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' LTE cellular networks<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== API for UE scheduler ====<br /> <br /> Mentors: Zoraze Ali, Lorenza Giupponi<br /> <br /> Similar to the classical LTE networks, the scheduler in the LTE module of ns-3 lies at the eNB, which interacts with its MAC by using a well defined API based on the FemtoForum MAC Scheduler Interface. However, with the advent of new paradigms, e.g., LAA, LTE ProSe, V2X and 5G NR, the concept of autonomous uplink scheduling has became more prominent. To incorporate such capability into the LTE module of ns-3 the MAC layer API of UE needs to be extended in a similar fashion as the eNB by using the FemtoForum MAC Scheduler Interface. This would allow custom implementation of UE schedulers to simulate the scenarios with autonomous uplink scheduling.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' Cellular networks, LTE<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== Usability improvements ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], Dizhi Zhou, others TBD<br /> <br /> Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some possible project examples:<br /> * Tools and scripts to conduct and manage data from a large number of simulation runs<br /> * How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]<br /> * Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&amp;rep=rep1&amp;type=pdf Yavista]<br /> <br /> ==== L4/L3 routing improvement ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> At the moment, each packet in ns-3 is routed independently. Even though this is a good behaviour for routers, it is not for the source node (expecially for TCP). As a matter of fact, when a TCP connection is established, *all* its packets should be directed to the very same output interface. The same goes for UDP when the source address is forced to be a specific one.<br /> The project idea is to modify the TCP and UDP stacks so that they can store the source address after the connection phase, and skip part of the routing process.<br /> * ''Required Experience:'' C++, TCP, UDP<br /> * ''Bonus Experience:'' IPv4 and IPv6 routing<br /> * ''Interests:'' TCP and UDP<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1041 Bug 1041]<br /> <br /> ==== NetDevice up/down consistency and event chain ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], Manoj Kumar Rana<br /> <br /> There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost).<br /> This prevents some &quot;normal&quot; behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc.<br /> As a matter offact, one should expect that an IP interface would be declared as &quot;down&quot; when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way. <br /> * ''Required Experience:'' C++, NetDevices, Interface behavior<br /> * ''Bonus Experience:'' NetDevice and IP behavior<br /> * ''Interests:'' NetDevice and IP behavior<br /> * ''Difficulty:'' medium<br /> <br /> ==== Wi-Fi mesh module upgrade ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).<br /> <br /> * ''Required Experience:''C++, Wi-Fi and mesh understanding<br /> * ''Interests:'' mesh networking<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' mesh issues in the [https://www.nsnam.org/bugzilla/buglist.cgi?component=mesh&amp;product=ns-3&amp;query_format=advanced&amp;resolution=--- tracker], and the mesh module documentation, and IEEE 802.11 standard<br /> <br /> ==== Direct Code Execution upgrade ====<br /> <br /> Mentor: [mailto:mattator@gmail.com Matthieu Coudron]<br /> <br /> ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&amp;content=&amp;no_redirect=1&amp;order=Importance&amp;product=dce&amp;query_format=specific open DCE issues in our tracker], for starters.<br /> * ''Required Experience:'' good hacking skills on Linux, C, C++, Python<br /> * ''Difficulty:'' Hard.<br /> * ''For more information:'' https://www.nsnam.org/overview/projects/direct-code-execution/dce-1-9/<br /> <br /> ==== Freshen ns-3/Click integration ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010. We seek a student interested in the following tasks: <br /> <br /> * Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.<br /> ** Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.<br /> * There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here: https://codereview.appspot.com/4890044/<br /> ** The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).<br /> * Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.<br /> <br /> The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' IPv4, IPv6, Click.<br /> * ''Interests:'' Software integration.<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== User-friendly internet-apps ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, &quot;Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file &lt;filename.txt&gt;&quot;, or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.). <br /> <br /> * ''Required Experience:''C++<br /> * ''Interests:'' Network performance management<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> <br /> ==== nam upgrade and support for ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> [http://www.isi.edu/nsnam/nam/ nam] is a Tcl/Tk-based animator for ns-2. Some example videos are found at [https://www.youtube.com/results?search_query=nam+network+animator YouTube]. nam has been functionally replaced in many ways by [https://www.nsnam.org/wiki/NetAnim NetAnim], but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos. <br /> <br /> * ''Required Experience:''C++, Tcl/Tk also preferred<br /> * ''Interests:'' Network visualization/animation<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** the links listed above<br /> <br /> ==== ns-2 ports to ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> [http://www.isi.edu/nsnam/ns/ ns-2] is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.<br /> <br /> * ''Required Experience:''C++, ns-2 also preferred<br /> * ''Difficulty:'' Low to medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== TCP testing and alignment ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** Similar FreeBSD test suite: https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionTestSuite<br /> ** https://wiki.linuxfoundation.org/networking/tcp_testing<br /> <br /> ==== TCP analysis ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as [http://research.protocollabs.com/captcp/ captcp], [http://www.wireshark.org Wireshark TCP analysis], [http://www.tcptrace.org/ tcptrace], [http://tstat.polito.it/ Tstat], or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.<br /> <br /> As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies &quot;10.0.0.1:*&quot; and &quot;192.168.0.1:80&quot;, and if there are three connections in the simulation from 10.0.0.1 to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== 802.15.4 Bootstrap ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.<br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== 802.15.4 Beacon-enabled mode ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module. <br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium/hard<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== DSR routing RFC compliance ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.<br /> The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.<br /> A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.<br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' DSR standard<br /> * ''Interests:'' Ad-hoc routing<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]<br /> <br /> ==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV and DSR. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV and DSR implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/dsr.html DSR model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> ==== 3GPP Channel model for sub 6-GHz and porting to ns-3 mainline ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:bbojovic@cttc.cat Biljana Bojovic], [mailto:sandra.lagen@cttc.cat Sandra Lagen]<br /> <br /> Among the multiple valuable contributions provided by the mmWave fork, there is the 3GPP channel and the beamforming antenna model. These features are modeled for the mmWave bands (&gt;= 6 GHz), as defined in the reference 3GPP document (3GPP TR 38.900). The purpose of this project would be to extend the mentioned model to frequency bands below 6GHz, i.e., to the model described in TR 38.901. Besides, the project would require a refactoring of the code, in such a way that it can be included in mainline ns-3, with some parts in propagation and others in antenna modules. The objective would be to make these models accessible from other modules (inside or outside mainline), such as LTE, mmWave, and NR. The resulting code will be the foundation of an improved M-MIMO model in LTE.<br /> <br /> Other interesting additions, up to the students, are the management of panels and the antenna polarization. The proposal must include documentation and testing code.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' Familiarity with 3GPP, and LTE/NR/mmWave module<br /> * ''Interests'': Cellular networks, LTE, NR<br /> * ''Difficulty'': Medium/Hard<br /> * ''Recommended reading'': LTE ns-3 documentation, 3GPP TR 38.900, TR 38.901, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8344116<br /> <br /> ==== &lt;del&gt; Persistent and Semi-Persistent Scheduling inside LTE module &lt;/del&gt; ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:sandra.lagen@cttc.cat Sandra Lagen]<br /> <br /> If you were thinking on going for this project, please contact the mentors. Right now, the proposal is suspended.<br /> <br /> Please get in touch with Natale and Sandra before going straight with this project. The goal of this project is to implement Semi-Persistent Scheduling (SPS) scheme in the ns-3 LTE module. SPS scheme is enabled in 4G LTE, as well as in 5G, in order to save L1/L2 (layer 1/layer 2) control signaling and reduce resource overhead for some periodic and predictable traffic, such as voice over IP (VoIP) and traffic from sensors/IoT devices. Currently, in ns-3 LTE, only Dynamic Scheduling (DS) scheme is implemented, for which the scheduling decisions are dynamically signaled on L1/L2 control to indicate the allocated resources. Differently, in SPS, only the first scheduling assignment is signaled on L1/L2, and the subsequent transmissions use the same resources with a preconfigured interval, thus reducing L1/L2 overhead. In particular, SPS periodicity is configured by RRC, and then activation is signaled through the downlink control information (DCI), both for downlink and uplink SPS. The idea of this project is to extend RRC parameters, and DCI formats, to enable SPS scheme, and to update the MAC scheduler (L2) to enable both SPS and DS schemes for different traffic simultaneously. The later requires, among others, a memory in the scheduler, so as not to allocate resources for DS that are already scheduled for SPS.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with lte module<br /> * ''Interests:'' LTE scheduling (MAC layer)<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== Structured logging support ====<br /> <br /> Mentors: [mailto:krotov@iitp.ru Alexander Krotov], ?<br /> <br /> Sometimes an experiment with a hard to find bug takes a lot of time to run, so it may be desirable to collect as much information as possible and process it later, without adding traces and running experiment again multiple times.<br /> <br /> Existing NS-3 logging framework does not support structured logging. It is only capable of printing text messages, which are hard to process automatically. In fact, [https://www.nsnam.org/docs/manual/html/logging.html NS-3 manual] even contains a warning:<br /> &lt;blockquote&gt;<br /> The project makes no guarantee about whether logging output will remain the same over time. Users are cautioned against building simulation output frameworks on top of logging code, as the output and the way the output is enabled may change over time.<br /> &lt;/blockquote&gt;<br /> <br /> Currently logs often lack context information, such as MAC addresses, node IDs etc. Even if the required information is present, extracting it from text messages is error-prone, and message format may change from version to version even when the required data is still available. As a result, it is often easier to resort to installing traces and adding conditionals to the NS-3 code, recompiling the code and re-running experiments.<br /> <br /> Structured logging, sometimes called semantic logging, is an approach that solves the problem of logs not being machine-readable.<br /> <br /> For example, instead of writing <br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to &quot; &lt;&lt; m_endPoint-&gt;GetPeerAddress () &lt;&lt; &quot; does not exist&quot;);<br /> &lt;/pre&gt;<br /> it will be possible to write something like<br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;, m_endPoint-&gt;GetPeerAddress (),<br /> &quot;id&quot;, &quot;route_not_exist&quot;);<br /> &lt;/pre&gt;<br /> <br /> When used in text mode, the logging framework will output messages as usual. In addition, it will be able to store messages as dictionaries, for example in [http://jsonlines.org/ JSON Lines], [http://cbor.io/ some binary format] or a [https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/ database].<br /> <br /> The message above could be represented as<br /> &lt;pre&gt;<br /> {<br /> &quot;message&quot;: &quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;: {&quot;type&quot;: &quot;ipv4&quot;, &quot;192.168.1.1&quot;},<br /> &quot;id&quot;: &quot;route_not_exist&quot;<br /> ...<br /> }<br /> &lt;/pre&gt;<br /> In addition, messages need to contain some context, extracted from object &lt;code&gt;this&lt;/code&gt;, object identifier (its pointer) and timestamp.<br /> <br /> The goal of this project is to<br /> * Add API to serialize NS-3 object to dictionaries.<br /> * Implement structured logging framework in the &lt;code&gt;core&lt;/code&gt; module.<br /> * Implement at least text and JSON output, extensible to add more output formats later.<br /> * Add structured logging support to at least some modules, e.g. &lt;code&gt;applications&lt;/code&gt;. It should be possible to incrementally switch to structured logging support later.<br /> <br /> There are hardly any C++ structured logging frameworks. There is a https://github.com/kevincox/sog, which is abandoned and uses Apache 2.0 license, that is incompatible to NS-3 license (GPLv2). As a result, it will probably be required to implement the whole framework from scratch. Structured logging frameworks for other languages, such as https://serilog.net/, can be used for inspiration.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Difficulty:'' medium<br /> <br /> ==== IP Traffic Control in LTE networks ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:p.imputato@gmail.com Pasquale Imputato]<br /> <br /> The TC layer is in the middle between IP and any Netdevice, and its role is to manage the scheduling, and the queueing, of IP packets. To work, it need cooperation by the NetDevices: they have to inform when they are ready to receive new packets, or when their internal queues are full. The project is centered on developing the cooperation between the LTE module and the TC module. The starting point is the work done by a Ph.D. student and to merge it in ns3 dev.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with LTE, TC, and network module<br /> * ''Interests:'' Reducing latencies<br /> * ''Difficulty:'' Easy to Medium<br /> * Interested readings: https://zenodo.org/record/2536822<br /> <br /> ==== Linux-like CAKE queue discipline for ns-3 ====<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> Common Applications Kept Enhanced (CAKE) is the most recent queue discipline added in Linux 4.19. It is a comprehensive queue management framework targeted for home Internet gateways, and integrates the following four components: bandwidth shaping, a new Active Queue Management (AQM) algorithm called COBALT (CoDel BLUE Alternate), handling Differentiated Services (DiffServ) and TCP ACK filtering. The main tasks in this project include: implementation, testing and documentation of individual components of CAKE in ns-3, followed by the integration of these components to form CAKE queue discipline in ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> ==== Improving the ns-3 AppStore and linking with bake ====<br /> <br /> Mentors: [mailto:abhijithabhayam@gmail.com Abhijith Anilkumar]<br /> <br /> The [https://apps.nsnam.org ns-3 AppStore] organizes information about the availability of extensions to the main ns-3 releases, and is built using Django. The app store has backend extensions to the Bake build system, enabling users to build a module from the bakefile.xml file. The main goal of this project is to link the Bake build system with the ns-3 AppStore. As the end goal, we envision letting the user type a command locally, something like &lt;code&gt;bake install mmwave&lt;/code&gt; which automatically fetches the data from the App Store, and does the required installation process. By opening up REST APIs, we send data from the app store in the format that can be processed by bake and then install it. <br /> <br /> * ''Required Experience:'' Familiarity with Python, Django.<br /> * ''Bonus Experience:'' Familiarity with Django Rest Framework.<br /> * ''Difficulty:'' Low to Medium<br /> <br /> [[Category:GSoC]]</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2019Projects&diff=11464 2019-03-04T16:26:15Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2019 Google Summer of Code project ideas for ns-3.<br /> <br /> <br /> * [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br /> * [[GSOC2019StudentGuide |ns-3's 2019 GSoC Student guide]]<br /> * [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]<br /> * [[GSOC2019StudentApplicationTemplate |2019 GSoC Student application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Student Selection Process]]<br /> * ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.<br /> <br /> ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-18. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br /> <br /> === Org admins ===<br /> <br /> Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br /> <br /> === Mentors ===<br /> <br /> Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2019, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.<br /> <br /> The current list of prospective mentors for 2019 (depending on project selection) includes Zoraze Ali, Abhijith Anilkumar, Gabriel Arrobo, Biljana Bojovic, Ankit Deepak, Lorenza Giupponi, Alexander Krotov, Natale Patriciello, Manoj Kumar Rana, Mohit Tahiliani, and Dizhi Zhou.<br /> <br /> === Students: how to participate ===<br /> <br /> For students interested in applying to ns-3 for GSOC, please go through the following list to get started:<br /> * Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br /> * Read [[GSOC2019StudentGuide |ns-3's GSoC Student guide]].<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [http://www.nsnam.org/ns-3-29/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br /> * Once it is posted, look through the [[GSOC2019StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br /> * Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br /> * In parallel, make sure you prepare a patch as per the [[GSOC2019PatchRequirement | Patch Requirement Guidelines]] (to be posted at a later date). Your application to ns-3 will not be considered if you do not fulfill this requirement.<br /> <br /> Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2019. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.<br /> &lt;/blockquote&gt;<br /> <br /> === Mentors: how to participate ===<br /> <br /> The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:<br /> <br /> * The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.<br /> * The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.<br /> * There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to students:''' These ideas are not listed in any priority order. <br /> <br /> ==== Improvement of usability and maintainability of LTE schedulers ====<br /> <br /> Mentors: Zoraze Ali, Biljana Bojovic<br /> <br /> The LTE scheduler is a key RAN feature that allows to analyze many information received at eNB MAC layer and take fundamental decisions in terms of the radio resurces to be allocated. The LTE module offers multiple schedulers, characterized by a high number of lines, many of which are duplicated. This complicates the maintainability of the code, since every time that something needs to be changed in the scheduler, needs to be changed in all the schedulers. And also complicates the usability, since the structure of the code is monolithic, while the user often needs to just get access to some input information, and change the scheduler policy in order to test different scheduler solutions. The proposal of this project is to reorganize the schedulers' structure in a more modular way, in order to overcome the duplication of lines of code and facilitate the usability of this important LTE functionality.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' LTE cellular networks<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== API for UE scheduler ====<br /> <br /> Mentors: Zoraze Ali, Lorenza Giupponi<br /> <br /> Similar to the classical LTE networks, the scheduler in the LTE module of ns-3 lies at the eNB, which interacts with its MAC by using a well defined API based on the FemtoForum MAC Scheduler Interface. However, with the advent of new paradigms, e.g., LAA, LTE ProSe, V2X and 5G NR, the concept of autonomous uplink scheduling has became more prominent. To incorporate such capability into the LTE module of ns-3 the MAC layer API of UE needs to be extended in a similar fashion as the eNB by using the FemtoForum MAC Scheduler Interface. This would allow custom implementation of UE schedulers to simulate the scenarios with autonomous uplink scheduling.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' Cellular networks, LTE<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== Usability improvements ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], Dizhi Zhou, others TBD<br /> <br /> Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some possible project examples:<br /> * Tools and scripts to conduct and manage data from a large number of simulation runs<br /> * How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]<br /> * Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&amp;rep=rep1&amp;type=pdf Yavista]<br /> <br /> ==== L4/L3 routing improvement ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> At the moment, each packet in ns-3 is routed independently. Even though this is a good behaviour for routers, it is not for the source node (expecially for TCP). As a matter of fact, when a TCP connection is established, *all* its packets should be directed to the very same output interface. The same goes for UDP when the source address is forced to be a specific one.<br /> The project idea is to modify the TCP and UDP stacks so that they can store the source address after the connection phase, and skip part of the routing process.<br /> * ''Required Experience:'' C++, TCP, UDP<br /> * ''Bonus Experience:'' IPv4 and IPv6 routing<br /> * ''Interests:'' TCP and UDP<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1041 Bug 1041]<br /> <br /> ==== NetDevice up/down consistency and event chain ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], Manoj Kumar Rana<br /> <br /> There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost).<br /> This prevents some &quot;normal&quot; behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc.<br /> As a matter offact, one should expect that an IP interface would be declared as &quot;down&quot; when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way. <br /> * ''Required Experience:'' C++, NetDevices, Interface behavior<br /> * ''Bonus Experience:'' NetDevice and IP behavior<br /> * ''Interests:'' NetDevice and IP behavior<br /> * ''Difficulty:'' medium<br /> <br /> ==== Wi-Fi mesh module upgrade ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).<br /> <br /> * ''Required Experience:''C++, Wi-Fi and mesh understanding<br /> * ''Interests:'' mesh networking<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' mesh issues in the [https://www.nsnam.org/bugzilla/buglist.cgi?component=mesh&amp;product=ns-3&amp;query_format=advanced&amp;resolution=--- tracker], and the mesh module documentation, and IEEE 802.11 standard<br /> <br /> ==== Direct Code Execution upgrade ====<br /> <br /> Mentor: [mailto:mattator@gmail.com Matthieu Coudron]<br /> <br /> ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&amp;content=&amp;no_redirect=1&amp;order=Importance&amp;product=dce&amp;query_format=specific open DCE issues in our tracker], for starters.<br /> * ''Required Experience:'' good hacking skills on Linux, C, C++, Python<br /> * ''Difficulty:'' Hard.<br /> * ''For more information:'' https://www.nsnam.org/overview/projects/direct-code-execution/dce-1-9/<br /> <br /> ==== Freshen ns-3/Click integration ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010. We seek a student interested in the following tasks: <br /> <br /> * Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.<br /> ** Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.<br /> * There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here: https://codereview.appspot.com/4890044/<br /> ** The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).<br /> * Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.<br /> <br /> The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' IPv4, IPv6, Click.<br /> * ''Interests:'' Software integration.<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== User-friendly internet-apps ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, &quot;Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file &lt;filename.txt&gt;&quot;, or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.). <br /> <br /> * ''Required Experience:''C++<br /> * ''Interests:'' Network performance management<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> <br /> ==== nam upgrade and support for ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> [http://www.isi.edu/nsnam/nam/ nam] is a Tcl/Tk-based animator for ns-2. Some example videos are found at [https://www.youtube.com/results?search_query=nam+network+animator YouTube]. nam has been functionally replaced in many ways by [https://www.nsnam.org/wiki/NetAnim NetAnim], but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos. <br /> <br /> * ''Required Experience:''C++, Tcl/Tk also preferred<br /> * ''Interests:'' Network visualization/animation<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** the links listed above<br /> <br /> ==== ns-2 ports to ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> [http://www.isi.edu/nsnam/ns/ ns-2] is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.<br /> <br /> * ''Required Experience:''C++, ns-2 also preferred<br /> * ''Difficulty:'' Low to medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== TCP testing and alignment ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** Similar FreeBSD test suite: https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionTestSuite<br /> ** https://wiki.linuxfoundation.org/networking/tcp_testing<br /> <br /> ==== TCP analysis ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as [http://research.protocollabs.com/captcp/ captcp], [http://www.wireshark.org Wireshark TCP analysis], [http://www.tcptrace.org/ tcptrace], [http://tstat.polito.it/ Tstat], or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.<br /> <br /> As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies &quot;10.0.0.1:*&quot; and &quot;192.168.0.1:80&quot;, and if there are three connections in the simulation from 10.0.0.1 to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== 802.15.4 Bootstrap ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.<br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== 802.15.4 Beacon-enabled mode ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module. <br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium/hard<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== DSR routing RFC compliance ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.<br /> The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.<br /> A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.<br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' DSR standard<br /> * ''Interests:'' Ad-hoc routing<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]<br /> <br /> ==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV and DSR. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV and DSR implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/dsr.html DSR model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> ==== 3GPP Channel model for sub 6-GHz and porting to ns-3 mainline ====<br /> <br /> Among the multiple valuable contributions provided by the mmWave fork, there is the 3GPP channel and the beamforming antenna model. These features are modeled for the mmWave bands (&gt;= 6 GHz), as defined in the reference 3GPP document (3GPP TR 38.900). The purpose of this project would be to extend the mentioned model to frequency bands below 6GHz, i.e., to the model described in TR 38.901. Besides, the project would require a refactoring of the code, in such a way that it can be included in mainline ns-3, with some parts in propagation and others in antenna modules. The objective would be to make these models accessible from other modules (inside or outside mainline), such as LTE, mmWave, and NR. The resulting code will be the foundation of an improved M-MIMO model in LTE.<br /> <br /> Other interesting additions, up to the students, are the management of panels and the antenna polarization. The proposal must include documentation and testing code.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' Familiarity with 3GPP, and LTE/NR/mmWave module<br /> * ''Interests'': Cellular networks, LTE, NR<br /> * ''Difficulty'': Medium/Hard<br /> * ''Recommended reading'': LTE ns-3 documentation, 3GPP TR 38.900, TR 38.901, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8344116<br /> <br /> ==== Persistent and Semi-Persistent Scheduling inside LTE module ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:sandra.lagen@cttc.cat Sandra Lagen]<br /> <br /> Please get in touch with Natale and Sandra before going straight with this project. The goal of this project is to implement Semi-Persistent Scheduling (SPS) scheme in the ns-3 LTE module. SPS scheme is enabled in 4G LTE, as well as in 5G, in order to save L1/L2 (layer 1/layer 2) control signaling and reduce resource overhead for some periodic and predictable traffic, such as voice over IP (VoIP) and traffic from sensors/IoT devices. Currently, in ns-3 LTE, only Dynamic Scheduling (DS) scheme is implemented, for which the scheduling decisions are dynamically signaled on L1/L2 control to indicate the allocated resources. Differently, in SPS, only the first scheduling assignment is signaled on L1/L2, and the subsequent transmissions use the same resources with a preconfigured interval, thus reducing L1/L2 overhead. In particular, SPS periodicity is configured by RRC, and then activation is signaled through the downlink control information (DCI), both for downlink and uplink SPS. The idea of this project is to extend RRC parameters, and DCI formats, to enable SPS scheme, and to update the MAC scheduler (L2) to enable both SPS and DS schemes for different traffic simultaneously. The later requires, among others, a memory in the scheduler, so as not to allocate resources for DS that are already scheduled for SPS.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with lte module<br /> * ''Interests:'' LTE scheduling (MAC layer)<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== Structured logging support ====<br /> <br /> Mentors: [mailto:krotov@iitp.ru Alexander Krotov], ?<br /> <br /> Sometimes an experiment with a hard to find bug takes a lot of time to run, so it may be desirable to collect as much information as possible and process it later, without adding traces and running experiment again multiple times.<br /> <br /> Existing NS-3 logging framework does not support structured logging. It is only capable of printing text messages, which are hard to process automatically. In fact, [https://www.nsnam.org/docs/manual/html/logging.html NS-3 manual] even contains a warning:<br /> &lt;blockquote&gt;<br /> The project makes no guarantee about whether logging output will remain the same over time. Users are cautioned against building simulation output frameworks on top of logging code, as the output and the way the output is enabled may change over time.<br /> &lt;/blockquote&gt;<br /> <br /> Currently logs often lack context information, such as MAC addresses, node IDs etc. Even if the required information is present, extracting it from text messages is error-prone, and message format may change from version to version even when the required data is still available. As a result, it is often easier to resort to installing traces and adding conditionals to the NS-3 code, recompiling the code and re-running experiments.<br /> <br /> Structured logging, sometimes called semantic logging, is an approach that solves the problem of logs not being machine-readable.<br /> <br /> For example, instead of writing <br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to &quot; &lt;&lt; m_endPoint-&gt;GetPeerAddress () &lt;&lt; &quot; does not exist&quot;);<br /> &lt;/pre&gt;<br /> it will be possible to write something like<br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;, m_endPoint-&gt;GetPeerAddress (),<br /> &quot;id&quot;, &quot;route_not_exist&quot;);<br /> &lt;/pre&gt;<br /> <br /> When used in text mode, the logging framework will output messages as usual. In addition, it will be able to store messages as dictionaries, for example in [http://jsonlines.org/ JSON Lines], [http://cbor.io/ some binary format] or a [https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/ database].<br /> <br /> The message above could be represented as<br /> &lt;pre&gt;<br /> {<br /> &quot;message&quot;: &quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;: {&quot;type&quot;: &quot;ipv4&quot;, &quot;192.168.1.1&quot;},<br /> &quot;id&quot;: &quot;route_not_exist&quot;<br /> ...<br /> }<br /> &lt;/pre&gt;<br /> In addition, messages need to contain some context, extracted from object &lt;code&gt;this&lt;/code&gt;, object identifier (its pointer) and timestamp.<br /> <br /> The goal of this project is to<br /> * Add API to serialize NS-3 object to dictionaries.<br /> * Implement structured logging framework in the &lt;code&gt;core&lt;/code&gt; module.<br /> * Implement at least text and JSON output, extensible to add more output formats later.<br /> * Add structured logging support to at least some modules, e.g. &lt;code&gt;applications&lt;/code&gt;. It should be possible to incrementally switch to structured logging support later.<br /> <br /> There are hardly any C++ structured logging frameworks. There is a https://github.com/kevincox/sog, which is abandoned and uses Apache 2.0 license, that is incompatible to NS-3 license (GPLv2). As a result, it will probably be required to implement the whole framework from scratch. Structured logging frameworks for other languages, such as https://serilog.net/, can be used for inspiration.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Difficulty:'' medium<br /> <br /> ==== IP Traffic Control in LTE networks ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:p.imputato@gmail.com Pasquale Imputato]<br /> <br /> The TC layer is in the middle between IP and any Netdevice, and its role is to manage the scheduling, and the queueing, of IP packets. To work, it need cooperation by the NetDevices: they have to inform when they are ready to receive new packets, or when their internal queues are full. The project is centered on developing the cooperation between the LTE module and the TC module. The starting point is the work done by a Ph.D. student and to merge it in ns3 dev.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with LTE, TC, and network module<br /> * ''Interests:'' Reducing latencies<br /> * ''Difficulty:'' Easy to Medium<br /> * Interested readings: https://zenodo.org/record/2536822<br /> <br /> ==== Linux-like CAKE queue discipline for ns-3 ====<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> Common Applications Kept Enhanced (CAKE) is the most recent queue discipline added in Linux 4.19. It is a comprehensive queue management framework targeted for home Internet gateways, and integrates the following four components: bandwidth shaping, a new Active Queue Management (AQM) algorithm called COBALT (CoDel BLUE Alternate), handling Differentiated Services (DiffServ) and TCP ACK filtering. The main tasks in this project include: implementation, testing and documentation of individual components of CAKE in ns-3, followed by the integration of these components to form CAKE queue discipline in ns-3.<br /> <br /> * ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with CAKE framework in Linux 4.19<br /> * ''Interests:'' Active Queue Management, Packet scheduling and TCP.<br /> * ''Difficulty:'' Medium to Hard<br /> * ''Recommended reading:''<br /> ** [https://arxiv.org/pdf/1804.07617.pdf Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways]<br /> ** [https://lwn.net/Articles/758353/ Let them run CAKE]<br /> ** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue disciplines in ns-3]<br /> <br /> ==== Improving the ns-3 AppStore and linking with bake ====<br /> <br /> Mentors: [mailto:abhijithabhayam@gmail.com Abhijith Anilkumar]<br /> <br /> The [https://apps.nsnam.org ns-3 AppStore] organizes information about the availability of extensions to the main ns-3 releases, and is built using Django. The app store has backend extensions to the Bake build system, enabling users to build a module from the bakefile.xml file. The main goal of this project is to link the Bake build system with the ns-3 AppStore. As the end goal, we envision letting the user type a command locally, something like &lt;code&gt;bake install mmwave&lt;/code&gt; which automatically fetches the data from the App Store, and does the required installation process. By opening up REST APIs, we send data from the app store in the format that can be processed by bake and then install it. <br /> <br /> * ''Required Experience:'' Familiarity with Python, Django.<br /> * ''Bonus Experience:'' Familiarity with Django Rest Framework.<br /> * ''Difficulty:'' Low to Medium<br /> <br /> [[Category:GSoC]]</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2019Projects&diff=11447 2019-02-06T09:28:21Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> This page contains 2019 Google Summer of Code project ideas for ns-3.<br /> <br /> '''Important note:''' Google has not selected participating open source projects yet; we are only in the application phase.<br /> <br /> <br /> * [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br /> * [[GSOC2018StudentGuide |ns-3's 2018 GSoC Student guide]]<br /> * [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]<br /> * [[GSOC2018StudentApplicationTemplate |2018 GSoC Student application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Student Selection Process]]<br /> * ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.<br /> <br /> ns-3 has participated in past GSoCs during 2008-10, 2012-15, and 2017-18. We seek students interested in the intersection of wireless and computer networking, performance analysis, and open source software.<br /> <br /> === Org admins ===<br /> <br /> Google Summer of Code organizational admins for ns-3 are [mailto:tpecorella@mac.com Tommaso Pecorella] and [mailto:tomh@tomh.org Tom Henderson]; contact them with any questions. They also hang out on [https://ns-3.zulipchat.com Zulip].<br /> <br /> === Mentors ===<br /> <br /> Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge. In 2019, we are going to be seeking two-person or multiple-person mentoring teams for projects, to help with the mentoring workload and bring more expertise.<br /> <br /> The current list of prospective mentors for 2019 (depending on project selection) includes Zoraze Ali, Abhijith Anilkumar, Gabriel Arrobo, Biljana Bojovic, Ankit Deepak, Lorenza Giupponi, Alexander Krotov, Natale Patriciello, Manoj Kumar Rana, Mohit Tahiliani, and Dizhi Zhou.<br /> <br /> === Students: how to participate ===<br /> <br /> For students interested in applying to ns-3 for GSOC, first wait to see if ns-3 will be selected. If so, then go through the following list to get started:<br /> * Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br /> * Read [[GSOC2018StudentGuide |ns-3's GSoC Student guide]].<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [http://www.nsnam.org/ns-3-29/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br /> * Look through the [[GSOC2018StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br /> * Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br /> * In parallel, make sure you prepare a patch as per the [[GSOC2018PatchRequirement | Patch Requirement Guidelines]] (to be revised). Your application to ns-3 will not be considered if you do not fulfill this requirement.<br /> <br /> Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2019. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.<br /> &lt;/blockquote&gt;<br /> <br /> === Mentors: how to participate ===<br /> <br /> The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:<br /> <br /> * The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.<br /> * The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.<br /> * There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to students:''' These ideas are not listed in any priority order. <br /> <br /> ==== Improvement of usability and maintainability of LTE schedulers ====<br /> <br /> Mentors: Zoraze Ali, Biljana Bojovic<br /> <br /> The LTE scheduler is a key RAN feature that allows to analyze many information received at eNB MAC layer and take fundamental decisions in terms of the radio resurces to be allocated. The LTE module offers multiple schedulers, characterized by a high number of lines, many of which are duplicated. This complicates the maintainability of the code, since every time that something needs to be changed in the scheduler, needs to be changed in all the schedulers. And also complicates the usability, since the structure of the code is monolithic, while the user often needs to just get access to some input information, and change the scheduler policy in order to test different scheduler solutions. The proposal of this project is to reorganize the schedulers' structure in a more modular way, in order to overcome the duplication of lines of code and facilitate the usability of this important LTE functionality.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' LTE cellular networks<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== API for UE scheduler ====<br /> <br /> Mentors: Zoraze Ali, Lorenza Giupponi<br /> <br /> Similar to the classical LTE networks, the scheduler in the LTE module of ns-3 lies at the eNB, which interacts with its MAC by using a well defined API based on the FemtoForum MAC Scheduler Interface. However, with the advent of new paradigms, e.g., LAA, LTE ProSe, V2X and 5G NR, the concept of autonomous uplink scheduling has became more prominent. To incorporate such capability into the LTE module of ns-3 the MAC layer API of UE needs to be extended in a similar fashion as the eNB by using the FemtoForum MAC Scheduler Interface. This would allow custom implementation of UE schedulers to simulate the scenarios with autonomous uplink scheduling.<br /> <br /> * ''Required Experience:'' C++, Git<br /> * ''Interests:'' Cellular networks, LTE<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' LTE ns-3 documentation and FemtoForum MAC Scheduler Interface API<br /> <br /> ==== Usability improvements ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], Dizhi Zhou, others TBD<br /> <br /> Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some possible project examples:<br /> * Tools and scripts to conduct and manage data from a large number of simulation runs<br /> * How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]<br /> * Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&amp;rep=rep1&amp;type=pdf Yavista]<br /> <br /> ==== L4/L3 routing improvement ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> At the moment, each packet in ns-3 is routed independently. Even though this is a good behaviour for routers, it is not for the source node (expecially for TCP). As a matter of fact, when a TCP connection is established, *all* its packets should be directed to the very same output interface. The same goes for UDP when the source address is forced to be a specific one.<br /> The project idea is to modify the TCP and UDP stacks so that they can store the source address after the connection phase, and skip part of the routing process.<br /> * ''Required Experience:'' C++, TCP, UDP<br /> * ''Bonus Experience:'' IPv4 and IPv6 routing<br /> * ''Interests:'' TCP and UDP<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1041 Bug 1041]<br /> <br /> ==== NetDevice up/down consistency and event chain ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], Manoj Kumar Rana<br /> <br /> There in no actual consistency among the different modules about how to handle Up/Down events (e.g., when a link is lost).<br /> This prevents some &quot;normal&quot; behaviours from happening, e.g., the DHCP IP address renegotiation, MIP implementation, etc.<br /> As a matter offact, one should expect that an IP interface would be declared as &quot;down&quot; when its NetDevice is down... but it isn't. The goal of this project is to fix this behavior, to update some NetDevices so that they use Up/Down events consistently, to provide the documentation about what is the standard behavior, and what NetDevices are actually implementing it in the right way. <br /> * ''Required Experience:'' C++, NetDevices, Interface behavior<br /> * ''Bonus Experience:'' NetDevice and IP behavior<br /> * ''Interests:'' NetDevice and IP behavior<br /> * ''Difficulty:'' medium<br /> <br /> ==== Wi-Fi mesh module upgrade ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).<br /> <br /> * ''Required Experience:''C++, Wi-Fi and mesh understanding<br /> * ''Interests:'' mesh networking<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' mesh issues in the [https://www.nsnam.org/bugzilla/buglist.cgi?component=mesh&amp;product=ns-3&amp;query_format=advanced&amp;resolution=--- tracker], and the mesh module documentation, and IEEE 802.11 standard<br /> <br /> ==== Direct Code Execution upgrade ====<br /> <br /> Mentor: [mailto:mattator@gmail.com Matthieu Coudron]<br /> <br /> ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&amp;content=&amp;no_redirect=1&amp;order=Importance&amp;product=dce&amp;query_format=specific open DCE issues in our tracker], for starters.<br /> * ''Required Experience:'' good hacking skills on Linux, C, C++, Python<br /> * ''Difficulty:'' Hard.<br /> * ''For more information:'' https://www.nsnam.org/overview/projects/direct-code-execution/dce-1-9/<br /> <br /> ==== Freshen ns-3/Click integration ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010. We seek a student interested in the following tasks: <br /> <br /> * Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.<br /> ** Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.<br /> * There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here: https://codereview.appspot.com/4890044/<br /> ** The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).<br /> * Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.<br /> <br /> The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' IPv4, IPv6, Click.<br /> * ''Interests:'' Software integration.<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== User-friendly internet-apps ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, &quot;Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file &lt;filename.txt&gt;&quot;, or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.). <br /> <br /> * ''Required Experience:''C++<br /> * ''Interests:'' Network performance management<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> <br /> ==== nam upgrade and support for ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> [http://www.isi.edu/nsnam/nam/ nam] is a Tcl/Tk-based animator for ns-2. Some example videos are found at [https://www.youtube.com/results?search_query=nam+network+animator YouTube]. nam has been functionally replaced in many ways by [https://www.nsnam.org/wiki/NetAnim NetAnim], but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos. <br /> <br /> * ''Required Experience:''C++, Tcl/Tk also preferred<br /> * ''Interests:'' Network visualization/animation<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** the links listed above<br /> <br /> ==== ns-2 ports to ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> [http://www.isi.edu/nsnam/ns/ ns-2] is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.<br /> <br /> * ''Required Experience:''C++, ns-2 also preferred<br /> * ''Difficulty:'' Low to medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== TCP testing and alignment ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** Similar FreeBSD test suite: https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionTestSuite<br /> ** https://wiki.linuxfoundation.org/networking/tcp_testing<br /> <br /> ==== TCP analysis ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as [http://research.protocollabs.com/captcp/ captcp], [http://www.wireshark.org Wireshark TCP analysis], [http://www.tcptrace.org/ tcptrace], [http://tstat.polito.it/ Tstat], or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.<br /> <br /> As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies &quot;10.0.0.1:*&quot; and &quot;192.168.0.1:80&quot;, and if there are three connections in the simulation from 10.0.0.1 to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== 802.15.4 Bootstrap ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.<br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== 802.15.4 Beacon-enabled mode ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module. <br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium/hard<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== DSR routing RFC compliance ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.<br /> The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.<br /> A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.<br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' DSR standard<br /> * ''Interests:'' Ad-hoc routing<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]<br /> <br /> ==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV and DSR. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV and DSR implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/dsr.html DSR model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> ==== Data collection and statistics framework extension ====<br /> <br /> Mentors: [mailto:dizhizhou@hotmail.com Dizhi Zhou]<br /> <br /> The goal of this project is to extend and add more functionalities on ns-3 data collection and statistics framework (source code:ns-3.27/src/stats/) which was added in ns-3.18. The model was implemented based on the ns-3 tracing system. It has two major functions. 1) retrieve data from multiple ns-3 trace sources and then recalculate/transform the data into a user-defined format. However, not all the trace source types are supported. 2) use a data collector to calculate some useful statistics from a ns-3 trace source (e.g. max and min of the trace value). However, only supports counter and min/max data collectors are supported today. In order to make the model more useful, more trace source types, output formats and collectors need to be added.<br /> <br /> A parallel project of ns-3, named sns3, proposed an enhancement on this model in 2016. But the patch was not merged to the official release yet. Student may use this patch as a reference for their proposals. Some sample ideas are listed below.<br /> * ''Help to merge sns3 statistic enhancement to ns-3. <br /> * ''Add more trace types<br /> * ''Add more collectors. Ideally, the statistic calculation method should be configurable in the script so that people don’t need to add new collectors when they have any new requirement.<br /> * ''More output format types: excel, MySql, matplotlib, R, Matlab, more picture formats, etc.<br /> * ''Improve documentation and add more example scripts.<br /> <br /> The list is not exhaustive and not limiting. Any new ideas in this area are welcome.<br /> * ''Required Experience:'' C++ programming.<br /> * ''Bonus Experience:'' Proficiency with open source data handling software (e.g. R, matplotlib, SQLite, gnuplot)<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/documentation/ Data collection and trace chapters in ns-3 tutorial/manual/model library]<br /> ** [https://codereview.appspot.com/318800043/ Statistic model enhancement code review from sns3 project]<br /> <br /> ==== Persistent and Semi-Persistent Scheduling inside LTE module ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:sandra.lagen@cttc.cat Sandra Lagen]<br /> <br /> Please get in touch with Natale and Sandra before going straight with this project. The goal of this project is to implement Semi-Persistent Scheduling (SPS) scheme in the ns-3 LTE module. SPS scheme is enabled in 4G LTE, as well as in 5G, in order to save L1/L2 (layer 1/layer 2) control signaling and reduce resource overhead for some periodic and predictable traffic, such as voice over IP (VoIP) and traffic from sensors/IoT devices. Currently, in ns-3 LTE, only Dynamic Scheduling (DS) scheme is implemented, for which the scheduling decisions are dynamically signaled on L1/L2 control to indicate the allocated resources. Differently, in SPS, only the first scheduling assignment is signaled on L1/L2, and the subsequent transmissions use the same resources with a preconfigured interval, thus reducing L1/L2 overhead. In particular, SPS periodicity is configured by RRC, and then activation is signaled through the downlink control information (DCI), both for downlink and uplink SPS. The idea of this project is to extend RRC parameters, and DCI formats, to enable SPS scheme, and to update the MAC scheduler (L2) to enable both SPS and DS schemes for different traffic simultaneously. The later requires, among others, a memory in the scheduler, so as not to allocate resources for DS that are already scheduled for SPS.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with lte module<br /> * ''Interests:'' LTE scheduling (MAC layer)<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== Structured logging support ====<br /> <br /> Mentors: [mailto:krotov@iitp.ru Alexander Krotov], ?<br /> <br /> Sometimes an experiment with a hard to find bug takes a lot of time to run, so it may be desirable to collect as much information as possible and process it later, without adding traces and running experiment again multiple times.<br /> <br /> Existing NS-3 logging framework does not support structured logging. It is only capable of printing text messages, which are hard to process automatically. In fact, [https://www.nsnam.org/docs/manual/html/logging.html NS-3 manual] even contains a warning:<br /> &lt;blockquote&gt;<br /> The project makes no guarantee about whether logging output will remain the same over time. Users are cautioned against building simulation output frameworks on top of logging code, as the output and the way the output is enabled may change over time.<br /> &lt;/blockquote&gt;<br /> <br /> Currently logs often lack context information, such as MAC addresses, node IDs etc. Even if the required information is present, extracting it from text messages is error-prone, and message format may change from version to version even when the required data is still available. As a result, it is often easier to resort to installing traces and adding conditionals to the NS-3 code, recompiling the code and re-running experiments.<br /> <br /> Structured logging, sometimes called semantic logging, is an approach that solves the problem of logs not being machine-readable.<br /> <br /> For example, instead of writing <br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to &quot; &lt;&lt; m_endPoint-&gt;GetPeerAddress () &lt;&lt; &quot; does not exist&quot;);<br /> &lt;/pre&gt;<br /> it will be possible to write something like<br /> &lt;pre&gt;<br /> NS_LOG_LOGIC (&quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;, m_endPoint-&gt;GetPeerAddress (),<br /> &quot;id&quot;, &quot;route_not_exist&quot;);<br /> &lt;/pre&gt;<br /> <br /> When used in text mode, the logging framework will output messages as usual. In addition, it will be able to store messages as dictionaries, for example in [http://jsonlines.org/ JSON Lines], [http://cbor.io/ some binary format] or a [https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/ database].<br /> <br /> The message above could be represented as<br /> &lt;pre&gt;<br /> {<br /> &quot;message&quot;: &quot;Route to {peer_address} does not exist&quot;,<br /> &quot;peer_address&quot;: {&quot;type&quot;: &quot;ipv4&quot;, &quot;192.168.1.1&quot;},<br /> &quot;id&quot;: &quot;route_not_exist&quot;<br /> ...<br /> }<br /> &lt;/pre&gt;<br /> In addition, messages need to contain some context, extracted from object &lt;code&gt;this&lt;/code&gt;, object identifier (its pointer) and timestamp.<br /> <br /> The goal of this project is to<br /> * Add API to serialize NS-3 object to dictionaries.<br /> * Implement structured logging framework in the &lt;code&gt;core&lt;/code&gt; module.<br /> * Implement at least text and JSON output, extensible to add more output formats later.<br /> * Add structured logging support to at least some modules, e.g. &lt;code&gt;applications&lt;/code&gt;. It should be possible to incrementally switch to structured logging support later.<br /> <br /> There are hardly any C++ structured logging frameworks. There is a https://github.com/kevincox/sog, which is abandoned and uses Apache 2.0 license, that is incompatible to NS-3 license (GPLv2). As a result, it will probably be required to implement the whole framework from scratch. Structured logging frameworks for other languages, such as https://serilog.net/, can be used for inspiration.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Difficulty:'' medium<br /> <br /> ==== Persistent and Semi-Persistent Scheduling inside LTE module ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> The TC layer is in the middle between IP and any Netdevice, and its role is to manage the scheduling, and the queueing, of IP packets. To work, it need cooperation by the NetDevices: they have to inform when they are ready to receive new packets, or when their internal queues are full. The project is centered on developing the cooperation between the LTE module and the TC module. The starting point is the work done by a Ph.D. student and to merge it in ns3 dev.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with LTE, TC, and network module<br /> * ''Interests:'' Reducing latencies<br /> * ''Difficulty:'' Easy<br /> * Interested readings: https://zenodo.org/record/2536822<br /> <br /> [[Category:GSoC]]</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=HOWTO_use_distcc_and_ccache&diff=11401 2018-11-14T16:41:45Z

<p>Natale: </p> <hr /> <div><br /> == How to use distcc and ccache for speed up building time ==<br /> <br /> Ns-3 has a lot of files to compile. With the expected growth of different branches and repositories, time spent in compiling is affecting the development time in a considerable way. At the end of this HOWTO, you will be able to store the intermediate result of a compilation (the object files) and to distribute new compilation unit (i.e., when the cached object file does not exist or it has to be updated). You could also selectively disable one (or both) options just by switching an environment variable.<br /> <br /> === Linux: setup distcc ===<br /> <br /> distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network to speed up the building time. It should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile. Use your favorite package manager to install the distcc package.<br /> <br /> In the following, we will use the term ''master'' to indicate the computer which initiates the compilation and which contains the source copy of ns-3, while we will use the term ''slave'' to indicate a computer which accepts compilation requests sent by the master. First of all, in the slaves, follow your distribution guide to set up a working distcc server. For instance, for Archlinux (that is the most easy distribution you can find out there -- forget all the complexity of Ubuntu, multiple package versions, libraries, -dev, and everything that could make you hate the Linux ecosystem) you can refer to [https://wiki.archlinux.org/index.php/Distcc]. Basically, the /etc/conf.d/distcc should look like:<br /> <br /> &lt;pre&gt;<br /> #<br /> # Parameters to be passed to distccd<br /> #<br /> # You must explicitly add IPs (or subnets) that are allowed to connect,<br /> # using the --allow switch. See the distccd manpage for more info.<br /> #<br /> <br /> DISTCC_ARGS=&quot;--allow MASTER_IP --log-level debug --log-file /tmp/distccd.log&quot;<br /> &lt;/pre&gt;<br /> <br /> Then, in the master, install the distcc package without running the server. Then, configure it (following your distribution howto) to have the slave ip in the DISTCC_HOST configuration variable. For instance, for Archlinux, this is easy as having a file /etc/distcc/host with the following content:<br /> <br /> &lt;pre&gt;<br /> # --- /etc/distcc/hosts -----------------------<br /> # See the &quot;Hosts Specification&quot; section of<br /> # &quot;man distcc&quot; for the format of this file.<br /> #<br /> # By default, just test that it works in loopback mode.<br /> #127.0.0.1<br /> SLAVE_IP,lzo,cpp<br /> &lt;/pre&gt;<br /> <br /> Just replace the SLAVE_IP with the IP address of the slave. Please note that this configuration is '''insecure''' because sources and objects are traveling the network with a simple, unencrypted, TCP connection. Please set up a more advanced environment by using SSH if you have to cross the Internet or another untrusted network.<br /> <br /> In the master computer, you have to specify now to use ''pump distcc'' as your compiler. The most obvious way to use it for ns-3 is the following:<br /> <br /> &lt;pre&gt;<br /> $ CXX=&quot;pump distcc g++&quot; ./waf --your-options<br /> &lt;/pre&gt;<br /> <br /> But before doing so, let test if distcc generally works for you by creating a file named &quot;test.cc&quot; that contains the following:<br /> <br /> &lt;pre&gt;<br /> int main ()<br /> {<br /> return 0;<br /> }<br /> &lt;/pre&gt;<br /> <br /> In the slave let's see what is happening by doing:<br /> <br /> &lt;pre&gt;<br /> $ tail -f /tmp/distccd.log<br /> &lt;/pre&gt;<br /> <br /> and then running the following:<br /> <br /> &lt;pre&gt;<br /> $ pump distcc gcc -c test.cc test.o<br /> &lt;/pre&gt;<br /> <br /> <br /> You should see that the slave receives the compilation and compile successfully the file. The most important line is at the end:<br /> <br /> &lt;pre&gt;<br /> distccd[686] (dcc_check_client) connection from 10.1.16.52:60284<br /> distccd[686] (check_address_inet) match client 0x3410010a, value 0x3410010a, mask 0xffffffff<br /> distccd[686] (dcc_r_token_int) got DIST00000002<br /> distccd[686] (dcc_r_token_int) got ARGC00000005<br /> [cut.....]<br /> distccd[686] job complete<br /> distccd[686] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files<br /> distccd[686] (dcc_job_summary) client: 10.1.16.52:60284 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:61ms gcc asd.c<br /> &lt;/pre&gt;<br /> <br /> If you see COMPILE_OK, then you are good: distcc and distccd are properly configured, and you can try to use it with ns-3:<br /> <br /> &lt;pre&gt;<br /> $ CXX=&quot;pump distcc g++&quot; ./waf --your-options<br /> $ ./waf -j8042 # 8042 concurrent processes is my dream<br /> &lt;/pre&gt;<br /> <br /> === Linux: Setup ccache ===</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=HOWTO_use_distcc_and_ccache&diff=11400 2018-11-14T16:40:55Z

<p>Natale: </p> <hr /> <div><br /> == How to use distcc and ccache for speed up building time ==<br /> <br /> Ns-3 has a lot of files to compile. With the expected growth of different branches and repositories, time spent in compiling is affecting the development time in a considerable way. At the end of this HOWTO, you will be able to store the intermediate result of a compilation (the object files) and to distribute new compilation unit (i.e., when the cached object file does not exist or it has to be updated). You could also selectively disable one (or both) options just by switching an environment variable.<br /> <br /> === Linux: setup distcc ===<br /> <br /> distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network to speed up the building time. It should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile. Use your favorite package manager to install the distcc package.<br /> <br /> In the following, we will use the term ''master'' to indicate the computer which initiates the compilation and which contains the source copy of ns-3, while we will use the term ''slave'' to indicate a computer which accepts compilation requests sent by the master. First of all, in the slaves, follow your distribution guide to setup a working distcc server. For instance, for Archlinux (that is the most easy distribution you can find out there -- forget all the complexity of Ubuntu, multiple package versions, libraries, -dev, and everything that could make you hate the Linux ecosystem) you can refer to [https://wiki.archlinux.org/index.php/Distcc]. Basically, the /etc/conf.d/distcc should look like:<br /> <br /> &lt;pre&gt;<br /> #<br /> # Parameters to be passed to distccd<br /> #<br /> # You must explicitly add IPs (or subnets) that are allowed to connect,<br /> # using the --allow switch. See the distccd manpage for more info.<br /> #<br /> <br /> DISTCC_ARGS=&quot;--allow MASTER_IP --log-level debug --log-file /tmp/distccd.log&quot;<br /> &lt;/pre&gt;<br /> <br /> Then, in the master, install the distcc package without running the server. Then, configure it (following your distribution howto) to have the slave ip in the DISTCC_HOST configuration variable. For instance, for Archlinux, this is easy as having a file /etc/distcc/host with the following content:<br /> <br /> &lt;pre&gt;<br /> # --- /etc/distcc/hosts -----------------------<br /> # See the &quot;Hosts Specification&quot; section of<br /> # &quot;man distcc&quot; for the format of this file.<br /> #<br /> # By default, just test that it works in loopback mode.<br /> #127.0.0.1<br /> SLAVE_IP,lzo,cpp<br /> &lt;/pre&gt;<br /> <br /> Just replace the SLAVE_IP with the IP address of the slave. Please note that this configuration is '''insecure''' because sources and objects are traveling the network with a simple, unencrypted, TCP connection. Please set up a more advanced environment by using SSH if you have to cross the Internet or another untrusted network.<br /> <br /> In the master computer, you have to specify now to use ''pump distcc'' as your compiler. The most obvious way to use it for ns-3 is the following:<br /> <br /> &lt;pre&gt;<br /> $ CXX=&quot;pump distcc g++&quot; ./waf --your-options<br /> &lt;/pre&gt;<br /> <br /> But before doing so, let test if distcc generally works for you by creating a file named &quot;test.cc&quot; that contains the following:<br /> <br /> &lt;pre&gt;<br /> int main ()<br /> {<br /> return 0;<br /> }<br /> &lt;/pre&gt;<br /> <br /> In the slave let's see what is happening by doing <br /> <br /> &lt;pre&gt;<br /> $ tail -f /tmp/distccd.log<br /> &lt;/pre&gt;<br /> <br /> and then running the following:<br /> <br /> &lt;pre&gt;<br /> $ pump distcc gcc -c test.cc test.o<br /> &lt;/pre&gt;<br /> <br /> <br /> You should see that the slave receives the compilation and compile successfully the file. The most important line is at the end:<br /> <br /> &lt;pre&gt;<br /> distccd[686] (dcc_check_client) connection from 10.1.16.52:60284<br /> distccd[686] (check_address_inet) match client 0x3410010a, value 0x3410010a, mask 0xffffffff<br /> distccd[686] (dcc_r_token_int) got DIST00000002<br /> distccd[686] (dcc_r_token_int) got ARGC00000005<br /> [cut.....]<br /> distccd[686] job complete<br /> distccd[686] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files<br /> distccd[686] (dcc_job_summary) client: 10.1.16.52:60284 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:61ms gcc asd.c<br /> &lt;/pre&gt;<br /> <br /> If you see COMPILE_OK, then you are good: distcc and distccd are properly configured, and you can try to use it with ns-3:<br /> <br /> &lt;pre&gt;<br /> $ CXX=&quot;pump distcc g++&quot; ./waf --your-options<br /> $ ./waf -j8042 # 8042 concurrent processes is my dream<br /> &lt;/pre&gt;<br /> <br /> === Linux: Setup ccache ====</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=HOWTO_use_distcc_and_ccache&diff=11399 2018-11-14T14:24:07Z

<p>Natale: Created page with &quot; == How to use distcc and ccache for speed up building time == Ns-3 has a lot of files to compile. With the expected growth of different branches and repositories, time spent...&quot;</p> <hr /> <div><br /> == How to use distcc and ccache for speed up building time ==<br /> <br /> Ns-3 has a lot of files to compile. With the expected growth of different branches and repositories, time spent in compiling is affecting the development time in a considerable way. At the end of this HOWTO, you will be able to store the intermediate result of a compilation (the object files) and to distribute new compilation unit (i.e., when the cached object file does not exist or it has to be updated). You could also selectively disable one (or both) options just by switching an environment variable.<br /> <br /> === Linux: setup distcc ===<br /> <br /> distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network to speed up the building time. It should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile. Use your favorite package manager to install the distcc package.<br /> <br /> In the following, we will use the term ''master'' to indicate the computer which initiates the compilation and which contains the source copy of ns-3, while we will use the term ''slave'' to indicate a computer which accepts compilation requests sent by the master. First of all, in the slaves, follow your distribution guide to setup a working distcc server. For instance, for Archlinux (that is the most easy distribution you can find out there -- forget all the complexity of Ubuntu, multiple package versions, libraries, -dev, and everything that could make you hate the Linux ecosystem) you can refer to [https://wiki.archlinux.org/index.php/Distcc]. Basically, the /etc/conf.d/distcc should look like:<br /> <br /> &lt;pre&gt;<br /> #<br /> # Parameters to be passed to distccd<br /> #<br /> # You must explicitly add IPs (or subnets) that are allowed to connect,<br /> # using the --allow switch. See the distccd manpage for more info.<br /> #<br /> <br /> DISTCC_ARGS=&quot;--allow MASTER_IP --log-level debug --log-file /tmp/distccd.log&quot;<br /> &lt;/pre&gt;<br /> <br /> Then, in the master, install the distcc package without running the server. Then, configure it (following your distribution howto) to have the slave ip in the DISTCC_HOST configuration variable. For instance, for Archlinux, this is easy as having a file /etc/distcc/host with the following content:<br /> <br /> &lt;pre&gt;<br /> # --- /etc/distcc/hosts -----------------------<br /> # See the &quot;Hosts Specification&quot; section of<br /> # &quot;man distcc&quot; for the format of this file.<br /> #<br /> # By default, just test that it works in loopback mode.<br /> #127.0.0.1<br /> SLAVE_IP,lzo,cpp<br /> &lt;/pre&gt;<br /> <br /> Just replace the SLAVE_IP with the IP address of the slave. Please note that this configuration is '''insecure''' because sources and objects are traveling the network with a simple, unencrypted, TCP connection. Please set up a more advanced environment by using SSH if you have to cross the Internet or another untrusted network.<br /> <br /> In the master computer, you have to specify now to use ''pump distcc'' as your compiler. The most obvious way is the following:<br /> <br /> &lt;pre&gt;<br /> $ CXX=&quot;pump distcc&quot; ./waf --your-options<br /> &lt;/pre&gt;<br /> <br /> Let test it by creating a file named &quot;test.cc&quot; that contains the following:<br /> <br /> &lt;pre&gt;<br /> int main ()<br /> {<br /> return 0;<br /> }<br /> &lt;/pre&gt;<br /> <br /> In the slave let's see what is happening by doing <br /> <br /> &lt;pre&gt;<br /> $ tail -f /tmp/distccd.log<br /> &lt;/pre&gt;<br /> <br /> and then running the following:<br /> <br /> &lt;pre&gt;<br /> $ pump distcc gcc -c test.cc test.o<br /> &lt;/pre&gt;<br /> <br /> <br /> You should see that the slave receives the compilation and compile successfully the file. The most important line is at the end:<br /> <br /> &lt;pre&gt;<br /> distccd[686] (dcc_check_client) connection from 10.1.16.52:60284<br /> distccd[686] (check_address_inet) match client 0x3410010a, value 0x3410010a, mask 0xffffffff<br /> distccd[686] (dcc_r_token_int) got DIST00000002<br /> distccd[686] (dcc_r_token_int) got ARGC00000005<br /> [cut.....]<br /> distccd[686] job complete<br /> distccd[686] (dcc_cleanup_tempfiles_inner) deleted 5 temporary files<br /> distccd[686] (dcc_job_summary) client: 10.1.16.52:60284 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:61ms gcc asd.c<br /> &lt;/pre&gt;<br /> <br /> === Linux: Setup ccache ====</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Git_Migration&diff=10975 2018-04-27T07:47:13Z

<p>Natale: </p> <hr /> <div>= Git Migration =<br /> This page recap all the open questions for the migration to the git tool for managing source code and their answers.<br /> <br /> We all agree on the fact that a giant, important step like this requires coordination, and the feedback/contribution of many people as possible, especially current maintainers. We do not want to worse their life quality, as they are the concrete walls on which ns-3 bases its life. The process of updating the source code management system will be split into different sequential phases. Each phase will be used as input for the next stage.<br /> <br /> '''Phase 1 - 30 April - 14 May''': ''Definition of questions to be answered: '' Each ns-3 users can put questions on this page that he/she would like to have it answered. The problems can have multiple points. Users can add points to each item.<br /> <br /> '''Phase 2 - 15 May - 09 June''': ''Answering of questions: '' Each developer starts answering the questions (even not his/her own) with his/her proposal. Each proposal can be refined, discussed on the mailing list, and so on.<br /> <br /> '''Phase 3 - 10 June - 17 June''': ''Live talks in wns3: '' In this week the proposal can be discussed live.<br /> <br /> '''Phase 4 - 18 June - 20 June''': ''Voting: '' If there are questions with conflicting proposals, the current maintainers will have a vote on what plan should be implemented.<br /> <br /> '''Phase 5 - 21 June - 1 July''' ''- Implementation:'' The maintainers will start migrate the source code. At the end of the phase, the community will give comments.<br /> <br /> '''Phase 5 - 1 July - 15 July''' ''- Implementation:'' Discussion, Integration, and Iteration until the final release<br /> <br /> = Phase 1 (until 14 May) =<br /> <br /> Each ns-3 user is free to add questions that he/she would like to have answered. The objective is to have a coherent set of stakeholder interests, as well as a set of design rules that take into considerations these interests. The reality is that we have a different way of working, and it is difficult to have something that is good enough for everyone. In this way, I hope to catch early enough all the doubts and the driving decision in the design process.<br /> <br /> # (nat) Should we move some modules to move to contrib?<br /> # (nat) What modules should we move to contrib?<br /> # (nat) Define how the contrib/ modules will be fetched and compiled<br /> # (nat) Define the service we will use (GitHub, GitLab, BitBucket)<br /> # (nat) Define the official branches (stable releases, development)<br /> # (nat) Define how the versions are managed and released<br /> # (nat) Define a workflow for integrating patches:<br /> ## (nat) stable fixes (fixes that are for an already shipped version)<br /> ## (nat) development fixes/features (fixes and features for master branch)<br /> # (nat) Define the accepted code review models<br /> # (nat) Define the permissions of each user inside the projects (should everyone have r/w access to the repo?)<br /> <br /> ''' Add your question by prefixing your (recognizable) name.''' The questions can be reordered, and subtopic inserted until 14 May. <br /> <br /> = Phase 2 =<br /> Each question of phase 1 will be answered.<br /> <br /> = Phase 3 =<br /> Live talk at wns3<br /> <br /> = Phase 4 =<br /> Voting on conflicting proposals<br /> <br /> = Phase 5 =<br /> Implementation<br /> <br /> = Phase 6 =<br /> Discussion, Integration, and Iteration</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Git_Migration&diff=10974 2018-04-26T20:08:56Z

<p>Natale: </p> <hr /> <div>= Git Migration =<br /> This page recap all the open questions for the migration to the git tool for managing source code and their answers.<br /> <br /> We all agree on the fact that a giant, important step like this requires coordination, and the feedback/contribution of many people as possible, especially current maintainers. We do not want to worse their life quality, as they are the concrete walls on which ns-3 bases its life. The process of updating the source code management system will be split into different sequential phases. Each phase will be used as input for the next stage.<br /> <br /> '''Phase 1 - 30 April - 14 May''': ''Definition of questions to be answered: '' Each ns-3 users can put questions on this page that he/she would like to have it answered. The problems can have multiple points. Users can add points to each item.<br /> <br /> '''Phase 2 - 15 May - 09 June''': ''Answering of questions: '' Each developer starts answering the questions (even not his/her own) with his/her proposal. Each proposal can be refined, discussed on the mailing list, and so on.<br /> <br /> '''Phase 3 - 10 June - 17 June''': ''Live talks in wns3: '' In this week the proposal can be discussed live.<br /> <br /> '''Phase 4 - 18 June - 20 June''': ''Voting: '' If there are questions with conflicting proposals, the current maintainers will have a vote on what plan should be implemented.<br /> <br /> '''Phase 5 - 21 June - 1 July''' ''- Implementation:'' The maintainers will start migrate the source code.<br /> <br /> = Phase 1 =<br /> <br /> Each ns-3 user is free to add questions that he/she would like to have answered. The objective is to have a coherent set of stakeholder interests, as well as a set of design rules that take into considerations these interests. The reality is that we have a different way of working, and it is difficult to have something that is good enough for everyone. In this way, I hope to catch early enough all the doubts and the driving decision in the design process.<br /> <br /> # (nat) Should we move some modules to move to contrib?<br /> # (nat) What modules should we move to contrib?<br /> # (nat) Define how the contrib/ modules will be fetched and compiled<br /> # (nat) Define the service we will use (GitHub, GitLab, BitBucket)<br /> # (nat) Define the official branches (stable releases, development)<br /> # (nat) Define how the versions are managed and released<br /> # (nat) Define a workflow for integrating patches:<br /> ## (nat) stable fixes (fixes that are for an already shipped version)<br /> ## (nat) development fixes/features (fixes and features for master branch)<br /> # (nat) Define the accepted code review models<br /> # (nat) Define the permissions of each user inside the projects (should everyone have r/w access to the repo?)<br /> <br /> ''' Add your question by prefixing your (recognizable) name.''' The questions can be reordered, and subtopic inserted until 14 May. <br /> <br /> = Phase 2 =<br /> Each question of phase 1 will be answered.<br /> <br /> = Phase 3 =<br /> Live talk at wns3<br /> <br /> = Phase 4 =<br /> Voting on conflicting proposals<br /> <br /> = Phase 5 =<br /> Implementation</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Git_Migration&diff=10973 2018-04-26T19:42:18Z

<p>Natale: </p> <hr /> <div>= Git Migration =<br /> This page recap all the open questions for the migration to the git tool for managing source code.<br /> <br /> We all agree on the fact that a giant, important step like this requires coordination, and the feedback/contribution of many people as possible, especially current maintainers. We do not want to worse their life quality, as they are the concrete walls on which ns-3 bases its life. The process of updating the source code management system will be split into different sequential phases. Each phase will be used as input for the next phase.<br /> <br /> '''Phase 1 - 30 April - 14 May''': ''Definition of questions to be answered: '' Each ns-3 users can put questions on this page that he/she would like to have it answered. The questions can have multiple points. Users can add points to each question.<br /> <br /> '''Phase 2 - 15 May - 09 June''': ''Answering of questions: '' Each developer starts answering the questions (even not his/her own) with his/her proposal. Each proposal can be refined, discussed on the mailing list, and so on.<br /> <br /> '''Phase 3 - 10 June - 17 June''': ''Live talks in wns3: '' In this week the proposal can be discussed live.<br /> <br /> '''Phase 4 - 18 June - 20 June''': ''Voting: '' If there are questions with conflicting proposals, the current maintainers will have a vote on what proposal should be implemented.<br /> <br /> '''Phase 5 - 21 June - 1 July''' ''- Implementation:'' The maintainers will start migrate the source code.<br /> <br /> <br /> == Questions for phase 1 ==<br /> <br /> # (nat) Should we move some modules to move to contrib?<br /> # (nat) What modules should we move to contrib?<br /> # (nat) Define the service we will use (GitHub, GitLab, BitBucket)<br /> # (nat) Define the official branches (stable releases, development) and how the versions are managed<br /> # (nat) Define a workflow for stable fixes, and development fixes/features<br /> # (nat) Define the accepted code review models<br /> # (nat) Define the permissions of the user inside the projects<br /> # (nat) Define how the contrib/ modules will be fetched and compiled<br /> <br /> ''' Add your own question by prefixing your (recognizable) name'''<br /> <br /> == Phase 2 ==<br /> == Phase 3 ==<br /> == Phase 4 ==<br /> == Phase 5 ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Git_Migration&diff=10972 2018-04-26T16:12:35Z

<p>Natale: Created page with &quot;= Git Migration = This page recap all the open questions for the migration to the git tool for managing source code. We all agree on the fact that a giant, important step lik...&quot;</p> <hr /> <div>= Git Migration =<br /> This page recap all the open questions for the migration to the git tool for managing source code.<br /> <br /> We all agree on the fact that a giant, important step like this requires coordination, and the feedback/contribution of many people as possible, especially current maintainers. We do not want to worse their life quality, as they are the concrete walls on which ns-3 bases its life. The process of updating the source code management system will be split into different sequential phases.<br /> <br /> '''Phase 1 - 30 April - 14 May''': ''Definition of questions to be answered: '' Each ns-3 users can put questions on this page that he/she would like to have it answered. The questions can have multiple points. Users can add points to each question.<br /> <br /> '''Phase 2 - 15 May - 09 June''': ''Answering of questions ''<br /> <br /> '''Phase 3 - 10 June - 17 June''': ''Live talks in wns3 ''<br /> <br /> '''Phase 4 - 18 June - ...''': ''Implementations ''<br /> <br /> <br /> == Questions for phase 1 ==<br /> <br /> # Should we move some modules to move to contrib?<br /> # What modules should we move?<br /> # Define the service we will use (GitHub, GitLab, BitBucket)<br /> # Define the official branches (stable releases, development) and how the versions are managed<br /> # Define a workflow for stable fixes, and development fixes/features<br /> # Define the accepted code review models<br /> # Define the permissions of the user inside the projects<br /> # Define how the contrib/ modules will be fetched and compiled<br /> <br /> <br /> TO be continued</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2018Projects&diff=10921 2018-03-07T19:52:52Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> * [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br /> * [[GSOC2018StudentGuide |ns-3's 2018 GSoC Student guide]]<br /> * [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]<br /> * [[GSOC2018StudentApplicationTemplate |2018 GSoC Student application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Student Selection Process]]<br /> * ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br /> <br /> == ns-3's GSoC 2018 ==<br /> <br /> This webpage highlights project ideas for ns-3's Google Summer of Code 2018 effort. <br /> <br /> The thirteen week coding period for projects runs from 14 May to 14 August, 2018. The full project timeline is here: https://developers.google.com/open-source/gsoc/timeline<br /> <br /> '''Important note:''' ns-3 is applying to Google Summer of Code as a project but will not learn about acceptance until February 12.<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.<br /> <br /> Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10, 2012-15, and 2017.<br /> <br /> Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge.<br /> <br /> === Students: how to participate ===<br /> <br /> For students interested in applying to ns-3 for GSOC, first wait to see if ns-3 will be selected. If so, then go through the following list to get started:<br /> * Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br /> * Read [[GSOC2017StudentGuide |ns-3's GSoC Student guide]].<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [http://www.nsnam.org/ns-3-26/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br /> * Look through the [[GSOC2017StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br /> * Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br /> * In parallel, make sure you prepare a patch as per the [[GSOC2017PatchRequirement | Patch Requirement Guidelines]] (to be revised). Your application to ns-3 will not be considered if you do not fulfill this requirement.<br /> <br /> Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2018. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.<br /> &lt;/blockquote&gt;<br /> <br /> === Mentors: how to participate ===<br /> <br /> The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:<br /> <br /> * The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.<br /> * The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.<br /> * There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to students:''' These ideas are not listed in any priority order. The list of mentors for 2018: Tom Henderson, Tommaso Pecorella, Mohit Tahiliani, Dizhi Zhou, Matthieu Coudron, and Natale Patriciello.<br /> <br /> ==== Usability improvements ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], Dizhi Zhou, others TBD<br /> <br /> Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some project examples:<br /> * Tools and scripts to conduct and manage data from a large number of simulation runs<br /> * How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]<br /> * Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&amp;rep=rep1&amp;type=pdf Yavista]<br /> <br /> ==== LTE and Wi-Fi Coexistence ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Since 2016, the License-Assisted Access (LAA) variant of LTE has been a popular [https://www.nsnam.org/wiki/LAA-WiFi-Coexistence off-tree repository], but this fork has never been merged to ns-3-dev and has fallen behind. In addition, features beyond the Release 13 LAA (such as Release 14 eLAA) are desired. The main focus of this project would be to work with the LTE and Wi-Fi maintainers to integrate the LAA-based changes to those repositories, and to move the laa-wifi-coexistence module to a released 'app' on the new [http://apps.nsnam.org ns-3 App Store]. A similar job of porting [http://www.cttc.es/spidercloud-and-cttc-model-lte-u-performance-advancements/ LTE-U CSAT models] to ns-3-dev is also of interest.<br /> <br /> * ''Required Experience:''C++, LTE and Wi-Fi understanding<br /> * ''Interests:'' wireless networking and coexistence<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' the code found in the above, and this [http://arxiv.org/abs/1604.06826 arXiv paper]<br /> <br /> ==== Wi-Fi mesh module upgrade ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).<br /> <br /> * ''Required Experience:''C++, Wi-Fi and mesh understanding<br /> * ''Interests:'' mesh networking<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' mesh issues in the [https://www.nsnam.org/bugzilla/buglist.cgi?component=mesh&amp;product=ns-3&amp;query_format=advanced&amp;resolution=--- tracker], and the mesh module documentation, and IEEE 802.11 standard<br /> <br /> ==== Direct Code Execution upgrade ====<br /> <br /> Mentor: [mailto:mattator@gmail.com Matthieu Coudron]<br /> <br /> ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&amp;content=&amp;no_redirect=1&amp;order=Importance&amp;product=dce&amp;query_format=specific open DCE issues in our tracker], for starters.<br /> * ''Required Experience:'' good hacking skills on Linux, C, C++, Python<br /> * ''Difficulty:'' Hard.<br /> * ''For more information:'' https://www.nsnam.org/overview/projects/direct-code-execution/dce-1-9/<br /> <br /> ==== Freshen ns-3/Click integration ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010. We seek a student interested in the following tasks: <br /> <br /> * Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.<br /> ** Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.<br /> * There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here: https://codereview.appspot.com/4890044/<br /> ** The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).<br /> * Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.<br /> <br /> The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' IPv4, IPv6, Click.<br /> * ''Interests:'' Software integration.<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== User-friendly internet-apps ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, &quot;Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file &lt;filename.txt&gt;&quot;, or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.). <br /> <br /> * ''Required Experience:''C++<br /> * ''Interests:'' Network performance management<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> <br /> ==== nam upgrade and support for ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> [http://www.isi.edu/nsnam/nam/ nam] is a Tcl/Tk-based animator for ns-2. Some example videos are found at [https://www.youtube.com/results?search_query=nam+network+animator YouTube]. nam has been functionally replaced in many ways by [https://www.nsnam.org/wiki/NetAnim NetAnim], but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos. <br /> <br /> * ''Required Experience:''C++, Tcl/Tk also preferred<br /> * ''Interests:'' Network visualization/animation<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** the links listed above<br /> <br /> ==== ns-2 ports to ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> [http://www.isi.edu/nsnam/ns/ ns-2] is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.<br /> <br /> * ''Required Experience:''C++, ns-2 also preferred<br /> * ''Difficulty:'' Low to medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== TCP testing and alignment ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** Similar FreeBSD test suite: https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionTestSuite<br /> ** https://wiki.linuxfoundation.org/networking/tcp_testing<br /> <br /> ==== TCP analysis ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as [http://research.protocollabs.com/captcp/ captcp], [http://www.wireshark.org Wireshark TCP analysis], [http://www.tcptrace.org/ tcptrace], [http://tstat.polito.it/ Tstat], or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.<br /> <br /> As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies &quot;10.0.0.1:*&quot; and &quot;192.168.0.1:80&quot;, and if there are three connections in the simulation from 10.0.0.1 to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== 802.15.4 Bootstrap ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.<br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== 802.15.4 Beacon-enabled mode ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module. <br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium/hard<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== DSR routing RFC compliance ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.<br /> The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.<br /> A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.<br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' DSR standard<br /> * ''Interests:'' Ad-hoc routing<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]<br /> <br /> ==== Implementation of AccECN and ECN++ in ns-3 ====<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> Reducing Internet Transport Latency is an interesting research topic and has gained significant attention in the recent past. Some of the promising new solutions rely on Explicit Congestion Notification (ECN) (RFC 3168) to notify TCP endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. As a result, there have been attempts at Internet Engineering Task Force (IETF) to extend the functionality of ECN and provide rich feedback to TCP endpoints. In this regard, Accurate ECN feedback (AccECN) and ECN++ are two active topics of discussion at IETF. This project proposal is to: extend the ECN implementation in ns-3 to support AccECN and ECN++, test the correctness of implementation and provide examples.<br /> <br /> * ''Required Experience:'' Familiarity with TCP congestion control algorithms, ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with ECN implementation in ns-3<br /> * ''Interests:'' TCP performance enhancements and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html TCP models in ns-3]<br /> ** [https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-05 More Accurate ECN Feedback in TCP]<br /> ** [https://tools.ietf.org/id/draft-ietf-tcpm-generalized-ecn-02.html ECN++: Adding ECN to TCP Control Packets]<br /> <br /> ==== Enable IPv6 support for Ad hoc Routing Protocols in ns-3 ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> ns-3 contains models for proactive (DSDV and OLSR) and reactive (AODV and DSR) ad hoc routing protocols. However, these models are IPv4-only and do not provide support of IPv6 addressing. This project aims to enable IPv6 support for ad hoc routing protocols in ns-3, mainly for AODV and DSR. There are out-of-tree implementations of OLSR and DSDV that provide support for IPv6 addressing, and can be used as references to get started with this project.<br /> An important point of the implementation should be code duplicate minimization, in order to have the minimize maintenance efforts.<br /> Note: Enabling IPv6 support for these protocols is not a matter of simply changing out an IPv4-formatted address for an IPv6-formatted address. The IPv6 addressing architecture emphasizes scoping much more than does IPv4 (RFC 4007). Please suggest in your application how IPv6 address configuration (and possibly auto-configuration?) and address scopes (e.g. link-local vs. global) should be used in these protocols. Consulting the RFCs is highly recommended.'<br /> <br /> * ''Required Experience:'' Fundamentals of IPv6 addressing, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with AODV and DSR implementations in ns-3<br /> * ''Interests:'' Ad hoc routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/ipv6.html IPv6 model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/aodv.html AODV model in ns-3]<br /> ** [https://www.nsnam.org/docs/models/html/dsr.html DSR model in ns-3]<br /> ** [https://www.nsnam.org/workshops/wns3-2016/posters/IPv6-support-for-OLSR.pdf IPv6 Support for OLSR in ns-3]<br /> <br /> ==== Trust-based routing protocols framework ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> ns-3 contains different routing modules, both for IPv4 and for IPv6. None of them is trust-based.<br /> Given the increasing interest on trust-based routing schemes to increase and improve the network resilience Vs routing attacks, it would be useful to have a general approach for Trust-based schemes. As a matter of fact, there are multiple trust-based extensions for well known protocold (e.g., AODV), but each one modifies in a particular way the single routing protocol, making it difficult to export the solution to other routing schemes.<br /> On the opposite, it would be extremely useful to have an architectural approach where the next hop trust calculation is independent from the actual routing protocol or communication scheme, and the protocol(s) can use the next hop trust independently from the actual scheme used to calculate the trust value.<br /> This should allow a greater flexibility in studying differet trust evaluation schemes and their effect on different routing policies.<br /> The project aims at defining and develop a Trust-based framework, at least one (or more) trust evluation methods, and apply them to at least one (or more) routing protocols.<br /> <br /> * ''Required Experience:'' Familiarity with Trust-based routing protocols, C++ programming.<br /> * ''Bonus Experience:'' Familiarity with ns-3 routing protocols<br /> * ''Interests:'' Trust-based routing<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/internet-models.html Internet model in ns-3]<br /> ** [https://pdfs.semanticscholar.org/db82/e98f454331469deec32aeff566882898ef01.pdf C. Zhang, X. Zhu, Y. Song and Y. Fang, &quot;A Formal Study of Trust-Based Routing in Wireless Ad Hoc Networks,&quot; 2010 Proceedings IEEE INFOCOM, San Diego, CA, 2010, pp. 1-9. doi: 10.1109/INFCOM.2010.5462116]<br /> <br /> ==== Data collection and statistics framework extension ====<br /> <br /> Mentors: [mailto:dizhizhou@hotmail.com Dizhi Zhou]<br /> <br /> The goal of this project is to extend and add more functionalities on ns-3 data collection and statistics framework (source code:ns-3.27/src/stats/) which was added in ns-3.18. The model was implemented based on the ns-3 tracing system. It has two major functions. 1) retrieve data from multiple ns-3 trace sources and then recalculate/transform the data into a user-defined format. However, not all the trace source types are supported. 2) use a data collector to calculate some useful statistics from a ns-3 trace source (e.g. max and min of the trace value). However, only supports counter and min/max data collectors are supported today. In order to make the model more useful, more trace source types, output formats and collectors need to be added.<br /> <br /> A parallel project of ns-3, named sns3, proposed an enhancement on this model in 2016. But the patch was not merged to the official release yet. Student may use this patch as a reference for their proposals. Some sample ideas are listed below.<br /> * ''Help to merge sns3 statistic enhancement to ns-3. <br /> * ''Add more trace types<br /> * ''Add more collectors. Ideally, the statistic calculation method should be configurable in the script so that people don’t need to add new collectors when they have any new requirement.<br /> * ''More output format types: excel, MySql, matplotlib, R, Matlab, more picture formats, etc.<br /> * ''Improve documentation and add more example scripts.<br /> <br /> The list is not exhaustive and not limiting. Any new ideas in this area are welcome.<br /> * ''Required Experience:'' C++ programming.<br /> * ''Bonus Experience:'' Proficiency with open source data handling software (e.g. R, matplotlib, SQLite, gnuplot)<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/documentation/ Data collection and trace chapters in ns-3 tutorial/manual/model library]<br /> ** [https://codereview.appspot.com/318800043/ Statistic model enhancement code review from sns3 project]<br /> <br /> ==== Persistent and Semi-Persistent Scheduling inside LTE module ====<br /> <br /> Mentors: [mailto:natale.patriciello@gmail.com Natale Patriciello], [mailto:sandra.lagen@cttc.cat Sandra Lagen]<br /> <br /> The goal of this project is to implement Semi-Persistent Scheduling (SPS) scheme in the ns-3 LTE module. SPS scheme is enabled in 4G LTE, as well as in 5G, in order to save L1/L2 (layer 1/layer 2) control signaling and reduce resource overhead for some periodic and predictable traffic, such as voice over IP (VoIP) and traffic from sensors/IoT devices. Currently, in ns-3 LTE, only Dynamic Scheduling (DS) scheme is implemented, for which the scheduling decisions are dynamically signaled on L1/L2 control to indicate the allocated resources. Differently, in SPS, only the first scheduling assignment is signaled on L1/L2, and the subsequent transmissions use the same resources with a preconfigured interval, thus reducing L1/L2 overhead. In particular, SPS periodicity is configured by RRC, and then activation is signaled through the downlink control information (DCI), both for downlink and uplink SPS. The idea of this project is to extend RRC parameters, and DCI formats, to enable SPS scheme, and to update the MAC scheduler (L2) to enable both SPS and DS schemes for different traffic simultaneously. The later requires, among others, a memory in the scheduler, so as not to allocate resources for DS that are already scheduled for SPS.<br /> <br /> * ''Required Experience:'' C++, LTE understanding<br /> * ''Bonus Experience:'' Familiarity with lte module<br /> * ''Interests:'' LTE scheduling (MAC layer)<br /> * ''Difficulty:'' Medium.<br /> <br /> [[Category:GSoC]]</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2018Projects&diff=10885 2018-01-29T09:06:13Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> * [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page GSoC Frequently Asked Questions]<br /> * [[GSOC2017StudentGuide |ns-3's 2017 GSoC Student guide]]<br /> * [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide (not ns-3 specific)]<br /> * [[GSOC2017StudentApplicationTemplate |2017 GSoC Student application template]]<br /> * [[GSOCMentorGuide | ns-3's GSoC Mentor guide]]<br /> * [http://en.flossmanuals.net/gsoc-mentoring/ GSoC Mentor guide (not ns-3 specific)]<br /> * [[GSOCSelectionProcess | GSoC Student Selection Process]]<br /> * ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] | ''chat'' https://ns-3.zulipchat.com/<br /> <br /> == ns-3's GSoC 2018 ==<br /> <br /> This webpage highlights project ideas for ns-3's Google Summer of Code 2018 effort. <br /> <br /> The thirteen week coding period for projects runs from 14 May to 14 August, 2018. The full project timeline is here: https://developers.google.com/open-source/gsoc/timeline<br /> <br /> '''Important note:''' ns-3 is applying to Google Summer of Code as a project but will not learn about acceptance until February 12.<br /> <br /> === About the ns-3 project ===<br /> <br /> ns-3 is a discrete-event network simulator, with a particular emphasis on network research and education.<br /> <br /> Users of ns-3 can construct simulations of computer networks using models of traffic generators, protocols such as TCP/IP, and devices and channels such as WiFi, and analyze or visualize the results. Simulation plays a vital role in the research and education process, because of the ability for simulations to obtain reproducible results (particularly for wireless protocol design), scale to large networks, and study systems that have not yet been implemented. A particular emphasis in ns-3 is the high degree of realism in the models (including frameworks for real application and kernel code) and integration of the tool with virtual machine environments and testbeds; we view that researchers need to move more effortlessly between simulation, testbeds, and live experiments, and ns-3 is designed to facilitate that.<br /> <br /> Our GSoC organizational admin is [mailto:tomhend@u.washington.edu Tom Henderson] and our backup org admin is [mailto:tpecorella@mac.com Tommaso Pecorella]. The project has participated in past GSoCs during 2008-10, 2012-15, and 2017.<br /> <br /> Mentors will be paired with students based on the projects that are selected. Mentors from companies are welcome, if the employer will permit the mentor sufficient time to perform the mentoring. Prospective mentors should notify Tom Henderson or Tommaso Pecorella of interest. Mentors familiar with ns-3 development practices will be preferred, to improve the chances of student code merge.<br /> <br /> === Students: how to participate ===<br /> <br /> For students interested in applying to ns-3 for GSOC, first wait to see if ns-3 will be selected. If so, then go through the following list to get started:<br /> * Read the official [http://en.flossmanuals.net/GSoCStudentGuide/ GSoC student guide].<br /> * Read [[GSOC2017StudentGuide |ns-3's GSoC Student guide]].<br /> * Look through our [[#Project Ideas]] below to see if you find a project that interests you.<br /> * Review the [http://www.nsnam.org/ns-3-26/documentation/ns-3 tutorial] thoroughly, if you have not already done so.<br /> * Look through the [[GSOC2017StudentApplicationTemplate |GSoC Student application template]] to start preparing your proposal.<br /> * Next, proceed to get in touch with the developers on the mailing list and refine your proposal.<br /> * In parallel, make sure you prepare a patch as per the [[GSOC2017PatchRequirement | Patch Requirement Guidelines]] (to be revised). Your application to ns-3 will not be considered if you do not fulfill this requirement.<br /> <br /> Below is a list of [[#Project Ideas]] proposed by the ns-3 team for Google Summer of Code 2018. Please note that these ideas are not limited to GSoC; anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if you have a different idea that you'd like to work on, to see if a mentor may be interested. Applicants are encouraged to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Previous experience with the Google Summer of Code programmes suggest that the more you discuss and refine your proposal on the mailing list beforehand, the stronger the proposal it will develop into, and the higher your chances of being accepted into the programme.<br /> <br /> &lt;blockquote&gt;<br /> Each project idea within a particular priority has been tagged with the following properties:<br /> * ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.<br /> * ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.<br /> * ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.<br /> * ''Difficulty:'' easy, medium or difficult<br /> * ''Recommended reading:'' pointers to documentation, papers, specific bugs, etc.<br /> <br /> Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.<br /> &lt;/blockquote&gt;<br /> <br /> === Mentors: how to participate ===<br /> <br /> The ns-3 project is open to the proposal of new project ideas by developers interested in being a GSoC mentor. For mentors who're adding project ideas to the list below, please ensure that:<br /> <br /> * The projects are sized such that there can be a code merge by the end of the coding period. The scope of the project should be such that it is very difficult to not have a code merge by the end of the summer.<br /> * The proposed projects are not too open-ended. That is, if the deliverables or a clear path to the same are not well understood, it is better kept outside GSOC.<br /> * There should be a clear merge path to one of the main project code repositories (ns-3-dev, ns-3-dce, bake) by the end of the summer, either because the patches directly apply to these repositories, or because they apply to an ns-3 module that is in the process of being merged with ns-3-dev.<br /> <br /> == Project Ideas ==<br /> <br /> '''Note to students:''' These ideas are not listed in any priority order. The list of mentors for 2018: Tom Henderson, Tommaso Pecorella, Mohit Tahiliani, Dizhi Zhou, Matthieu Coudron, and Natale Patriciello.<br /> <br /> ==== Usability improvements ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], Dizhi Zhou, others TBD<br /> <br /> Usability of ns-3 can always be improved, whether it is help with building simulations, running simulation campaigns, using the ns-3 C++ API, improving the Python user experience, visualizing simulations or data, software packaging (e.g. binary packages or Docker containers), or documentation. This project is for a student who has been using ns-3 for a while and has ideas on how to make it better during GSoC. We don't want to limit the scope of proposals here; we will consider any project ideas that improve ns-3 usability in some way (please explain to us why the usability improvement is important to users beyond yourself, and why you would argue for your particular solution, and of course describe how you plan to get it done during the timeframe of GSoC). Some project examples:<br /> * Tools and scripts to conduct and manage data from a large number of simulation runs<br /> * How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]<br /> * Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&amp;rep=rep1&amp;type=pdf Yavista]<br /> <br /> ==== LTE and Wi-Fi Coexistence ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Since 2016, the License-Assisted Access (LAA) variant of LTE has been a popular [https://www.nsnam.org/wiki/LAA-WiFi-Coexistence off-tree repository], but this fork has never been merged to ns-3-dev and has fallen behind. In addition, features beyond the Release 13 LAA (such as Release 14 eLAA) are desired. The main focus of this project would be to work with the LTE and Wi-Fi maintainers to integrate the LAA-based changes to those repositories, and to move the laa-wifi-coexistence module to a released 'app' on the new [http://apps.nsnam.org ns-3 App Store]. A similar job of porting [http://www.cttc.es/spidercloud-and-cttc-model-lte-u-performance-advancements/ LTE-U CSAT models] to ns-3-dev is also of interest.<br /> <br /> * ''Required Experience:''C++, LTE and Wi-Fi understanding<br /> * ''Interests:'' wireless networking and coexistence<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' the code found in the above, and this [http://arxiv.org/abs/1604.06826 arXiv paper]<br /> <br /> ==== Wi-Fi mesh module upgrade ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 Wi-Fi mesh module was written about 8 years ago, and is not completely up to date with the standard, nor does it work with newer Wi-Fi variants (802.11n/ac/ax). This project would prioritize making mesh module compatible with all variants of Wi-Fi and would align with the latest standard. Going further, some scenarios and scripts that align ns-3 simulations with how community networks are set up and configured would be helpful, such as guidance on how to configure rate controls and routing protocols (e.g. how to run OLSR on top of mesh).<br /> <br /> * ''Required Experience:''C++, Wi-Fi and mesh understanding<br /> * ''Interests:'' mesh networking<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:'' mesh issues in the [https://www.nsnam.org/bugzilla/buglist.cgi?component=mesh&amp;product=ns-3&amp;query_format=advanced&amp;resolution=--- tracker], and the mesh module documentation, and IEEE 802.11 standard<br /> <br /> ==== Direct Code Execution upgrade ====<br /> <br /> Mentor: [mailto:mattator@gmail.com Matthieu Coudron]<br /> <br /> ns-3 has an extension known as Direct Code Execution, which allows users to build C or C++-based applications, and open source (Linux, FreeBSD) kernels, into ns-3. However, support for the latest kernels (e.g. Linux kernel 4 series) and latest gcc versions has languished. We also could better integrate DCE with the main ns-3 tree. This project seeks a student interested in DCE, improving usability, and making it current with latest kernels and toolchains. The payoff of this type of project is very high since DCE makes available a lot of real-world models for use in ns-3. If you select this project idea, please engage with us on the developers list, and consider to take a look at solving one of the [https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&amp;content=&amp;no_redirect=1&amp;order=Importance&amp;product=dce&amp;query_format=specific open DCE issues in our tracker], for starters.<br /> * ''Required Experience:'' good hacking skills on Linux, C, C++, Python<br /> * ''Difficulty:'' Hard.<br /> * ''For more information:'' https://www.nsnam.org/overview/projects/direct-code-execution/dce-1-9/<br /> <br /> ==== Freshen ns-3/Click integration ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> ns-3 and [https://github.com/kohler/click Click modular routing] were first integrated in an [https://www.nsnam.org/wiki/GSOC2010Click ns-3 GSoC project] from 2010. We seek a student interested in the following tasks: <br /> <br /> * Since 2010, Ipv4L3Protocol has continued to evolve, but Ipv4L3ClickProtocol has not kept pace with the changes. Also, IPv6 is not supported. Refactor Ipv4L3Protocol and Ipv4L3ClickProtocol (or delete Ipv4L3ClickProtocol altogether) so that the click-specific pieces are limited and can be maintained more easily.<br /> ** Current thoughts on this are that we would like to modify the approach. It would be nice for Click to run on ns-3 in a manner that is as close as possible to its working outside simulation (raw sockets + tun/tap devices). This will hopefully allow us to delete IPv4L3ClickProtocol and avoid needed ns-3 code to expect Click to provide a routing table. ns-3 traffic generators should then be able to send packets to an ns-3 equivalent of a tun/tap device (which doesn't presently exist), have packets show up in Click, and then get Click to push those packets directly to an interface using raw sockets from inside ns-3.<br /> * There was an [https://www.nsnam.org/wiki/NSOC2011ClickMac/MidTermReport ns-3 2011 summer project] (not part of GSoC, but a follow-on project) to try to finish the integration with ClickMac. We'd like to update it, finish it off, and merge it with ns-3-dev. Some brief discussion was here: https://codereview.appspot.com/4890044/<br /> ** The blocking issue at the time was in the Wi-Fi module; the changes in radiotap and frame injection over monitor mode, which Click needed, were not finished (accepted).<br /> * Anything else that a student thinks would be useful to support regarding click and ns-3 integration. Consider to review in the recent literature (see Google Scholar) how Click is now being used for research, and think about then what might be research-driven priorities for support in ns-3. Provide evidence (citations) in your application.<br /> <br /> The list is not exhaustive and not limiting. I.e., the candidate can propose other points and/or concentrate on a specific subset.<br /> <br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' IPv4, IPv6, Click.<br /> * ''Interests:'' Software integration.<br /> * ''Difficulty:'' Medium.<br /> <br /> ==== User-friendly internet-apps ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Ping is a ubiquitous application for reachability and latency measurements. ns-3 already has a ping model (the v4ping.cc and ping6.cc). However, a user-friendly API could still be added. It is not straightforward to configure an ns-3 program to do in a single statement, for example, &quot;Ping the IP address W.X.Y.Z from node 0 between times 5 and 50 seconds in my program, and save the output in traditional format to the file &lt;filename.txt&gt;&quot;, or to configure the many options found in the ping man page. This project is therefore not about developing brand new features as much as it is about making ping super-easy to use with a great API. Have a look at how ns-3 programs are written, and tell us what kind of API makes sense to you, and why, and how you would go about prioritizing its implementation. If ping is solved very early, the project can follow the same pattern for one or two more applications (e.g. netperf, iperf, etc.). <br /> <br /> * ''Required Experience:''C++<br /> * ''Interests:'' Network performance management<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> <br /> ==== nam upgrade and support for ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> [http://www.isi.edu/nsnam/nam/ nam] is a Tcl/Tk-based animator for ns-2. Some example videos are found at [https://www.youtube.com/results?search_query=nam+network+animator YouTube]. nam has been functionally replaced in many ways by [https://www.nsnam.org/wiki/NetAnim NetAnim], but it still has some attractive features and might make a complementary animation tool for ns-3. In fact, someone did a proof-of-concept support of nam for ns-3 many years ago: http://www.nsnam.org/contributed/ns-3-nam.tar.bz2. This project would involve upgrading nam support to the latest Tcl/Tk release series (8.6) and then using the existing ns-3 trace system to generate nam output files such as in ns-2, and documenting and testing the results, including some demonstration videos. <br /> <br /> * ''Required Experience:''C++, Tcl/Tk also preferred<br /> * ''Interests:'' Network visualization/animation<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** the links listed above<br /> <br /> ==== ns-2 ports to ns-3 ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> [http://www.isi.edu/nsnam/ns/ ns-2] is the predecessor to ns-3, but some popular models still exist in ns-2 and are not yet ported to ns-3. Google Scholar can be used to find topics for which people still are publishing papers using ns-2. This project idea is for someone who is fond of some feature or model found in ns-2 but not in ns-3. A successful application of this type will make a good case that the port is still relevant to network research, that people are using ns-2 due to this model, and will describe the technical approach that is planned to make the port (e.g. how OTcl default variables will be ported to ns-3). Please note that the networking relevance is very important part of the application; if you propose to port some feature of ns-2 that is dated or unlikely to be of much interest because its applicability is very narrow, your proposal will not be selected.<br /> <br /> * ''Required Experience:''C++, ns-2 also preferred<br /> * ''Difficulty:'' Low to medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== TCP testing and alignment ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> ns-3 needs good TCP models that align with real implementations, or that have documented differences. In particular, does ns-3 TCP's slow start and congestion avoidace perform like a real implementation, including common variants found in the field (CUBIC, DCTCP), and ones under development (TCP Prague, BBR). The project should also produce regression tests. We envision that this project will consist of setting up ns-3 in emulation mode to test operation of its implementation against real implementations, in different impairment environments, documenting the results, and figuring out how to take the ns-3 results and generate regression tests.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** Similar FreeBSD test suite: https://wiki.freebsd.org/SummerOfCode2016/TCP-IP-RegressionTestSuite<br /> ** https://wiki.linuxfoundation.org/networking/tcp_testing<br /> <br /> ==== TCP analysis ====<br /> <br /> Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> This project is not about developing new TCP variants, but about developing a TCP analysis capability that is user-friendly and produces output similar to (perhaps integrates with?) tools such as [http://research.protocollabs.com/captcp/ captcp], [http://www.wireshark.org Wireshark TCP analysis], [http://www.tcptrace.org/ tcptrace], [http://tstat.polito.it/ Tstat], or other similar tools. An important part of your application will be a description of how a user will enable it in a user program, and some description of how it will be implemented.<br /> <br /> As an example, consider providing the user with the ability to auto-generate plots of throughput evolution, congestion window evolution, etc. over time, for a pair of 4-tuples where the 4-tuples may contain wild cards or regular expressions. For instance, the user specifies &quot;10.0.0.1:*&quot; and &quot;192.168.0.1:80&quot;, and if there are three connections in the simulation from 10.0.0.1 to that specific IP address and port, then three sets of time-series plots are generated and labelled appropriately.<br /> <br /> * ''Required Experience:''C++, TCP<br /> * ''Difficulty:'' Medium<br /> * ''Recommended reading:''<br /> ** ns-2 and ns-3 manuals<br /> <br /> ==== 802.15.4 Bootstrap ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. An useful extension is to fully support the node bootstrap phase, including node association and beacon request/reply. The goal of the project is to enhance the lr-wpan module so to use beacons in the bootstrap phase along with network scanning and pan-id resolution for in-range coordinators.<br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== 802.15.4 Beacon-enabled mode ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The lr-wpan model is an 802.15.4 PHY and MAC model currently in development. The model is able to simulate an 802.15.4 network in ad-hoc mode, much like Contiki-os nodes do. Unlike Contiki-os, the model could benefit from supporting beacon-enabled mode of operation. The beacon-enabled mode is a fully slotted transmission mode, with guaranteed slots and bound performances, unlike the ad-hoc mode. This is especially important because the L3 routing protocols might be strongly affected by the lower-layer topology. Hence it is of paramount importance to be able to simulate both in ns-3. The goal of the project is to develop the new beacon-enabled MAC layer for the lr-wpan module. <br /> * ''Required Experience:'' C++, WSN<br /> * ''Bonus Experience:'' 802.15.4 standard<br /> * ''Interests:'' WSN<br /> * ''Difficulty:'' medium/hard<br /> * ''Recommended reading:''<br /> ** [http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf 802.15.4 Standard]<br /> <br /> ==== DSR routing RFC compliance ====<br /> <br /> Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> The DSR routing module is not compliant with the RFC 4728. This leads to a number of small issues, like simulation imprecision and impossibility to decode the messages with Wireshark.<br /> The goal of the project is to enhance the current model and to make it RFC-compliant, eventually doing a code refectory where needed.<br /> A possible enhancement over the base protocol could also be to include support for IPv6 in the implementation.<br /> * ''Required Experience:'' C++<br /> * ''Bonus Experience:'' DSR standard<br /> * ''Interests:'' Ad-hoc routing<br /> * ''Difficulty:'' medium<br /> * ''Recommended reading:''<br /> ** [http://www6.ietf.org/rfc/rfc4728.txt RFC 4728]<br /> <br /> ==== Implementation of AccECN and ECN++ in ns-3 ====<br /> <br /> Mentors: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]<br /> <br /> Reducing Internet Transport Latency is an interesting research topic and has gained significant attention in the recent past. Some of the promising new solutions rely on Explicit Congestion Notification (ECN) (RFC 3168) to notify TCP endpoints of congestion that may be developing in a bottleneck queue, without resorting to packet drops. As a result, there have been attempts at Internet Engineering Task Force (IETF) to extend the functionality of ECN and provide rich feedback to TCP endpoints. In this regard, Accurate ECN feedback (AccECN) and ECN++ are two active topics of discussion at IETF. This project proposal is to: extend the ECN implementation in ns-3 to support AccECN and ECN++, test the correctness of implementation and provide examples.<br /> <br /> * ''Required Experience:'' Familiarity with TCP congestion control algorithms, ECN and C++ programming.<br /> * ''Bonus Experience:'' Familiarity with ECN implementation in ns-3<br /> * ''Interests:'' TCP performance enhancements and ECN.<br /> * ''Difficulty:'' Medium.<br /> * ''Recommended reading:''<br /> ** [https://www.nsnam.org/docs/models/html/tcp.html TCP models in ns-3]<br /> ** [https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-05 More Accurate ECN Feedback in TCP]<br /> ** [https://tools.ietf.org/id/draft-ietf-tcpm-generalized-ecn-02.html ECN++: Adding ECN to TCP Control Packets]<br /> <br /> [[Category:GSoC]]</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Project_Ideas&diff=10238 2016-11-24T08:35:54Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> One way to get involved with ns-3 is to work with a mentor on a suggested project. These are typically project suggestions that would be valued contributions but the proposer does not have enough time to do it himself or herself, but is willing to mentor someone else to do it.<br /> <br /> Another possibility for students is to get involved in the [http://code.google.com/soc/ Google Summer of Code] program. This program is administered by Google and acceptance is competitive.<br /> <br /> How does a mentored project work? You contact the mentor and describe your interests and availability to work on the module. You and the mentor will work out a plan to regularly review and discuss the development of your module, following the [https://www.nsnam.org/docs/manual/html/new-modules.html guidelines for developing new models for ns-3]. You will set up a public repository somewhere such as [http://mercurial.selenic.com/wiki/MercurialHosting a site listed here] or your own mercurial server. <br /> <br /> Not all projects are mentored, nor do they all need to be. Please suggest new project ideas on this page and whether you would mentor them.<br /> <br /> = Introductory projects =<br /> <br /> This project category is for smaller, simpler projects for new developers to get started. If you would like to work on one of these, please coordinate with the named mentor.<br /> <br /> == tcp-echo example and relative tutorial section ==<br /> <br /> '''Mentor''': [mailto:natale.patriciello@gmail.com Natale]<br /> <br /> References:<br /> * https://www.nsnam.org/bugzilla/show_bug.cgi?id=454<br /> <br /> From the bug report: Pretty much every introduction to BSD sockets ever written uses a TCP echo client server pair to start with. It then moves to a UDP echo client server pair to illustrate datagrams.<br /> <br /> We wrote the udp-echo.cc example when there was no TCP in the system. Now that we have some TCPs, it would be useful to make a tcp-echo.cc and associated applications. In our documentation, it would be very useful go through the same kind of tutorial as everyone else in the world, with a tcp echo walkthrough followed by a udp echo walkthrough.<br /> <br /> The code is already there, and it is perfect to be read and to be adapted to latest ns-3 by an interested student.<br /> <br /> == Sockets should support the setting of QoS ==<br /> <br /> '''Mentor''': [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> References: <br /> * http://groups.google.com/group/ns-3-users/browse_thread/thread/5be010835c4b5b71<br /> * https://www.nsnam.org/bugzilla/show_bug.cgi?id=1361<br /> <br /> == Reducing header dependencies ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Bug [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1832 1832] describes some software maintenance that could be performed on ns-3, to reduce unnecessary header dependencies. Patches are welcome for even a small part of the overall solution.<br /> <br /> I would suggest to adapt deheader and place it in utils/deheader.py. Running utils/deheader.py should list all the unnecessary includes, and let the maintainers decide whether they want to go clean these up.<br /> <br /> Daniel Camara performed this work already, but the work was not finished and merged. Bug 1832 has the details.<br /> <br /> References:<br /> * http://www.catb.org/~esr/deheader/<br /> * http://code.google.com/p/include-what-you-use/<br /> <br /> == Fixing Doxygen errors and warnings ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson], [mailto:rivanvx@gmail.com Vedran Miletic], or [mailto:pdbarnes@llnl.gov Peter Barnes]<br /> <br /> Bug [https://www.nsnam.org/bugzilla/show_bug.cgi?id=938 938] describes an overall effort to eliminate Doxygen warnings (primarily, for missing Doxygen) from our modules. Any patches that contribute to the overall goal would be welcome. Contact one of the mentors if interested.<br /> <br /> = Projects needing completion =<br /> <br /> Some projects were started in the past and never brought to completion.<br /> <br /> == Wifi rate control example ==<br /> <br /> ns-3 supports many different wifi rate controls, but there isn't a good example program that allows users to clearly contrast the performance of different ones. The example program 'examples/wireless/multirate.cc' does this a little bit, but it focuses on sampling the throughput.<br /> <br /> The suggested project is to work with improving multirate.cc so that users can clearly see the difference between selecting the different rate control algorithms, perhaps by running for longer amount of time and finding a way to plot the rate chosen by the control algorithm as a function of time.<br /> <br /> == Perfect ARP ==<br /> <br /> [https://www.nsnam.org/bugzilla/show_bug.cgi?id=187 Bug 187] has a patch that needs further review, updating to ns-3-dev, and finishing off. The enhancement is described as follows:<br /> <br /> We need an implementation of ARP which avoids the generation of ARP request/reply packets and assumes a 'perfect' ARP table is always available and up-to-date.<br /> <br /> == IPv6 Routing ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], <br /> <br /> There is little support for global (i.e. god) routing routing for IPv6. This was started in a 2011 ns-3 summer of code project.<br /> IPv6 can use Dynamic routing (RIPng is included in ns-3.20), but more protocols are welcome.<br /> <br /> However, global routing is still needed. Moreover, all the ad-hoc routing protocols are currently IPv4-only.<br /> <br /> == Refactor AODV Hello ==<br /> <br /> [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1188 Bug 1188] describes a problem with the current AODV implementation that Hellos are sent even without any active routes.<br /> <br /> We would like for someone to align our implementation with the AODV RFC (or with working implementations) in this regard. <br /> <br /> '''Mentor''': [mailto:nikkipui@gmail.com Daniel Lertpratchya]<br /> <br /> = Mentored projects =<br /> <br /> This section lists project ideas for which there is interest by an ns-3 developer or maintainer to serve as a mentor in the development of a new feature for ns-3.<br /> <br /> Please do not apply for mentoring help on a class project unless you have approval from the instructor to receive mentoring.<br /> <br /> == Decouple traffic generation from sockets ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> All ns-3 simulations are IP based but there is no template for how to do this for non-IP-based stacks. One issue that should be addressed in the long term is that applications that generate traffic are strongly coupled to the sockets interface. It would be nice to decouple the traffic generation aspects of these applications from the sockets-related code.<br /> <br /> #* ''summary'': Proposed decoupling to generalize applications<br /> #* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html<br /> #* ''code location'': http://code.nsnam.org/laprisee/ns-3-mp/<br /> #* ''status'': Was under discussion in the summer.<br /> #:<br /> <br /> <br /> == SCTP (Stream Control Transmission Protocol) ==<br /> <br /> '''Mentor''': [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> [http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol SCTP] is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails.<br /> Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.<br /> * Required Experience: C++<br /> * Bonus Experience: L4 protocols understanding<br /> * Interests: L4 protocols modeling and simulation<br /> * Difficulty: medium<br /> * Recommended reading:<br /> ** [http://tools.ietf.org/html/rfc3286 RFC 3286] An Introduction to the Stream Control Transmission Protocol<br /> ** [http://tools.ietf.org/html/rfc6458 RFC 6458] Sockets API Extensions for the Stream Control Transmission Protocol<br /> ** all the relevant RFCs about SCTP<br /> <br /> = Feature requests =<br /> <br /> The following projects have been suggested in the past. If you are working on them, please let us know on the developers or users list so that we can coordinate activities. If you want to add a project, please describe it below.<br /> <br /> == Path MTU discovery ==<br /> <br /> When a L4 packet is passed to the IPv4 or IPv6 stacks, the MTU (i.e., the size of the outgoing IP packets) is usually set to the local interface MTU. Or so it is the popular belief. Using the local interface MTU might lead to IP-level fragmentation, more overhead, and poor network performance.+<br /> <br /> As a consequence, multiple techniques to discover the end-to-end MTU (called Path MTU) are available.<br /> The current PMTU discovery ns-3 capability status is listed below.<br /> <br /> === Path MTU discovery for IPv4 stacks ===<br /> <br /> '''Status:''' Being worked on by Vedran Miletic<br /> <br /> There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] implemented for IPv4. This makes guessing the end-to-end MTU imperative for ns-3 simulations. We would welcome a contribution that introduced path MTU discovery to ns-3. <br /> <br /> Vedran expressed interest in working on PMTU discovery.<br /> <br /> === Path MTU discovery for IPv6 stacks ===<br /> <br /> [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] is implemented in ns-3's IPv6 stack.<br /> <br /> === Packetization Layer Path MTU Discovery ===<br /> [http://tools.ietf.org/html/rfc4821 RFC 4821] describes a method to detect PMTU at packetization (i.e., L4) level. This is another good candidate to be implemented.<br /> <br /> === L4 compliance with PMTU ===<br /> Even if IPv6 is able to detect PMTU, and IPv4 could be, currently there is no API to probe for a specific PMTU from L4 (e.g., UDP, TCP, etc.).<br /> Moreover, TCP is blind with respect to PMTU. I.e., its MSS (Maximum Segment Size) is fixed.<br /> <br /> In order to reproduce real TCP performance it is of paramount importance to:<br /> <br /> # Define an API to be used by L4 protocols, for PMTU probing.<br /> # Update TCP to react to PMTU changes (dynamic MSS).<br /> # Update TCP to not decrement its Congestion Window upon losses due to PMTU discovery (especially important for IPv6).<br /> <br /> == DSR RFC compliance ==<br /> <br /> '''Note:''' As of June 2015, Gaurangi Saxena is working on this (see: http://mailman.isi.edu/pipermail/ns-developers/2015-June/012842.html).<br /> <br /> The ns-3 DSR implementation is not following strictly the [http://datatracker.ietf.org/doc/rfc4728/ RFC 4728]. The topic has been briefly discussed in [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1895 bug# 1895].<br /> <br /> It would be nice to have a switch to change from the current behaviour to the &quot;RFC-strict&quot; behaviour.<br /> As a byproduct, DSR could be updated to support IPv6. Although not explicitly stated by the rFC, DSR can be used for IPv6 as well.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Project_Ideas&diff=10237 2016-11-24T08:35:07Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> One way to get involved with ns-3 is to work with a mentor on a suggested project. These are typically project suggestions that would be valued contributions but the proposer does not have enough time to do it himself or herself, but is willing to mentor someone else to do it.<br /> <br /> Another possibility for students is to get involved in the [http://code.google.com/soc/ Google Summer of Code] program. This program is administered by Google and acceptance is competitive.<br /> <br /> How does a mentored project work? You contact the mentor and describe your interests and availability to work on the module. You and the mentor will work out a plan to regularly review and discuss the development of your module, following the [https://www.nsnam.org/docs/manual/html/new-modules.html guidelines for developing new models for ns-3]. You will set up a public repository somewhere such as [http://mercurial.selenic.com/wiki/MercurialHosting a site listed here] or your own mercurial server. <br /> <br /> Not all projects are mentored, nor do they all need to be. Please suggest new project ideas on this page and whether you would mentor them.<br /> <br /> = Introductory projects =<br /> <br /> This project category is for smaller, simpler projects for new developers to get started. If you would like to work on one of these, please coordinate with the named mentor.<br /> <br /> == tcp-echo example and relative tutorial section ==<br /> <br /> '''Mentor''': [mailto:natale.patriciello@gmail.com Natale]<br /> <br /> References:<br /> * https://www.nsnam.org/bugzilla/show_bug.cgi?id=454<br /> <br /> From the bug report: Pretty much every introduction to BSD sockets ever written uses a TCP echo client server pair to start with. It then moves to a UDP echo client server pair to illustrate datagrams.<br /> <br /> We wrote the udp-echo.cc example when there was no TCP in the system. Now that we have some TCPs, it would be useful to make a tcp-echo.cc and associated applications. In our documentation, it would be very useful go through the same kind of tutorial as everyone else in the world, with a tcp echo walkthrough followed by a udp echo walkthrough.<br /> <br /> The code is already there, and it would be wonderful to read and to adapt to latest ns-3 by an interested student.<br /> <br /> == Sockets should support the setting of QoS ==<br /> <br /> '''Mentor''': [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> References: <br /> * http://groups.google.com/group/ns-3-users/browse_thread/thread/5be010835c4b5b71<br /> * https://www.nsnam.org/bugzilla/show_bug.cgi?id=1361<br /> <br /> == Reducing header dependencies ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> Bug [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1832 1832] describes some software maintenance that could be performed on ns-3, to reduce unnecessary header dependencies. Patches are welcome for even a small part of the overall solution.<br /> <br /> I would suggest to adapt deheader and place it in utils/deheader.py. Running utils/deheader.py should list all the unnecessary includes, and let the maintainers decide whether they want to go clean these up.<br /> <br /> Daniel Camara performed this work already, but the work was not finished and merged. Bug 1832 has the details.<br /> <br /> References:<br /> * http://www.catb.org/~esr/deheader/<br /> * http://code.google.com/p/include-what-you-use/<br /> <br /> == Fixing Doxygen errors and warnings ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson], [mailto:rivanvx@gmail.com Vedran Miletic], or [mailto:pdbarnes@llnl.gov Peter Barnes]<br /> <br /> Bug [https://www.nsnam.org/bugzilla/show_bug.cgi?id=938 938] describes an overall effort to eliminate Doxygen warnings (primarily, for missing Doxygen) from our modules. Any patches that contribute to the overall goal would be welcome. Contact one of the mentors if interested.<br /> <br /> = Projects needing completion =<br /> <br /> Some projects were started in the past and never brought to completion.<br /> <br /> == Wifi rate control example ==<br /> <br /> ns-3 supports many different wifi rate controls, but there isn't a good example program that allows users to clearly contrast the performance of different ones. The example program 'examples/wireless/multirate.cc' does this a little bit, but it focuses on sampling the throughput.<br /> <br /> The suggested project is to work with improving multirate.cc so that users can clearly see the difference between selecting the different rate control algorithms, perhaps by running for longer amount of time and finding a way to plot the rate chosen by the control algorithm as a function of time.<br /> <br /> == Perfect ARP ==<br /> <br /> [https://www.nsnam.org/bugzilla/show_bug.cgi?id=187 Bug 187] has a patch that needs further review, updating to ns-3-dev, and finishing off. The enhancement is described as follows:<br /> <br /> We need an implementation of ARP which avoids the generation of ARP request/reply packets and assumes a 'perfect' ARP table is always available and up-to-date.<br /> <br /> == IPv6 Routing ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], <br /> <br /> There is little support for global (i.e. god) routing routing for IPv6. This was started in a 2011 ns-3 summer of code project.<br /> IPv6 can use Dynamic routing (RIPng is included in ns-3.20), but more protocols are welcome.<br /> <br /> However, global routing is still needed. Moreover, all the ad-hoc routing protocols are currently IPv4-only.<br /> <br /> == Refactor AODV Hello ==<br /> <br /> [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1188 Bug 1188] describes a problem with the current AODV implementation that Hellos are sent even without any active routes.<br /> <br /> We would like for someone to align our implementation with the AODV RFC (or with working implementations) in this regard. <br /> <br /> '''Mentor''': [mailto:nikkipui@gmail.com Daniel Lertpratchya]<br /> <br /> = Mentored projects =<br /> <br /> This section lists project ideas for which there is interest by an ns-3 developer or maintainer to serve as a mentor in the development of a new feature for ns-3.<br /> <br /> Please do not apply for mentoring help on a class project unless you have approval from the instructor to receive mentoring.<br /> <br /> == Decouple traffic generation from sockets ==<br /> <br /> '''Mentor''': [mailto:tomh@tomh.org Tom Henderson]<br /> <br /> All ns-3 simulations are IP based but there is no template for how to do this for non-IP-based stacks. One issue that should be addressed in the long term is that applications that generate traffic are strongly coupled to the sockets interface. It would be nice to decouple the traffic generation aspects of these applications from the sockets-related code.<br /> <br /> #* ''summary'': Proposed decoupling to generalize applications<br /> #* ''ns-developers post'': http://mailman.isi.edu/pipermail/ns-developers/2007-July/003136.html<br /> #* ''code location'': http://code.nsnam.org/laprisee/ns-3-mp/<br /> #* ''status'': Was under discussion in the summer.<br /> #:<br /> <br /> <br /> == SCTP (Stream Control Transmission Protocol) ==<br /> <br /> '''Mentor''': [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> [http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol SCTP] is a message-based L4 protocol with features similar to both TCP and UDP. It was originally developed as a reliable protocol to transport PSTN control streams, and it's currently used to carry 3G and 4G signaling over IP networks. The use of SCTP, however, is not limited to signaling transport, as its features makes it very interesting for a lot of other applications where UDP or TCP fails.<br /> Currently there is no SCTP implementation for ns-3. An SCTP implementation would have to comply with the IPv4 and IPv6 layers and have programming APIs toward the application layer similar to the ones defined in the available SCTP implementations for Linux.<br /> * Required Experience: C++<br /> * Bonus Experience: L4 protocols understanding<br /> * Interests: L4 protocols modeling and simulation<br /> * Difficulty: medium<br /> * Recommended reading:<br /> ** [http://tools.ietf.org/html/rfc3286 RFC 3286] An Introduction to the Stream Control Transmission Protocol<br /> ** [http://tools.ietf.org/html/rfc6458 RFC 6458] Sockets API Extensions for the Stream Control Transmission Protocol<br /> ** all the relevant RFCs about SCTP<br /> <br /> = Feature requests =<br /> <br /> The following projects have been suggested in the past. If you are working on them, please let us know on the developers or users list so that we can coordinate activities. If you want to add a project, please describe it below.<br /> <br /> == Path MTU discovery ==<br /> <br /> When a L4 packet is passed to the IPv4 or IPv6 stacks, the MTU (i.e., the size of the outgoing IP packets) is usually set to the local interface MTU. Or so it is the popular belief. Using the local interface MTU might lead to IP-level fragmentation, more overhead, and poor network performance.+<br /> <br /> As a consequence, multiple techniques to discover the end-to-end MTU (called Path MTU) are available.<br /> The current PMTU discovery ns-3 capability status is listed below.<br /> <br /> === Path MTU discovery for IPv4 stacks ===<br /> <br /> '''Status:''' Being worked on by Vedran Miletic<br /> <br /> There is no [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] implemented for IPv4. This makes guessing the end-to-end MTU imperative for ns-3 simulations. We would welcome a contribution that introduced path MTU discovery to ns-3. <br /> <br /> Vedran expressed interest in working on PMTU discovery.<br /> <br /> === Path MTU discovery for IPv6 stacks ===<br /> <br /> [http://en.wikipedia.org/wiki/Path_MTU_discovery path MTU discovery] is implemented in ns-3's IPv6 stack.<br /> <br /> === Packetization Layer Path MTU Discovery ===<br /> [http://tools.ietf.org/html/rfc4821 RFC 4821] describes a method to detect PMTU at packetization (i.e., L4) level. This is another good candidate to be implemented.<br /> <br /> === L4 compliance with PMTU ===<br /> Even if IPv6 is able to detect PMTU, and IPv4 could be, currently there is no API to probe for a specific PMTU from L4 (e.g., UDP, TCP, etc.).<br /> Moreover, TCP is blind with respect to PMTU. I.e., its MSS (Maximum Segment Size) is fixed.<br /> <br /> In order to reproduce real TCP performance it is of paramount importance to:<br /> <br /> # Define an API to be used by L4 protocols, for PMTU probing.<br /> # Update TCP to react to PMTU changes (dynamic MSS).<br /> # Update TCP to not decrement its Congestion Window upon losses due to PMTU discovery (especially important for IPv6).<br /> <br /> == DSR RFC compliance ==<br /> <br /> '''Note:''' As of June 2015, Gaurangi Saxena is working on this (see: http://mailman.isi.edu/pipermail/ns-developers/2015-June/012842.html).<br /> <br /> The ns-3 DSR implementation is not following strictly the [http://datatracker.ietf.org/doc/rfc4728/ RFC 4728]. The topic has been briefly discussed in [https://www.nsnam.org/bugzilla/show_bug.cgi?id=1895 bug# 1895].<br /> <br /> It would be nice to have a switch to change from the current behaviour to the &quot;RFC-strict&quot; behaviour.<br /> As a byproduct, DSR could be updated to support IPv6. Although not explicitly stated by the rFC, DSR can be used for IPv6 as well.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Ns-3.26&diff=10025 2016-06-20T13:24:04Z

<p>Natale: Tcp models update</p> <hr /> <div>{{TOC}}<br /> <br /> This page summarizes the release planning for ns-3.26 (planned for June 2016; rescheduled to early July 2016). The ns-3 release process is listed [http://www.nsnam.org/developers/release-process/ here] and [[Release Process | here]].<br /> <br /> = Release goals =<br /> <br /> The following goals have been identified by maintainers.<br /> <br /> == Build system ==<br /> <br /> * Upgrade Waf and bake build systems according to [[BakeIntegration | this functional specification for supporting contributed code]]<br /> <br /> == ns-3 core ==<br /> <br /> For ns-3.26, only maintenance on core (dealing with bug reports/open issues) is planned.<br /> <br /> Tom Henderson would like to finish off:<br /> * Attribute/TraceSource deprecation (bugs 2149 and 2344)<br /> * refactor chi-squared tests for random number generation (bug 1927)<br /> * Matt's test.py contributions (bug 2291)<br /> * bug 2086 on attribute accessibility<br /> * bug 1962 on random variable stream GetStream() returning -1<br /> * &lt;s&gt;bug 1939 on aggregating same object to two nodes&lt;/s&gt; Merged<br /> * bug 1604 on Config::GetDefault<br /> <br /> Peter Barnes intends to continue working on:<br /> * Bug 938 - missing Doxygen in ns-3<br /> * Bug 1764 - can't compile without pthread<br /> * Bug 1972 - CommandLine duplicate argument handling<br /> <br /> == network module ==<br /> <br /> There are a large number of patches pending on the Packet class and its friends; Tom H intends to work through them with Mathieu and with patch contributors.<br /> <br /> This proposal was made recently on ns-developers:<br /> <br /> * &lt;s&gt;we apply the patch in bug 2308 (LTE) if the LTE maintainers approve it&lt;/s&gt; Update: Manuel Requena is finalizing a new patch, now that the SocketAddressTag issue is resolved.<br /> * we apply the patch in bug 2069 (fix size of m_used variable)<br /> * we open a 'feature request/PATCH WANTED' for removal of ByteTags<br /> * we study the implications of the expansion of tag size recently (bug 2361) and either update documentation or change the code<br /> * we add a 'best current practice' note to the documentation, on tag usage, as suggested by Tommaso. (perhaps modifying this section:<br /> https://www.nsnam.org/docs/release/3.25/models/html/packets.html#adding-and-removing-tags) <br /> * consider Alex's proposal of some API changes to the tags class: https://www.nsnam.org/bugzilla/show_bug.cgi?id=1383<br /> * consider to finish patch for serializing/deserializing tags (bug 582)<br /> <br /> In addition, the following maintenance/bugs should be dealt with:<br /> <br /> * bug 2415: PacketMetadata Class Locks up Example<br /> * bug 2407: Packet Metadata bad state with small packet size<br /> * bug 2253: Alexander Krotov reported a bug: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2253<br /> * bug 2221: Packet tag size increased by 1 byte recently due to a Wi-Fi requirement; what should we do about this? is the previous 20 byte limit sacred?<br /> * bug 2198: proposed const addition<br /> * bug 2078: Tommaso found problems in metadata usage<br /> * bug 2102: another metadata bug reported<br /> * bug 1643: this has lingered with a patch for a while<br /> * bug 1535: this Packet::AddAtEnd() in TCP is still around; the TCP buffers still use this<br /> * bug 1407: packet header printing disabled<br /> <br /> == TCP models ==<br /> <br /> Natale Patriciello, Anh Nguyen, Tom Henderson, Matthieu Coudron, and Amir Modarresi are working on the following.<br /> <br /> 0) Already added.<br /> <br /> TCP BIC, Veno, Scalable, Vegas, YeAH, and Illinois have already been merged.<br /> <br /> 1) Open tracker issues<br /> <br /> * 2263: Support processing multiple TCP options in 1 header<br /> * 2122: decouple TcpTxBuffer variables<br /> * 2264: Possibility to setup Initial Sequence Number<br /> * 1529: randomize TCP initial sequence number<br /> * 2285: loss of TCP 3-way handshake calls receive callback to fire<br /> * 1167: TCP socket deferring CLOSE forever<br /> * 2133: In TCP close procedure, assert fail when receive in FIN_WAIT_2<br /> * 2278: in TcpSocketBase, need to advance NextTxSequence<br /> * 2256: TCPTxBuffer should be able to tell BytesInFlight<br /> * 2220: RAM usage reduction through reduction of retx events<br /> * 2214: TCP ScheduleNow for data transfer<br /> * 1783: experiencing drops during FastRec causes Tcp cw to blow up<br /> <br /> 2) Try to merge as many remaining TCP congestion control variants as are ready or nearly ready.<br /> * CUBIC<br /> * &lt;strike&gt;YeAH&lt;/strike&gt; (merged)<br /> * &lt;strike&gt;Illinois&lt;/strike&gt; (merged)<br /> * H-TCP: http://mailman.isi.edu/pipermail/ns-developers/2016-April/013541.html<br /> <br /> 3) work on SACK: &lt;s&gt;https://codereview.appspot.com/283880043/&lt;/s&gt; Updated in late May to this issue: https://codereview.appspot.com/299130043/<br /> * General Scoreboard<br /> * Tcp option SACK management<br /> * Tcp option SACK implementation<br /> <br /> MPTCP will not be merged for ns-3.26.<br /> <br /> == traffic-control module ==<br /> <br /> Stefano Avallone (stavallo@unina.it) is leading ns-3.26 development for traffic control, and has the following goals:<br /> <br /> * Add support for Byte Queue Limits (see bug 2428)<br /> * porting and polishing fq-codel (see bug 2430)<br /> * reviewing [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2261 PIE contribution] (in progress)<br /> * introduce mq (a multi-queue queue disc configured by default on wifi, along with fq-codel)<br /> * [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2241 user priorities and QoS API]<br /> * &lt;s&gt;provide a better solution for a couple of issues introduced by the requeue mechanism&lt;/s&gt; Merged<br /> <br /> == lte module ==<br /> <br /> No major changes planned for ns-3.26. Base support for LAA Wifi Coexistence module will be added (Biljana).<br /> <br /> With regard to two large patches previously proposed for code review, neither probably will make it to ns-3.26:<br /> * LTE RACH: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2300 (patch is very large-- Marco is reviewing)<br /> * Carrier Aggregation from Google Summer of Code 2015 (needs additional work)<br /> <br /> Tom and Tommaso will try to review and merge the IPv6 support:<br /> * https://www.nsnam.org/bugzilla/show_bug.cgi?id=2312<br /> <br /> === lte maintenance items ===<br /> <br /> &lt;s&gt;Manuel Ricardo plans to work on bug 2308 (how tags are used) in May.&lt;/s&gt; An updated patch is available in the tracker.<br /> <br /> Biljana will coordinate the remaining LTE bug responses on a best-effort basis:<br /> <br /> * 2339: PUSCH transmit power scaled incorrectly<br /> * 2282: Resources from UDP flows not realized<br /> * 2277: EpcTftClassifier::Classify blindly assumes L4 header<br /> * 2172: Out-of-bounds array access<br /> * 2161: Error in removing a bearer in epc-mme class<br /> * 2152: Uplink HARQ retransmissions out of synch at MAC layer<br /> * 2151: Redundancy version in uplink HARQ not generated properly<br /> * 2140: TraceFadingLossModel could use a wrong value<br /> * 2113: LTE RLC AM: all status reports indicate no more than one NACK<br /> * 2107: PCAP printing for S1U and X2<br /> * 2091: Race condition in LteUePhy::GenerateCqiRsrpRsrq<br /> * 2048: PfFfMacScheduler assigns dlinfo even if no resources available<br /> * 1861: Problem when send UDP packet size between 1473-1478 bytes<br /> * 1840: SINR-&gt;CQI-&gt;MCS conversion in the UL<br /> * 1515: REM shows increased SINR when co-located eNBs have same EARFCN<br /> * 1460: LTE-EPC/RPM different SINR values<br /> * 1438: lena-simple-epc with AM mode<br /> <br /> == wifi module ==<br /> <br /> Wifi continues to undergo significant development activity.<br /> <br /> Sebastien Deronne is working on these extensions:<br /> * [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2381 support for 802.11e TXOP]<br /> * extension of MPDU aggregation and block ack support (multi-tid, delayed response, …)<br /> <br /> Tom Henderson is working on these extensions:<br /> * SpectrumWifiPhy (bug 2400)<br /> * TOS setting so that Wi-Fi QoS can read it (also Stefano Avallone has a proposal)<br /> * support for selecting best beacon to associate with (also, channel roaming)<br /> * support for separate LAA Wifi Coexistence module<br /> <br /> Matias Richart is working on [https://codereview.appspot.com/254440043/ RRPAA rate control]<br /> <br /> ===wifi maintenance items===<br /> <br /> Tom Henderson would like to accomplish the following:<br /> * resolve bug 2369 on immediate access vs backoff<br /> * EDCA open bugs (2222, 2229)<br /> * allow mesh to run over 802.11n/ac <br /> <br /> current wifi issue list:<br /> https://www.nsnam.org/bugzilla/buglist.cgi?component=wifi&amp;product=ns-3&amp;query_format=advanced&amp;resolution=---<br /> <br /> == lr-wpan module ==<br /> <br /> Tommaso is aiming to get Vishwesh's code merged from GSOC 2015.<br /> <br /> Other than that, the following bugs are open:<br /> <br /> * 2088 SetMcpsDataIndicationCallback stops UDP data<br /> * 2033 IFS are not currently implemented<br /> * 1934 CCA interrupted by incoming packet<br /> * 1933 CCA mode should be configurable<br /> * 1924 sensing radius and CCA<br /> * 1879 LR-WPAN association primitive<br /> * 1809 lr-wpan features needed<br /> <br /> == internet module ==<br /> <br /> Tommaso is coordinating the below new feature work.<br /> * DHCP support: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2280<br /> * increased support for ARP/ND changes in bug 2145<br /> * Krishna's code from 2014 GSOC<br /> <br /> See also the proposal to add TOS byte:<br /> https://codereview.appspot.com/294280043/<br /> <br /> === maintenance issues for internet ===<br /> Some recent internet bugs:<br /> - 2209 ICMP message forwarding not based in incoming interface<br /> - 2180 is possible to register same route multiple times<br /> - 2102 global routing and bridging is reopened<br /> - 2064 UDP socket GetMtu() needed<br /> - 2057 ARP and NDISC caches should be updated by L4<br /> - 1984 expose additional random variables to configuration system<br /> <br /> bug 2057 is considered to be high priority<br /> <br /> == applications module ==<br /> <br /> For application module, we have a backlog of contributed code reviews related to new applications:<br /> <br /> - MPEG traffic generator<br /> - trace replay application<br /> - web browsing application<br /> <br /> and we also have these maintenance issues:<br /> <br /> - 2178 add Rx trace source to UdpEchoServer<br /> - 2111 add receiver timestamp to SeqTsHeader (we seem to have agreed to make a new header?)<br /> - 2106 add SetSocket API<br /> - 1977 v4ping verbose output when not explicitly stopped<br /> - 1899 add sequence number header (possibly related to 2111?) <br /> <br /> == uan module ==<br /> <br /> Federico Guerra plans to integrate [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2299 WOSS with the UAN module].<br /> <br /> Hossam Khader has also been active with patches and new proposals; see issues 2404, 2405, 2410, 2413.<br /> <br /> == other ==<br /> <br /> Chip Webb is working on improving support for Ethernet (full duplex links, switches and mixed L2/L3 networks)<br /> <br /> = Release and development schedule =<br /> <br /> The following schedule is planned (sliding about 5 weeks from original plan):<br /> <br /> * &lt;s&gt;May 11, 2016&lt;/s&gt; June 22: New feature deadline.<br /> * &lt;s&gt;May 25, 2016&lt;/s&gt; July 1: Planned code freeze date.<br /> * &lt;s&gt;June 1, 2016&lt;/s&gt; July 6: Scheduled release date for ns-3.26<br /> <br /> = Help wanted =<br /> <br /> If you would like to help prepare the ns-3.26 release in some way, please contact Tom Henderson (tomhend@u.washington.edu).<br /> <br /> Also, please check back at a later date as specific tasks may be listed here.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=HOWTO_use_Git_instead_of_Mercurial&diff=9944 2016-04-14T09:00:09Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> The ns-3 project presently uses Mercurial as its source code control system, but several developers favor using Git. Git is a VCS like Mercurial, Subversion or CVS, and it used to maintain many open-source (and closed-source) project. While git and mercurial have a lot of common properties, if you are new to git you should read first an introduction to it. The most up-to-date guite is the [https://git-scm.com/book/en/v2/Getting-Started-Git-Basics Git Book].<br /> <br /> Ns-3 project has set up a mirror on Github at https://github.com/nsnam/ns-3-dev-git.<br /> <br /> Please note that this repo does not accept [https://help.github.com/articles/using-pull-requests/ pull requests] at this time; to contribute back to the mainline code, use our bug tracker or Rietveld (see [https://www.nsnam.org/developers/contributing-code/ Contributing Code to ns-3]).<br /> <br /> This page provides common tips for people who wish to fork ns-3-dev from the nsnam github repo and keep a master sync'ed to the nsnam github repo.<br /> <br /> == Let's start our personal repository ==<br /> === Forking ns-3-dev ===<br /> <br /> Assume that you are user 'john' on github, and that you want to create a new public github repo that is synced to nsnam/ns-3-dev-git.<br /> <br /> #. Log into github<br /> #. Navigate to https://github.com/nsnam/ns-3-dev-git<br /> #. In the top-right corner of the page, click '''Fork'''. <br /> <br /> Note that you may only do this once; if you try to Fork again, github will take you to the page of the original fork. <br /> <br /> To create multiple forks from the same repository, see this blog page: https://adrianshort.org/create-multiple-forks-of-a-github-repo/<br /> <br /> For more information on forking at github: https://help.github.com/articles/fork-a-repo/<br /> <br /> &lt;!-- == Renaming your fork ==<br /> <br /> If you want to rename this repository, it is probably best to do it right after the initial fork. Let's say you wish to rename it 'ns-3-dev-wifi' to track your wifi modifications.<br /> <br /> #. Under your repository name, click Settings.<br /> #. Under the Repository Name heading, type the new name of your repository.<br /> #. Click Rename.<br /> --&gt;<br /> <br /> === Clone your repository on your working machine === <br /> <br /> Clone it locally to your system: <br /> <br /> git clone https://github.com/your-user-name/ns-3-dev-git<br /> cd ns-3-dev-git<br /> <br /> == Typical workflow ==<br /> <br /> Git is a distributed versioning system. This means that '''nobody''' will touch your personal repo, until you do something. Please note that every github user has, at least, two repositories: the first is represented by the repository hosted on github servers, which will be called in the following ''origin''. Then, you have your clone on your machine. This means that you could have many clones, on different machines, which refers to ''origin''.<br /> <br /> === Add the official ns-3 repository as remote upstream ===<br /> <br /> When you fork a repository, your history is no more bound to the repository itself. At this point, it is your duty to sync your fork with the original repository.<br /> Git is able to fetch and push changes to several repositories, each of them is called '''remote'''. The first remote repository we have encountered is ''origin''; we must add the official ns-3 repo as another remote repository.<br /> <br /> git remote add upstream https://github.com/nsnam/ns-3-dev-git<br /> <br /> With the command above, we added a remote repository, named upstream, which links to the official ns-3 repo. To show your remote repositories:<br /> <br /> git remote show<br /> <br /> To see to what ''origin'' is linking to:<br /> <br /> git remote show origin<br /> <br /> You can also delete remotes:<br /> <br /> git remote remove [name]<br /> <br /> Many options are available; please refer to the git manual for more.<br /> <br /> === Sync your repo === <br /> <br /> We assume, from now to the end of this document, that you will not make commits on top of the master branch. It should be kept clean from '''any''' personal modifications. Move the current HEAD to the master branch:<br /> <br /> git checkout master<br /> <br /> and fetch the changes from ''upstream'':<br /> <br /> git fetch upstream<br /> <br /> we can now merge the official changes into our master:<br /> <br /> git pull upstream master<br /> <br /> If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset (but this never happens if you do not commit over master).<br /> <br /> === Start a new branch ===<br /> <br /> Now look at the available branches:<br /> <br /> git branch -a<br /> <br /> you should see:<br /> <br /> * master<br /> remotes/origin/master<br /> remotes/upstream/master<br /> <br /> The branch master is your local master branch; remotes/origin/master point at the master branch on your repository located in the Github server, while remotes/upstream/master points to the official master branch.<br /> <br /> To create a new branch, which hopefully will contains new feature or bug correction, the command is<br /> <br /> git checkout -b [name_of_your_new_branch]<br /> <br /> To switch between branches, remove the -b option. You should now see:<br /> <br /> git branch -a<br /> <br /> * master<br /> [name_of_your_new_branch]<br /> remotes/origin/master<br /> remotes/upstream/master<br /> <br /> === Edit and commit the modifications ===<br /> <br /> After you edit some file, you should commit the difference. As a policy, git users love small and incremental patches. So, commit early, and commit often: you could rewrite your history later.<br /> <br /> Suppose we edited src/internet/model/tcp-socket-base.cc. With git status, we can see the repostory status:<br /> <br /> &lt;nowiki&gt;<br /> On branch tcp-next<br /> Your branch is up-to-date with 'mirror/tcp-next'.<br /> Changes not staged for commit:<br /> modified: src/internet/model/tcp-socket-base.cc<br /> &lt;/nowiki&gt;<br /> and we can see the edits with git diff:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git diff<br /> diff --git i/src/internet/model/tcp-socket-base.cc w/src/internet/model/tcp-socket-base.cc<br /> index 1bf0f69..e2298b0 100644<br /> --- i/src/internet/model/tcp-socket-base.cc<br /> +++ w/src/internet/model/tcp-socket-base.cc<br /> @@ -1439,6 +1439,10 @@ TcpSocketBase::ReceivedAck (Ptr&lt;Packet&gt; packet, const TcpHeader&amp; tcpHeader)<br /> // There is a DupAck<br /> ++m_dupAckCount;<br /> <br /> + // I'm introducing a subtle bug!<br /> +<br /> + m_tcb-&gt;m_cWnd = m_tcb-&gt;m_ssThresh;<br /> +<br /> if (m_tcb-&gt;m_congState == TcpSocketState::CA_OPEN)<br /> {<br /> // From Open we go Disorder<br /> &lt;/nowiki&gt;<br /> <br /> To create a commit, select the file you want to add to the commit with git add:<br /> <br /> git add src/internet/model/tcp-socket-base.cc<br /> <br /> and then commit the result:<br /> <br /> git commit -m &quot;My new TCP broken&quot;<br /> <br /> You can see the history of the commits with git log. To show a particular commit, copy the sha id and use git show &lt;sha-id&gt; .<br /> Do this until you feature or bug is corrected; now, it is time to make a review request.<br /> <br /> === Rebase your branch on master ===<br /> <br /> Meanwhile you were busy with your branch, the upstream master could have changed. To rebase your work with the now new master, first of all sync your master branch as explained before; then<br /> <br /> git checkout [name_of_your_new_branch]<br /> git rebase master<br /> <br /> this will rewind your work, update the HEAD of your branch to the actual master, and then re-apply all your work. If some of your work conflicts with the actual master, you will be asked to fix these conflicts if automatic merge fails.<br /> <br /> === Creating a patch against master ===<br /> <br /> If you are in a branch and want to diff it against master, you can type:<br /> <br /> git diff master<br /> <br /> and redirect to a patch:<br /> <br /> git diff master &gt; patch-against-master.patch<br /> <br /> To preserve all your commits, it is preferable to create many patches, one for each commit:<br /> <br /> git format-patch master<br /> <br /> and then you could submit them for a review.<br /> <br /> === Rewrite your history ===<br /> <br /> Let's suppose that, after a first round of review, you are asked to fix something. After you commited the fix of your (previously bad) commit, the log should be something like:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git log<br /> Sun Jan 17 14:43:36 2016 +0100 9cfa78e (HEAD -&gt; tcp-next) Fix for the previous [Tony Spinner]<br /> Sun Jan 17 14:43:16 2016 +0100 77ad6e1 first version of TCP broken [Tony Spinner]<br /> Mon Jan 11 14:44:13 2016 -0800 e2fc90a (origin/master, upstream/master, master) update some stale tutorial info [Someone]<br /> Mon Jan 11 21:11:54 2016 +0100 1df9c0d Bug 2257 - Ipv[4,6]InterfaceContainer::Add are not consistent [Someone]<br /> &lt;/nowiki&gt;<br /> <br /> If you plan to resubmit a review, you would like to merge the commits (original and its fix). You can easily do this with git rebase -i (--interactive).<br /> <br /> git rebase -i master<br /> <br /> and an editor should pop up, with your commits, and various possibilities:<br /> <br /> &lt;nowiki&gt;<br /> pick 77ad6e1 first version of TCP broken<br /> pick 9cfa78e Fix for the previous<br /> <br /> # Rebase e2fc90a..9cfa78e onto e2fc90a (10 command(s))<br /> #<br /> # Commands:<br /> # p, pick = use commit<br /> # r, reword = use commit, but edit the commit message<br /> # e, edit = use commit, but stop for amending<br /> # s, squash = use commit, but meld into previous commit<br /> # f, fixup = like &quot;squash&quot;, but discard this commit's log message<br /> # x, exec = run command (the rest of the line) using shell<br /> # d, drop = remove commit<br /> #<br /> # These lines can be re-ordered; they are executed from top to bottom.<br /> #<br /> # If you remove a line here THAT COMMIT WILL BE LOST.<br /> #<br /> # However, if you remove everything, the rebase will be aborted.<br /> #<br /> # Note that empty commits are commented out<br /> &lt;/nowiki&gt;<br /> <br /> What we want is to &quot;fixup&quot; the fix commit into the previous. So, changing &quot;pick&quot; to &quot;fixup&quot; (or simply f) and saving and quitting the editor is sufficient. The edited content:<br /> <br /> &lt;nowiki&gt;<br /> pick 77ad6e1 first version of TCP broken<br /> f 9cfa78e Fix for the previous<br /> &lt;/nowiki&gt;<br /> <br /> The resulting history:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git log<br /> Sun Jan 17 14:43:16 2016 +0100 847e9a8 (HEAD -&gt; tcp-next) first version of TCP broken [Tony Spinner]<br /> Mon Jan 11 14:44:13 2016 -0800 e2fc90a (origin/master, upstream/master, master) update some stale tutorial info [Someone]<br /> Mon Jan 11 21:11:54 2016 +0100 1df9c0d Bug 2257 - Ipv[4,6]InterfaceContainer::Add are not consistent [Someone]<br /> &lt;/nowiki&gt;<br /> <br /> Please remember that rewriting already published history is '''bad''', especially if someone other has synced your commits into their repository, but is necessary if you want to make clear commits. As a general rule, your personal development history can be rewritten as you wish; the history of your published features should be kept as they are.<br /> <br /> == Collaborating: an example of exchange between a maintainer and a contributor ==<br /> In the following we will explain a typical git workflow in the case of an exchange between a maintainer (M) and a contributor (C). It's clear that M is the only one that can push over the official ns-3-dev repo; but sometime, commits from C should be reviewed and tested out-of-the-tree. Now, we will follow two paths, corresponding to the actions of C and the actions of M.<br /> <br /> === How a contributor could made commits to be reviewed by a maintainer ===<br /> <br /> The first step for C is to set up a fork of the official ns-3-dev-git repository (see before). Then, if the M has it own repository, with some branches dedicated to future work that can be included next in the ns-3-dev repository, C should add its remote and fetch the index:<br /> <br /> git remote add [name] [url]<br /> git fetch [name]<br /> <br /> For instance, let's assume we are working on TCP. Nat usually has his own &quot;next-to-be-pushed&quot; work in the branch &quot;tcp-next&quot; of his repo on github. Therefore, C should start its work from this branch.<br /> <br /> git remote add nat https://github.com/kronat/ns-3-dev-git<br /> git fetch<br /> git checkout -b [feature_name] nat/tcp-next<br /> <br /> Please note that this is an example; the repo name, address, and the branch name could be different. At this point, the (local) branch of C called [feature_name] is tracking nat/tcp-next, and so it has all the same commits. C can start to work, using the normal workflow.<br /> <br /> When the set of commit is ready, C can push the branch to its own repository. Just do:<br /> <br /> git push<br /> <br /> NO ! This will likely results in an error, since C does not have the permission into writing the M repo. C should create a new branch in his own repository:<br /> <br /> git push -u origin [feature_name]<br /> <br /> That command will change the upstream reference, setting it to your origin (which is likely your github repo), and pushing all the work into the remote &quot;origin&quot;. For a visual representation of what is happening:<br /> <br /> &lt;nowiki&gt;<br /> [commit 169] &lt;----- C/tcp-next<br /> .... ( work of C on tcp-next )<br /> [commit 160] &lt;----- nat/tcp-next<br /> .... (previous work on TCP)<br /> [commit 123] &lt;---- ns-3-dev-git<br /> ... (official ns-3 history)<br /> &lt;/nowiki&gt;<br /> <br /> Well, at this point C could notify M: &quot;Please, see my work at github.com/C/ns-3-dev-git in the branch [feature_name]!&quot; and maybe asking for a merge. And it's time to change the perspective, passing to M.<br /> <br /> === A maintainer with a lot of contributor ===<br /> <br /> M has been notified of the work of C. The first thing he has to do is to adding the C repository to his (long) list of remotes:<br /> <br /> git remote add [C_name] [C_repo]<br /> git fetch [C_name]<br /> <br /> Then, he could quickly view the work done by the contributor:<br /> <br /> git checkout -b [local_C_name] [C_name]/[C_branch]<br /> <br /> If M thinks the work is well-done and ok, he could directly merge it into his branch:<br /> <br /> git checkout tcp-next<br /> git checkout merge [local_C_name]<br /> <br /> At this point, after some time, if the works is ok M should push the changes to the ns-3-dev mercurial repo. This is really tedious, and should be done carefully.. And it will be explained later in this HOWTO. But, as it often happens, M could made comments, and then wait another patchset.<br /> <br /> git checkout master<br /> git branch -D [local_C_name]<br /> <br /> === A quick flash-back to C ===<br /> <br /> Often the maintainer will made changes to that branch, because works of other contributor could have been merged, or whatever. So, C should be ready to _REBASE_ his own branch. Please note that a maintainer is *forced* to merge the contributor's work, because otherwise will broke the history of many. But each single contributor should *rebase* his work on the maintainer branch (or the master if the maintainer has no one). So, please go back and re-read carefully the section for rebasing the work.<br /> <br /> === Pushing things to ns-3-dev mercurial repository ===<br /> <br /> Of course this applies only for maintainers. When you have a local branch (e.g. tcp-next) that is ready to be merged in ns-3-dev, please do the following:<br /> # Pull the ns-3-dev-git master into your master branch<br /> # Rebase your local tcp-next branch to your local master branch<br /> # Create a series of patch that applies on top of master:<br /> git format-patch master<br /> # Copy these patches in ns-3-dev mercurial repo<br /> # Apply and commit one-by-one all these patches, paying attention to the right owner of the commit.<br /> <br /> One last thing: for binary patches this doesn't work: you need to update by hand all the files. We still need to figure a way to export correctly binary patches from git to mercurial.<br /> <br /> == Cheat sheet ==<br /> === Removing all local changes not tracked in the index (Dangerous) ===<br /> <br /> git clean -df<br /> git checkout -- .</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=HOWTO_use_Git_instead_of_Mercurial&diff=9850 2016-01-17T13:56:59Z

<p>Natale: Expanded and introduced a lot of new concepts</p> <hr /> <div>{{TOC}}<br /> <br /> The ns-3 project presently uses Mercurial as its source code control system, but several developers favor using Git. Git is a VCS like Mercurial, Subversion or CVS, and it used to maintain many open-source (and closed-source) project. While git and mercurial have a lot of common properties, if you are new to git you should read first an introduction to it. The most up-to-date guite is the [https://git-scm.com/book/en/v2/Getting-Started-Git-Basics Git Book].<br /> <br /> Ns-3 project has set up a mirror on Github at https://github.com/nsnam/ns-3-dev-git.<br /> <br /> Please note that this repo does not accept [https://help.github.com/articles/using-pull-requests/ pull requests] at this time; to contribute back to the mainline code, use our bug tracker or Rietveld (see [https://www.nsnam.org/developers/contributing-code/ Contributing Code to ns-3]).<br /> <br /> This page provides common tips for people who wish to fork ns-3-dev from the nsnam github repo and keep a master sync'ed to the nsnam github repo.<br /> <br /> == Let's start our personal repository ==<br /> === Forking ns-3-dev ===<br /> <br /> Assume that you are user 'john' on github, and that you want to create a new public github repo that is synced to nsnam/ns-3-dev-git.<br /> <br /> #. Log into github<br /> #. Navigate to https://github.com/nsnam/ns-3-dev-git<br /> #. In the top-right corner of the page, click '''Fork'''. <br /> <br /> Note that you may only do this once; if you try to Fork again, github will take you to the page of the original fork. <br /> <br /> To create multiple forks from the same repository, see this blog page: https://adrianshort.org/create-multiple-forks-of-a-github-repo/<br /> <br /> For more information on forking at github: https://help.github.com/articles/fork-a-repo/<br /> <br /> &lt;!-- == Renaming your fork ==<br /> <br /> If you want to rename this repository, it is probably best to do it right after the initial fork. Let's say you wish to rename it 'ns-3-dev-wifi' to track your wifi modifications.<br /> <br /> #. Under your repository name, click Settings.<br /> #. Under the Repository Name heading, type the new name of your repository.<br /> #. Click Rename.<br /> --&gt;<br /> <br /> === Clone your repository on your working machine === <br /> <br /> Clone it locally to your system: <br /> <br /> git clone https://github.com/your-user-name/ns-3-dev-git<br /> cd ns-3-dev-git<br /> <br /> == Typical workflow ==<br /> <br /> Git is a distributed versioning system. This means that '''nobody''' will touch your personal repo, until you do something. Please note that every github user has, at least, two repositories: the first is represented by the repository hosted on github servers, which will be called in the following ''origin''. Then, you have your clone on your machine. This means that you could have many clones, on different machines, which refers to ''origin''.<br /> <br /> === Add the official ns-3 repository as remote upstream ===<br /> <br /> When you fork a repository, your history is no more bound to the repository itself. At this point, it is your duty to sync your fork with the original repository.<br /> Git is able to fetch and push changes to several repositories, each of them is called '''remote'''. The first remote repository we have encountered is ''origin''; we must add the official ns-3 repo as another remote repository.<br /> <br /> git remote add upstream https://github.com/nsnam/ns-3-dev-git<br /> <br /> With the command above, we added a remote repository, named upstream, which links to the official ns-3 repo. To show your remote repositories:<br /> <br /> git remote show<br /> <br /> To see to what ''origin'' is linking to:<br /> <br /> git remote show origin<br /> <br /> You can also delete remotes:<br /> <br /> git remote remove [name]<br /> <br /> Many options are available; please refer to the git manual for more.<br /> <br /> === Sync your repo === <br /> <br /> We assume, from now to the end of this document, that you will not make commits on top of the master branch. It should be kept clean from '''any''' personal modifications. Move the current HEAD to the master branch:<br /> <br /> git checkout master<br /> <br /> and fetch the changes from ''upstream'':<br /> <br /> git fetch upstream<br /> <br /> we can now merge the official changes into our master:<br /> <br /> git pull upstream master<br /> <br /> If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset (but this never happens if you do not commit over master).<br /> <br /> === Start a new branch ===<br /> <br /> Now look at the available branches:<br /> <br /> git branch -a<br /> <br /> you should see:<br /> <br /> * master<br /> remotes/origin/master<br /> remotes/upstream/master<br /> <br /> The branch master is your local master branch; remotes/origin/master point at the master branch on your repository located in the Github server, while remotes/upstream/master points to the official master branch.<br /> <br /> To create a new branch, which hopefully will contains new feature or bug correction, the command is<br /> <br /> git checkout -b [name_of_your_new_branch]<br /> <br /> To switch between branches, remove the -b option. You should now see:<br /> <br /> git branch -a<br /> <br /> * master<br /> [name_of_your_new_branch]<br /> remotes/origin/master<br /> remotes/upstream/master<br /> <br /> === Edit and commit the modifications ===<br /> <br /> After you edit some file, you should commit the difference. As a policy, git users love small and incremental patches. So, commit early, and commit often: you could rewrite your history later.<br /> <br /> Suppose we edited src/internet/model/tcp-socket-base.cc. With git status, we can see the repostory status:<br /> <br /> &lt;nowiki&gt;<br /> On branch tcp-next<br /> Your branch is up-to-date with 'mirror/tcp-next'.<br /> Changes not staged for commit:<br /> modified: src/internet/model/tcp-socket-base.cc<br /> &lt;/nowiki&gt;<br /> and we can see the edits with git diff:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git diff<br /> diff --git i/src/internet/model/tcp-socket-base.cc w/src/internet/model/tcp-socket-base.cc<br /> index 1bf0f69..e2298b0 100644<br /> --- i/src/internet/model/tcp-socket-base.cc<br /> +++ w/src/internet/model/tcp-socket-base.cc<br /> @@ -1439,6 +1439,10 @@ TcpSocketBase::ReceivedAck (Ptr&lt;Packet&gt; packet, const TcpHeader&amp; tcpHeader)<br /> // There is a DupAck<br /> ++m_dupAckCount;<br /> <br /> + // I'm introducing a subtle bug!<br /> +<br /> + m_tcb-&gt;m_cWnd = m_tcb-&gt;m_ssThresh;<br /> +<br /> if (m_tcb-&gt;m_congState == TcpSocketState::CA_OPEN)<br /> {<br /> // From Open we go Disorder<br /> &lt;/nowiki&gt;<br /> <br /> To create a commit, select the file you want to add to the commit with git add:<br /> <br /> git add src/internet/model/tcp-socket-base.cc<br /> <br /> and then commit the result:<br /> <br /> git commit -m &quot;My new TCP broken&quot;<br /> <br /> You can see the history of the commits with git log. To show a particular commit, copy the sha id and use git show &lt;sha-id&gt; .<br /> Do this until you feature or bug is corrected; now, it is time to make a review request.<br /> <br /> === Rebase your branch on master ===<br /> <br /> Meanwhile you were busy with your branch, the upstream master could have changed. To rebase your work with the now new master, first of all sync your master branch as explained before; then<br /> <br /> git checkout [name_of_your_new_branch]<br /> git rebase master<br /> <br /> this will rewind your work, update the HEAD of your branch to the actual master, and then re-apply all your work. If some of your work conflicts with the actual master, you will be asked to fix these conflicts if automatic merge fails.<br /> <br /> === Creating a patch against master ===<br /> <br /> If you are in a branch and want to diff it against master, you can type:<br /> <br /> git diff master<br /> <br /> and redirect to a patch:<br /> <br /> git diff master &gt; patch-against-master.patch<br /> <br /> To preserve all your commits, it is preferable to create many patches, one for each commit:<br /> <br /> git format-patch master<br /> <br /> and then you could submit them for a review.<br /> <br /> === Rewrite your history ===<br /> <br /> Let's suppose that, after a first round of review, you are asked to fix something. After you commited the fix of your (previously bad) commit, the log should be something like:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git log<br /> Sun Jan 17 14:43:36 2016 +0100 9cfa78e (HEAD -&gt; tcp-next) Fix for the previous [Tony Spinner]<br /> Sun Jan 17 14:43:16 2016 +0100 77ad6e1 first version of TCP broken [Tony Spinner]<br /> Mon Jan 11 14:44:13 2016 -0800 e2fc90a (origin/master, upstream/master, master) update some stale tutorial info [Someone]<br /> Mon Jan 11 21:11:54 2016 +0100 1df9c0d Bug 2257 - Ipv[4,6]InterfaceContainer::Add are not consistent [Someone]<br /> &lt;/nowiki&gt;<br /> <br /> If you plan to resubmit a review, you would like to merge the commits (original and its fix). You can easily do this with git rebase -i (--interactive).<br /> <br /> git rebase -i master<br /> <br /> and an editor should pop up, with your commits, and various possibilities:<br /> <br /> &lt;nowiki&gt;<br /> pick 77ad6e1 first version of TCP broken<br /> pick 9cfa78e Fix for the previous<br /> <br /> # Rebase e2fc90a..9cfa78e onto e2fc90a (10 command(s))<br /> #<br /> # Commands:<br /> # p, pick = use commit<br /> # r, reword = use commit, but edit the commit message<br /> # e, edit = use commit, but stop for amending<br /> # s, squash = use commit, but meld into previous commit<br /> # f, fixup = like &quot;squash&quot;, but discard this commit's log message<br /> # x, exec = run command (the rest of the line) using shell<br /> # d, drop = remove commit<br /> #<br /> # These lines can be re-ordered; they are executed from top to bottom.<br /> #<br /> # If you remove a line here THAT COMMIT WILL BE LOST.<br /> #<br /> # However, if you remove everything, the rebase will be aborted.<br /> #<br /> # Note that empty commits are commented out<br /> &lt;/nowiki&gt;<br /> <br /> What we want is to &quot;fixup&quot; the fix commit into the previous. So, changing &quot;pick&quot; to &quot;fixup&quot; (or simply f) and saving and quitting the editor is sufficient. The edited content:<br /> <br /> &lt;nowiki&gt;<br /> pick 77ad6e1 first version of TCP broken<br /> f 9cfa78e Fix for the previous<br /> &lt;/nowiki&gt;<br /> <br /> The resulting history:<br /> <br /> &lt;nowiki&gt;<br /> nat@miyamoto ~/Work/ns-3-dev-git (tcp-next)$ git log<br /> Sun Jan 17 14:43:16 2016 +0100 847e9a8 (HEAD -&gt; tcp-next) first version of TCP broken [Tony Spinner]<br /> Mon Jan 11 14:44:13 2016 -0800 e2fc90a (origin/master, upstream/master, master) update some stale tutorial info [Someone]<br /> Mon Jan 11 21:11:54 2016 +0100 1df9c0d Bug 2257 - Ipv[4,6]InterfaceContainer::Add are not consistent [Someone]<br /> &lt;/nowiki&gt;<br /> <br /> Please remember that rewriting already published history is '''bad''', especially if someone other has synced your commits into their repository, but is necessary if you want to make clear commits. As a general rule, your personal development history can be rewritten as you wish; the history of your published features should be kept as they are.<br /> <br /> == Cheat sheet ==<br /> === Removing all local changes not tracked in the index (Dangerous) ===<br /> <br /> git clean -df<br /> git checkout -- .</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9806 2015-10-21T09:57:51Z

<p>Natale: Changed links from branch to tags into actual code</p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expected deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> '''Final though''': In the code, right now, only cWnd and ssth are moved back into TcpSocketBase.<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> ''' Not present in the final submission, because it is more complex than expected. However, branch is still alive and under development '''<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> ''' Present in the final submission '''<br /> <br /> == Slow start implementation ==<br /> <br /> Let's take as source RFC 5681. Slow start is defined as:<br /> <br /> During slow start, a TCP increments cwnd by at most SMSS bytes for<br /> each ACK received that cumulatively acknowledges new data. Slow<br /> start ends when cwnd exceeds ssthresh (or, optionally, when it<br /> reaches it, as noted above) or when congestion is observed. While<br /> traditionally TCP implementations have increased cwnd by precisely<br /> SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND<br /> that TCP implementations increase cwnd, per:<br /> cwnd += min (N, SMSS) (2)<br /> where N is the number of previously unacknowledged bytes acknowledged<br /> in the incoming ACK.<br /> <br /> Imagine that the receiver uses delayed ACK algorithm by default (as ns-3 currently do): it means that, more or less, we send 1 ACK every 2 packet received. This means that, with the slow start algorithm imposed by the RFC, we (no, the RFC) currently reduce the throughput achievable during the slow start. Some math (is really required?):<br /> <br /> * Assume the sender just sent 2 segments of SMSS each<br /> * The receiver receive the first, do not ack it (delayed ack algorithm)<br /> * The receiver receive the second, sends the ACK of 2*SMSS bytes<br /> * The sender receive the ack, computes<br /> <br /> min (N, SMSS) = min (2*SMSS, SMSS) = SMSS<br /> <br /> and so the cwnd is increased only by SMSS, and not 2*SMSS, as in the case without the delayed ACK. Without delayed ACK, we will end up with a cWnd of 4 segments, however with delayed ACK we will end up with a cWnd of only 3 segments. While one growth is exponential (4, 8, 16..) the other isn't, and the situation is even worse when we increase the number of ACK to wait before sending one delayed ACK (which often happens in fast networks).<br /> <br /> What Linux do? When it senses that the other end is in slow start, it does not use delayed ack.<br /> <br /> What we can do ?<br /> <br /> -&gt; use the following equation instead of (2):<br /> cwnd += N<br /> giving that N isn't outside boundaries (i.e. N &lt;= SND.UNA)<br /> <br /> -&gt; use the RFC equation, keeping delayed ACK algorithm the same,<br /> documenting this situation<br /> <br /> -&gt; (*) use the RFC equation, disabling delayed ACK when we suppose the<br /> other end is in slow start (i.e. until we do not send a triple<br /> DUPACK) and enabling it in congestion avoidance.<br /> <br /> Before, for each received ACK (also when it ACKed less than one segment) we increased cWnd by MSS.<br /> <br /> ''' In the final submission is present the option marked by (*) '''<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake '''Not present in the final submission but easy to setup'''<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down '''Not present in the final submission but easy to setup'''<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start '''Present in the final submission'''<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance '''Present in the final submission'''<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO '''Present in the final submission'''<br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO '''Not present in the final submission but easy to setup'''<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO '''Present in the final submission'''<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO '''Not present in the final submission but easy to setup'''<br /> : Multiple losses in the same window. Multiple RTO expiration.<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests. Since they have been inserted in ns-3-dev (2015-10-21) the links now points to tags in real code.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master (commit 1606c90 in github mirror)<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-1-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: 2015-gsoc-1-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-2-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: 2015-gsoc-2-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-3-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: 2015-gsoc-3-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-4-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: 2015-gsoc-4-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-5-ack-state-machine<br /> <br /> == Transmission control block ==<br /> <br /> Parent branch: 2015-gsoc-5-ack-state-machine<br /> <br /> Splitted the state from the TcpSocketBase. A new class has been added (TcpSocketState) which contains informations such as congestion window and slow start threshold.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-6-tcp-tcb<br /> <br /> == Fix TCP bugs ==<br /> <br /> Parent branch: 2015-gsoc-6-tcp-tcb<br /> <br /> Fix some TCB bugs reported in the bug tracker. Id 2159, 2150, 2041, 2165<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-7-fix-bugs<br /> <br /> == Tcp Error Model ==<br /> <br /> Parent branch: 2015-gsoc-7-fix-bugs<br /> <br /> Introduce the error model, and the environment, for TCP testing. Include tests for: slow start, new reno congestion avoidance, fast retransmission, rto expiration.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/2015-gsoc-8-error-model</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9736 2015-08-24T09:59:11Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expected deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> '''Final though''': In the code, right now, only cWnd and ssth are moved back into TcpSocketBase.<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> ''' Not present in the final submission, because it is more complex than expected. However, branch is still alive and under development '''<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> ''' Present in the final submission '''<br /> <br /> == Slow start implementation ==<br /> <br /> Let's take as source RFC 5681. Slow start is defined as:<br /> <br /> During slow start, a TCP increments cwnd by at most SMSS bytes for<br /> each ACK received that cumulatively acknowledges new data. Slow<br /> start ends when cwnd exceeds ssthresh (or, optionally, when it<br /> reaches it, as noted above) or when congestion is observed. While<br /> traditionally TCP implementations have increased cwnd by precisely<br /> SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND<br /> that TCP implementations increase cwnd, per:<br /> cwnd += min (N, SMSS) (2)<br /> where N is the number of previously unacknowledged bytes acknowledged<br /> in the incoming ACK.<br /> <br /> Imagine that the receiver uses delayed ACK algorithm by default (as ns-3 currently do): it means that, more or less, we send 1 ACK every 2 packet received. This means that, with the slow start algorithm imposed by the RFC, we (no, the RFC) currently reduce the throughput achievable during the slow start. Some math (is really required?):<br /> <br /> * Assume the sender just sent 2 segments of SMSS each<br /> * The receiver receive the first, do not ack it (delayed ack algorithm)<br /> * The receiver receive the second, sends the ACK of 2*SMSS bytes<br /> * The sender receive the ack, computes<br /> <br /> min (N, SMSS) = min (2*SMSS, SMSS) = SMSS<br /> <br /> and so the cwnd is increased only by SMSS, and not 2*SMSS, as in the case without the delayed ACK. Without delayed ACK, we will end up with a cWnd of 4 segments, however with delayed ACK we will end up with a cWnd of only 3 segments. While one growth is exponential (4, 8, 16..) the other isn't, and the situation is even worse when we increase the number of ACK to wait before sending one delayed ACK (which often happens in fast networks).<br /> <br /> What Linux do? When it senses that the other end is in slow start, it does not use delayed ack.<br /> <br /> What we can do ?<br /> <br /> -&gt; use the following equation instead of (2):<br /> cwnd += N<br /> giving that N isn't outside boundaries (i.e. N &lt;= SND.UNA)<br /> <br /> -&gt; use the RFC equation, keeping delayed ACK algorithm the same,<br /> documenting this situation<br /> <br /> -&gt; (*) use the RFC equation, disabling delayed ACK when we suppose the<br /> other end is in slow start (i.e. until we do not send a triple<br /> DUPACK) and enabling it in congestion avoidance.<br /> <br /> Before, for each received ACK (also when it ACKed less than one segment) we increased cWnd by MSS.<br /> <br /> ''' In the final submission is present the option marked by (*) '''<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake '''Not present in the final submission but easy to setup'''<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down '''Not present in the final submission but easy to setup'''<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start '''Present in the final submission'''<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance '''Present in the final submission'''<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO '''Present in the final submission'''<br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO '''Not present in the final submission but easy to setup'''<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO '''Present in the final submission'''<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO '''Not present in the final submission but easy to setup'''<br /> : Multiple losses in the same window. Multiple RTO expiration.<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window. Currently skipped<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block ==<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Splitted the state from the TcpSocketBase. A new class has been added (TcpSocketState) which contains informations such as congestion window and slow start threshold.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb<br /> <br /> == Fix TCP bugs ==<br /> <br /> Parent branch: gsoc-tcp-tcb<br /> <br /> Fix some TCB bugs reported in the bug tracker. Id 2159, 2150, 2041, 2165<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-fix-tcp-bugs<br /> <br /> == Tcp Error Model ==<br /> <br /> Parent branch: gsoc-fix-tcp-bugs<br /> <br /> Introduce the error model, and the environment, for TCP testing. Include tests for: slow start, new reno congestion avoidance, fast retransmission, rto expiration.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-error-model<br /> <br /> == Tcp Tracking Helper ==<br /> <br /> Parent branch: gsoc-tcp-error-model<br /> <br /> Introduce a new helper, which helps users to track down TCP values such as congestion window. Not ready for a merge.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-helper</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9725 2015-08-20T13:00:44Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> == Slow start implementation ==<br /> <br /> Let's take as source RFC 5681. Slow start is defined as:<br /> <br /> During slow start, a TCP increments cwnd by at most SMSS bytes for<br /> each ACK received that cumulatively acknowledges new data. Slow<br /> start ends when cwnd exceeds ssthresh (or, optionally, when it<br /> reaches it, as noted above) or when congestion is observed. While<br /> traditionally TCP implementations have increased cwnd by precisely<br /> SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND<br /> that TCP implementations increase cwnd, per:<br /> cwnd += min (N, SMSS) (2)<br /> where N is the number of previously unacknowledged bytes acknowledged<br /> in the incoming ACK.<br /> <br /> Imagine that the receiver uses delayed ACK algorithm by default (as ns-3 currently do): it means that, more or less, we send 1 ACK every 2 packet received. This means that, with the slow start algorithm imposed by the RFC, we (no, the RFC) currently reduce the throughput achievable during the slow start. Some math (is really required?):<br /> <br /> * Assume the sender just sent 2 segments of SMSS each<br /> * The receiver receive the first, do not ack it (delayed ack algorithm)<br /> * The receiver receive the second, sends the ACK of 2*SMSS bytes<br /> * The sender receive the ack, computes<br /> <br /> min (N, SMSS) = min (2*SMSS, SMSS) = SMSS<br /> <br /> and so the cwnd is increased only by SMSS, and not 2*SMSS, as in the case without the delayed ACK. Without delayed ACK, we will end up with a cWnd of 4 segments, however with delayed ACK we will end up with a cWnd of only 3 segments. While one growth is exponential (4, 8, 16..) the other isn't, and the situation is even worse when we increase the number of ACK to wait before sending one delayed ACK (which often happens in fast networks).<br /> <br /> What Linux do? When it senses that the other end is in slow start, it does not use delayed ack.<br /> <br /> What we can do ?<br /> <br /> -&gt; use the following equation instead of (2):<br /> cwnd += N<br /> giving that N isn't outside boundaries (i.e. N &lt;= SND.UNA)<br /> <br /> -&gt; use the RFC equation, keeping delayed ACK algorithm the same,<br /> documenting this situation<br /> <br /> -&gt; use the RFC equation, disabling delayed ACK when we suppose the<br /> other end is in slow start (i.e. until we do not send a triple<br /> DUPACK) and enabling it in congestion avoidance.<br /> <br /> Before, for each received ACK (also when it ACKed less than one segment) we increased cWnd by MSS.<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window. Currently skipped<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block ==<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Splitted the state from the TcpSocketBase. A new class has been added (TcpSocketState) which contains informations such as congestion window and slow start threshold.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb<br /> <br /> == Fix TCP bugs ==<br /> <br /> Parent branch: gsoc-tcp-tcb<br /> <br /> Fix some TCB bugs reported in the bug tracker. Id 2159, 2150, 2041, 2165<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-fix-tcp-bugs<br /> <br /> == Tcp Error Model ==<br /> <br /> Parent branch: gsoc-fix-tcp-bugs<br /> <br /> Introduce the error model, and the environment, for TCP testing. Include tests for: slow start, new reno congestion avoidance, fast retransmission, rto expiration.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-error-model<br /> <br /> == Tcp Tracking Helper ==<br /> <br /> Parent branch: gsoc-tcp-error-model<br /> <br /> Introduce a new helper, which helps users to track down TCP values such as congestion window.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-helper</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9705 2015-07-25T08:49:10Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> == Slow start implementation ==<br /> <br /> Let's take as source RFC 5681. Slow start is defined as:<br /> <br /> During slow start, a TCP increments cwnd by at most SMSS bytes for<br /> each ACK received that cumulatively acknowledges new data. Slow<br /> start ends when cwnd exceeds ssthresh (or, optionally, when it<br /> reaches it, as noted above) or when congestion is observed. While<br /> traditionally TCP implementations have increased cwnd by precisely<br /> SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND<br /> that TCP implementations increase cwnd, per:<br /> cwnd += min (N, SMSS) (2)<br /> where N is the number of previously unacknowledged bytes acknowledged<br /> in the incoming ACK.<br /> <br /> Imagine that the receiver uses delayed ACK algorithm by default (as ns-3 currently do): it means that, more or less, we send 1 ACK every 2 packet received. This means that, with the slow start algorithm imposed by the RFC, we (no, the RFC) currently reduce the throughput achievable during the slow start. Some math (is really required?):<br /> <br /> * Assume the sender just sent 2 segments of SMSS each<br /> * The receiver receive the first, do not ack it (delayed ack algorithm)<br /> * The receiver receive the second, sends the ACK of 2*SMSS bytes<br /> * The sender receive the ack, computes<br /> <br /> min (N, SMSS) = min (2*SMSS, SMSS) = SMSS<br /> <br /> and so the cwnd is increased only by SMSS, and not 2*SMSS, as in the case without the delayed ACK. Without delayed ACK, we will end up with a cWnd of 4 segments, however with delayed ACK we will end up with a cWnd of only 3 segments. While one growth is exponential (4, 8, 16..) the other isn't, and the situation is even worse when we increase the number of ACK to wait before sending one delayed ACK (which often happens in fast networks).<br /> <br /> What Linux do? When it senses that the other end is in slow start, it does not use delayed ack.<br /> <br /> What we can do ?<br /> <br /> -&gt; use the following equation instead of (2):<br /> cwnd += N<br /> giving that N isn't outside boundaries (i.e. N &lt;= SND.UNA)<br /> <br /> -&gt; use the RFC equation, keeping delayed ACK algorithm the same,<br /> documenting this situation<br /> <br /> -&gt; use the RFC equation, disabling delayed ACK when we suppose the<br /> other end is in slow start (i.e. until we do not send a triple<br /> DUPACK) and enabling it in congestion avoidance.<br /> <br /> Before, for each received ACK (also when it ACKed less than one segment) we increased cWnd by MSS.<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Currently ongoing development.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9704 2015-07-25T08:47:05Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> == Slow start implementation ==<br /> <br /> Let's take as source RFC 5681. Slow start is defined as:<br /> <br /> During slow start, a TCP increments cwnd by at most SMSS bytes for<br /> each ACK received that cumulatively acknowledges new data. Slow<br /> start ends when cwnd exceeds ssthresh (or, optionally, when it<br /> reaches it, as noted above) or when congestion is observed. While<br /> traditionally TCP implementations have increased cwnd by precisely<br /> SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND<br /> that TCP implementations increase cwnd, per:<br /> <br /> cwnd += min (N, SMSS) (2)<br /> <br /> where N is the number of previously unacknowledged bytes acknowledged<br /> in the incoming ACK.<br /> <br /> Imagine that the receiver uses delayed ACK algorithm by default (as ns-3 currently do): it means that, more or less, we send 1 ACK every 2 packet received. This means that, with the slow start algorithm imposed by the RFC, we (no, the RFC) currently reduce the throughput achievable during the slow start. Some math (is really required?):<br /> <br /> * Assume the sender just sent 2 segments of SMSS each<br /> * The receiver receive the first, do not ack it (delayed ack algorithm)<br /> * The receiver receive the second, sends the ACK of 2*SMSS bytes<br /> * The sender receive the ack, computes<br /> <br /> min (N, SMSS) = min (2*SMSS, SMSS) = SMSS<br /> <br /> and so the cwnd is increased only by SMSS, and not 2*SMSS, as in the case without the delayed ACK. Without delayed ACK, we will end up with a cWnd of 4 segments, however with delayed ACK we will end up with a cWnd of only 3 segments. While one growth is exponential (4, 8, 16..) the other isn't, and the situation is even worse when we increase the number of ACK to wait before sending one delayed ACK (which often happens in fast networks).<br /> <br /> What Linux do? When it senses that the other end is in slow start, it does not use delayed ack.<br /> <br /> What we can do ?<br /> <br /> -&gt; use the following equation instead of (2):<br /> cwnd += N<br /> giving that N isn't outside boundaries (i.e. N &lt;= SND.UNA)<br /> <br /> -&gt; use the RFC equation, keeping delayed ACK algorithm the same,<br /> documenting this situation<br /> <br /> -&gt; use the RFC equation, disabling delayed ACK when we suppose the<br /> other end is in slow start (i.e. until we do not send a triple<br /> DUPACK) and enabling it in congestion avoidance.<br /> <br /> Before, for each received ACK (also when it ACKed less than one segment) we increased cWnd by MSS.<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Currently ongoing development.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9703 2015-07-25T08:39:08Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Week 5 ==<br /> * Prepared the branch (after a first round of review by Tom) to be included, as midterm accomplishment. I've also updated my wiki page (which is now really long)<br /> * As recap, I've finished working on these branches:<br /> - gsoc-ack-state-machine (introd. ack state machine)<br /> - gsoc-cwnd-inflation (removed inflation/deflation)<br /> - gsoc-tcp-tcb (used a Transmission Control Block to pass<br /> variables between Socket and Cong. Control)<br /> <br /> * I'm currently in the gsoc-tcp-error-model branch, where a first test on slow start is being developed.<br /> <br /> == Week 6 ==<br /> <br /> * As pointed out in a review, I've added an API to make traces and attributes &quot;deprecate&quot;.<br /> <br /> * The entire patchset is ready for review. Each commit is self-contained and documented in the commit message.<br /> <br /> * Slow start test done.<br /> <br /> * Congestion avoidance (NewReno, Tahoe) test done. It simply checks that, in each RTT, the cWnd is opened by 1 segment.<br /> <br /> == Week 7 == <br /> <br /> Due to familiar issues, I've carried less than I've had in mind.<br /> * Updated TCP Congestion avoidance test<br /> <br /> == Week 8 ==<br /> <br /> For bug 2149, on Deprecation of attributes and trace sources, two iterations have been done. The current patch introduces MakeEmptyAttributeAccessor and MakeEmptyAttributeChecker, in order to utilize an EmptyAttributeValue as placeholder for deprecated/obsoleted attributes. For TraceSource, it is similar.<br /> <br /> On the fast recovery/rentransmit side, the general structure of the test is completed. Things I want to test:<br /> <br /> - Ack state machine state changing<br /> - on each dupack, one segment is sent out<br /> - one ssth reduction per window<br /> <br /> == Week 9 ==<br /> <br /> == Week 10 ==<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Currently ongoing development.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9669 2015-06-28T15:08:03Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> <br /> The branches presented here are not ready for an official review; however, please take a look and give your comments if you can.<br /> <br /> == Ack state machine ==<br /> <br /> Parent branch: gsoc-cwnd-ssth-merge<br /> <br /> Implemented the ACK state machine. The states are:<br /> <br /> typedef enum<br /> {<br /> OPEN, /**&lt; Normal state, no dubious events */<br /> DISORDER, /**&lt; In all the respects it is &quot;Open&quot;,<br /> * but requires a bit more attention. It is entered when<br /> * we see some SACKs or dupacks. It is split of &quot;Open&quot; */<br /> CWR, /**&lt; cWnd was reduced due to some Congestion Notification event.<br /> * It can be ECN, ICMP source quench, local device congestion.<br /> * Not used in NS-3 right now. */<br /> RECOVERY, /**&lt; CWND was reduced, we are fast-retransmitting. */<br /> LOSS, /**&lt; CWND was reduced due to RTO timeout or SACK reneging. */<br /> LAST_ACKSTATE /**&lt; Used only in debug messages */<br /> } TcpAckState_t;<br /> <br /> This state machine allows to move Fast recovery and Fast retransmit out of NewReno, and integrate them into TcpSocketBase. As downside, Reno and RFC 793 TCP (no congestion control) are removed from the codebase. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Remove cWnd inflation/deflation ==<br /> <br /> Parent branch: gsoc-ack-state-machine<br /> <br /> Removed the inflation and the deflation of the window.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-inflation<br /> <br /> == Transmission control block<br /> <br /> Parent branch: gsoc-cwnd-inflation<br /> <br /> Currently ongoing development.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-tcb</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9668 2015-06-28T14:59:32Z

<p>Natale: /* Midterm review */</p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can deduce from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9658 2015-06-26T11:01:49Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> As general remarks, I'm sorry to be unable to provide a first set of test example in the midterm review, neither the full socket refactor. As you can desume from the technical issues section, there are three more things to complete:<br /> <br /> * Ack state machine<br /> * remove inflation/deflation of cwnd<br /> * adding the Transmission Control Block class to exchange data between sockets and congestion control algorithms.<br /> <br /> They'll be ready for the final review, along with the tests.<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo # Only the first time<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9657 2015-06-26T10:56:55Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> = Midterm review =<br /> <br /> Here I want to present the work done until the 4th week for the midterm review. The section is organized as follows: <br /> <br /> * Brief patch summary<br /> * Link to the codereview<br /> <br /> To get individual patches, the procedure is as follows:<br /> <br /> git clone git_repo<br /> git checkout -b branch_name<br /> git format-patch parent_branch<br /> <br /> parent_branch will be indicated at the beginning of each section.<br /> <br /> == TCP L4 Protocol ==<br /> <br /> Parent branch: master<br /> <br /> The objective of this patchset is to address API in TcpL4Protocol, to separate TcpSocketBase and TcpL4Protocol behavior. In particular, no direct connections through &quot;friend&quot; relationship should be made between these classes; they are two separate entities, with well-defined duties. TcpL4Protocol should to multiplexing/demultiplexing, while TcpSocketBase maintains the TCP end-to-end behavior.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Merge DoForward methods ==<br /> <br /> Parent branch: gsoc-tcp-l4-protocol<br /> <br /> The commit unifies the behavior of DoForwardUp for both IPv4 and IPv6 (previously tagged as duplicated code) by changing the input parameters: from an {IPv4,IPv6}Header to a couple of address (sender and receiver). Thanks to the Send() method of TcpL4Protocol which takes in input two Addresses, the behavior of the method could be unified.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Better print statements and log management ==<br /> <br /> Parent branch: gsoc-merge-doforwardup<br /> <br /> This branch objective is to have independent print statements (through the use of operator&lt;&lt;) and, in general, an unified way of printing messages on TCP part. <br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-messages<br /> <br /> == cWnd and ssTh management inside TcpSocketBase ==<br /> <br /> Parent branch: gsoc-tcp-messages<br /> <br /> Each TCP flavors manage their congestion window and slow start threshold. These parameters are inside the TCP behavior, and so they have been moved inside TcpSocketBase. Rfc793 simply do not utilize these variables. It contains a change which is not back-compatible: traces of cWnd and ssTh are moved from TCP subclasses to TcpSocketBase. Initialization is also moved inside TcpSocketBase.<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> Git link: https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> <br /> = Final review =<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9635 2015-06-22T08:28:44Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Week 4 ==<br /> <br /> * Implemented ACK-state machine, which manages Fast Retransmission and Fast Recovery. The code has been changed only to manage the states in such ack machine (OPEN,DISORDER,RECOVERY,LOSS) but the path and the action taken by the code are exactly the same. The patch is made in an incremental way and takes 8 commits.<br /> <br /> * The loss management now happens in-window: this means that the ssthresh is recalculated only for the first loss in the window. It can be halved again only after the state change (LOSS-&gt;OPEN). I see some minor variation on the pcap trace before and after the patch, I'll investigate such differencies this week.<br /> <br /> * Since TCP Reno and TCP Tahoe differ from NewReno only for fast retransmit and fast recovery phases, they have been removed. If the community want them back, some switch should be added.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-ack-state-machine<br /> <br /> == Final review ==<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9634 2015-06-21T12:41:22Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> = Technical issues and plan =<br /> <br /> == Split input and output logic ==<br /> Since tcp-socket-base.cc is ~3000 lines long, and working on it starts to be annoying (most software engineer references (for example [1]) says the optimal length should be 600 lines long) because it is really difficult to walk through so much lines, I was thinking to split input and output logic of the socket in two different .cc files (tcp-socket-base-input.cc and tcp-socket-base-output.cc), with the aim to reach 1500 lines for each one, without changing the architecture (TcpSocketBase would still be one class). The only thing which changes would be the logging: if the user want to outputs all socket logging, he/she should enable TcpSocketBaseInput and TcpSocketBaseOutput, instead of TcpSocketBase (I don't know if there's a way to create a - let's say - super-logging-class, which if enabled prints log statements for children classes). Pro: an user could log only the input (or the output) logic by enabling the component he/she wants.<br /> <br /> [1] IEEE Computer Society Real-World Software Engineering Problems: A<br /> Self-Study Guide for Today's Software Professional<br /> <br /> == Socket attributes ==<br /> <br /> Right now, TCP socket attributes are scattered along classes. For instance, SND.UNA is an attribute of TcpTxBuffer, RCV.NXT is in TcpRxBuffer, and with my refactoring it seems (from the talk with Peter) that cWnd and ssThresh (along with rxThresh and so on) belong to TcpSocketState. My opinion is that, while we are in the game, let's investigate all the possible options. So, why not move _all_ the attributes and traces which control the behavior of TCP socket inside the TCP socket itself? One of the criticism is:<br /> <br /> this attribute controls the behavior of class A, but it's not defined in A, it's defined in some other class B<br /> <br /> My view is that where an attribute is defined is, in this case (and maybe only in this case), purely an implementation choice. cWnd or SND.UNA belongs conceptually to the socket; the fact that we, for easyness in debug and coding, moved their definition outside the main TcpSocketBase class is a thing that interest only developers, and not users. So, giving that all the documentation is correct (e.g. in the tutorial explain how to connect the TcpSocketBase, while in doxygen explains where certain parts are managed) the confusion that may be created to long-time users is avoided. For me either way is fine (technically, with the patch MakeTraceSourceAccessorFn, it is possible to do both).<br /> <br /> == cWnd inflation/deflation ==<br /> <br /> In Fast Recovery, RFC says that for each duplicate ACK the implementation should increment cWnd by one segment size. The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCP's sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. The implementation of TCP in Linux kernel avoids this &quot;shamanism&quot; (they're so funny in commenting their code) by improving the estimate of the in-flight packet. In RFC and ns-3, the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT - SND.UNA)<br /> <br /> example: cWnd = 10, SND.NXT = 20, SND.UNA = 10. You receive 3 ACKs for<br /> 10. When receiving the third, you set cWnd to 13, and so:<br /> <br /> AvailableWindow = 13 - (20 - 10) = 3<br /> <br /> and 3 packets could be sent. For each additional DUPACK, cWnd is incremented by 1 MSS, and one packet could be sent. When a full ACK is received, cWnd goes back to the right value (which is the recalculated ssth).In Linux [1], the calculus is:<br /> <br /> AvailableWindow = cWnd - (SND.NXT-SND.UNA) - left_out + retrans_out<br /> <br /> What are these new values? retrans_out is the number of packet retransmitted, and<br /> <br /> left_out = sacked_out + lost_out<br /> <br /> where sacked_out is the number of packets arrived at the received but not acked. With SACK this is easy to obtain, but with DUPACK is easy too (sacket_out=m_dupAckCount). lost_out is the only guessed value: with FACK, which is the most conservative heuristic, you assume that all not SACKed packets until the most forward SACK are lost. Since we have not SACK, NewReno estimate could be used, which basically assumes that only one segment is lost (classical Reno). If we are in recovery and a partial ACK arrives, it means that one more packet has been lost.<br /> <br /> On the wire, inflating / deflating the cWnd or use the linux metric is exactly the same. On the cWnd analysis, it is better to not have the inflation because it allows to see exactly the classical Van Jacobson's shape. On the implementation point of view, it is easier to not have the inflation/deflation, since it eliminates some complexity from the code. However, this means that we will not _strictly_ follow the RFC. It depends on your point of view, if the result is exactly the same on wire. Mine is to agree to the Linux implementation.<br /> <br /> == ACK state machine ==<br /> <br /> To deal with SACK/FACK/ECN and so on, in Linux it is introduced a new state machine. I friendly call it &quot;Ack State Machine&quot;. There are five states: Open, Disorder, CWR, Recovery, Loss. Introducing it in ns-3 would allow to manage the fast retransmit/recovery in a more consolidated way, at the cost of introducing another state machine in the code (which anyway could be tracked with attributes). It is also not defined in any RFC, but would help in the future to manage things like Explicit Congestion Notification, Local Device Congestion or ICMP source quench. Introducing this state machine touches the actual code in a much deeper way than just only refactoring (ah, a thing I forgot, is that this state machine only works in the ACK management part, other pieces are left untouched).<br /> <br /> == Ideas on possible tests ==<br /> <br /> ; TCP Three way handshake<br /> : Two possible cases: Well-behaving endpoints: SYN-SYN/ACK-ACK progression or missing SYN/ACK or missing ACK because of drop.<br /> * Check the transmission of SYN/ACK and ACK after the first SYN<br /> * Check retransmission of SYN/ACK or ACK<br /> * Check retries count and termination if it is not possible to make the connection<br /> <br /> ; TCP Four way tear-down<br /> : Also there we can have well-behaving endpoints or losses on FINs or ACKs.<br /> * Check the sequence FIN--&gt;ACK FIN--&gt;ACK<br /> * Check the retransmission of FINs<br /> <br /> ; Established state: slow start<br /> : Without any loss, congestion window grow up to ssth<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: congestion avoidance<br /> : Without any loss, after reaching ssth, the congestion window grows up linearly (this depends on the congestion avoidance algorithm selected)<br /> * Check what happens with small acks (e.g. 1000 bytes of MSS, ACK each 500 bytes)<br /> <br /> ; Established state: single loss, no RTO <br /> : Single loss in the window. Only duplicated ACKs.<br /> <br /> ; Established state: multiple losses, no RTO<br /> : Multiple losses in the window. Only duplicated ACKs and partial ACKs.<br /> <br /> ; Established state: single loss, with RTO<br /> : Single loss in the window detected through the expiration of the RTO.<br /> <br /> ; Established state: multiple losses, with RTO<br /> : Multipli losses in the same window. Multiple RTO expiration.<br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Final review ==<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9628 2015-06-19T14:08:53Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> == Week 2 ==<br /> <br /> * The merge for tcp-versions into mainline has been slightly delayed to Monday due to reviewers' duties.<br /> * Patches for TcpL4Protocol are ready for a review. They simplify a lot the class, reducing the duplicated code, and fixes two bugs (one for an invalid RST packet, and the other about const correctness of methods). Git repository is in [1].<br /> <br /> * Manage ssth and cwnd into TcpSocketBase<br /> <br /> Finally! I have always wanted that. Now, each tcp version doesn't need to declare and manage their window flow variables. They are initializated and accessible via Attribute systems through TcpSocketBase ! This means ~500 lines of duplicated code removed, as can be seen from stat:<br /> <br /> 16 files changed, 136 insertions(+), 618 deletions(-)<br /> <br /> Without touching the functionalities of the congestion control algorithms. The code is ready in [2] (codereview will be setup after the patches in TcpL4Protocol reaches mainline). This is a starting point for extracting congestion control from the socket. By the way, I've done a little thing (unnoticed before). The function DoForwardUp exists in both version (IPv4 and IPv6) and that duplicates a lot of code. Thanks to the changes to TcpL4Protocol, now the two functions are merged. Less duplicated code and same functionality: this is what I love :-D (code in [3], codereview togheter with cwnd-ssth merge).<br /> <br /> src/internet/model/tcp-socket-base.cc | 185 +++++++++++++++++++++++++------------------------------------------------------------------------------<br /> src/internet/model/tcp-socket-base.h | 22 +++++--------<br /> 2 files changed, 53 insertions(+), 154 deletions(-)<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> [2] https://github.com/kronat/ns-3-dev-git/tree/gsoc-cwnd-ssth-merge<br /> [3] https://github.com/kronat/ns-3-dev-git/tree/gsoc-merge-doforwardup<br /> <br /> == Week 3 ==<br /> <br /> * TcpCongestionOps abstract class has been created. To exchange data between socket and the congestion control, a TcpSocketState class has been created as well, with the members needed to the congestion control to work (e.g. cwnd, ssth).<br /> <br /> * NewAck has been implemented, and a simple transfer (tcp-bulk-send) is running fine under the new model (the code has not been modified, only refactored).<br /> <br /> == Final review ==<br /> It's not the time :)</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9560 2015-06-01T13:25:41Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Week 1 - Step 1 ==<br /> Different tools has been evaluated to measure the performance on ns-3. I<br /> was mainly interested in the TCP layer, but I found that it requires less<br /> than 0.57% of the entire total running time for tcp-based examples like<br /> tcp-variants-comparison and tcp-bulk-send. In particular, I'm reporting<br /> the results with perf, which is the current &quot;on-the-wave&quot; technology for<br /> performance evaluation.<br /> <br /> While the most source of overhead is in core (MultModM function. As a side<br /> question, there is a chance to see if there are other - maybe in assembly - way<br /> to do it?) from what is visible from this line:<br /> <br /> 10,63% libns3-dev-core-debug.so [.] (anonymous namespace)::MultModM<br /> <br /> TCP counts for less than 0.57% in its most demanding piece of code:<br /> <br /> 0.57% std::_List_base&lt;ns3::Ptr&lt;ns3::TcpOption&gt;, std::allocator&lt;ns3::Ptr&lt;ns3::TcpOption&gt; &gt; &gt;::_M_clear<br /> <br /> and to reach the first function we should walk to the 4th place, where<br /> TcpTxBuffer::CopyFromSequence stands with 0.35%. The most demanding function<br /> in TcpSocketBase are SendPendingData and ReceivedData (obviously) while<br /> TcpL4Protocol isn't in the very first page of the list (so it is reasonably<br /> fast). Please note that with each run results can vary a little (measuring<br /> performance isn't an exact science) but from what I have gathered I<br /> can start now to change things and making sure that any my edit isn't<br /> adding unwanted complexity (on the contrary, with the hope to be<br /> slightly faster than the past). If you want to try, check ns-3-dev<br /> (with ./waf --run &quot;tcp-bulk-send&quot; --command-template=&quot;perf record %s&quot;)<br /> and then check the code in [1]. Results are reported with perf report.<br /> <br /> Logically separate the TcpL4Protocol and TcpSocketBase isn't only a stylistic<br /> change. It implies a better definition of the role of the two classes:<br /> TcpL4Protocol handles {de,}multiplexing between opened sockets (thanks to<br /> the endpoints), while TcpSocketBase implement all the logic behind a<br /> communication between two endpoints with TCP.<br /> <br /> To do so, an incremental approach has been taken. You can see in [1] all<br /> the patches that have been published with an in-depth explanation of what<br /> has been done and why.<br /> <br /> [1] https://github.com/kronat/ns-3-dev-git/tree/gsoc-tcp-l4-protocol<br /> <br /> <br /> == Final review ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=GSOC2015TCPTest&diff=9464 2015-04-30T09:51:44Z

<p>Natale: Created page with &quot;{{TOC}} Return to GSoC 2015 Accepted Projects page. == Project overview == * '''Project:'''TCP layer refactoring with automated test on RFC-com...&quot;</p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[GSOC2015AcceptedProjects | GSoC 2015 Accepted Projects]] page.<br /> == Project overview ==<br /> * '''Project:'''TCP layer refactoring with automated test on RFC-compliance and validation <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> * '''Mentors:''' [mailto:tomh@tomh.org Tom Henderson],[mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> * '''Abstract:''' A step-by-step refactoring of the TCP layer, which should lead to a more easy way to test congestion control and RFC compliancy of its state machine.<br /> * '''Future Plans:''' None yet<br /> * '''Code:'''<br /> * '''About me:''' My first step into ns-3 were dated to middle 2013. I started working to an integration of ns-3 and Netmap; first results were published to IEEE ICON 2013. Then, I switched to the upper levels, namely TCP and IP, and made a middleware proposal to reduce latency in high-delay environments called C2ML, and published in GCOM 2014, with simulations entirely based on ns-3. I contributed to the TCP layer of ns-3 via the SOCIS 2014 experience, where I coded the TCP options and some TCP congestion control algorithms (BIC, Cubic, Hybla, Noordwijk). The project successful ended, and TCP variants are under review for an inclusion on the mainline (options were already accepted). More information about my research status are [[http://dii.unimore.it/wiki/index.php?title=Natale_Patriciello&amp;redirect=no here]]<br /> <br /> = The (original) proposal =<br /> <br /> == Actual TCP Overview ==<br /> The ns-3 TCP layer was substantially rewritten in 2011, with the introduction of the abstract class TcpSocketBase, which provides the TCP socket basic functions, such as the mechanics of its state machine and the sliding window. It is born to be extensible, and in fact it needs to be extended to work: the first extensions that have been released were two TCP flavors, namely TCP NewReno and the basic TCP without congestion control. Over the years, only two subclasses have been added: TcpWestwood and TcpTahoe. It is worth noting that not even the algorithms written for ns-2 (for instance, Cubic, Bic and so on) were ported to ns-3. The first time I approached ns-3, I ascribed this behavior to the carelessly of the researchers. After all, TCP research is a well-investigated subject, and no more effort is put into its development anymore.<br /> <br /> == Considerations ==<br /> Things changed when I submitted my proposal to SOCIS 2014. It has been selected, and I started to develop a lot of TCP congestion control algorithms: Cubic, Bic, Hybla, Highspeed, and Noordwijk, together with an initial implementation of Tcp options (despite their creation in 1992, ns-3 was still missing all of them). All over the summer I faced the messy code of TCP layer. The real problem is not in the quality of the code (after all, it has -probably- worked well for all these years) but rather than in its design. At the core of this firm belief, there is one fundamental issue: that a congestion control &quot;is-a&quot; TCP (e.g. TcpNewReno &quot;is-a&quot; TcpSocketBase. This way, each TCP flavor needs to define its own cWnd and ssThresh. Moreover, each version should reimplement basic algorithms (like fast retransmission) and, even worse, bugs resolved in one subclass may be still present in other subclasses.<br /> <br /> == Tests ==<br /> An evidence of that can be found on the test which are present on the src/test/ns3tcp subdirectory (I pass over the test in the src/internet directory.. the only test is a very general one where it is tested if TcpNewReno can open a connection, transfer some data and then close the connection). For instance, let's take the loss test: all flavors (westwood, newreno, tahoe..) are tested sequentially with an approach that, in words, sound like: &quot;What happen if the 14th packet is lost?&quot;. The outcome is then compared with a reference pcap file, which generates an error if there is any difference. A good design would allowed to check the internal state, the values of cwnd before and after, and the slow start threshold, only one time for all these flavors, since they share the fast recovery / fast retransmit algorithms. Switching to the congestion window test, it is clear that cWnd is tested only for Reno, and against the linux 2.6.26 implementation. In general, no RFC compliance is tested (for example, we are in SYN_RCVD state, and we receive an ACK for a random sequence number. What happens?) and all testing is done through comparison with reference pcap files. Another issue for a ns-3 user is the doubtful consistency of the TcpSocketBase API. For example, the initial congestion window is expressed in packets, while the initial slow start threshold is expressed in bytes; these kind of differences could lead to subtle bugs and misunderstandings in the user-written code.<br /> <br /> == The complete proposal ==<br /> Read (and comment) the entire proposal [[https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/natalepatriciello/5668600916475904 here]].<br /> <br /> <br /> = Expcted deliverables =<br /> <br /> == Week 1 - Step 1 ==<br /> * Time measurement on TCP layer<br /> * Remove the TcpL4Layer and TcpSocketBase friendship (which become an &quot;has&quot; relationship)<br /> <br /> == Week 2 - Deliverable for Step 1; start of Step 2 ==<br /> * Patches submitted for deliverables of step 1<br /> * Inserting cWnd and ssTh management into TcpSocketBase (and relative attributes). Subclasses of TcpSocketBase work on these protected variables.<br /> * Actual test updated to account this design<br /> <br /> == Week 3 - Step 2 ==<br /> * Split congestion control part from TcpSocketBase, by creating the interface class TcpCongestionControl.<br /> * Port of existing congestion control as subclasses of TcpCongestionControl<br /> <br /> == Week 4 - Step 2 ==<br /> * Improvement in actual test of congestion controls. Test will be re-organized and expanded (especially for variants written in SOCIS 2014)<br /> <br /> == Week 5 - Deliverable for Step2 and Step 3 ==<br /> * Subclassing is done through &quot;virtualization&quot; of methods of class TcpSocketBase, and then the code splitting will be done. Non-implemented methods will be pure virtual.<br /> <br /> == Week 6 - Step 3 ==<br /> * Carry on on the splitting, with a careful check when splitting duties<br /> <br /> == Week 7 - Deliverable for Step 3; start of Step 4 ==<br /> * From here to the end of the project, effort on implementing RFC-compliance test for the TCP state machine.<br /> * In the remaining time, if it exists, testing against a reference implementation could be made (i.e. pcap generation of the Linux stack, with DCE, and a comparison against ns-3 implementation). Possible differences will be addressed with specific attributes to enable or disable Linux compatibility.<br /> <br /> == Week 8 - Step 4 ==<br /> <br /> == Week 9 - Step 4 ==<br /> <br /> == Week 10 - Step 4 and Deliverables for Step 3 and 4 ==<br /> * Patches for step 3 and 4. I will high five everyone for the great work done and for the help received :-)<br /> <br /> <br /> = Weekly progress =<br /> <br /> == Final review ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8952 2014-08-26T12:49:38Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.<br /> <br /> == Week 3 ==<br /> This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.<br /> <br /> Testing the serialization is specified for each option. For example, there is the code for the Timestamp option:<br /> void<br /> TcpOptionTSTestCase::TestSerialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> opt.SetTimestamp (m_timestamp);<br /> opt.SetEcho (m_echo);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;TS isn't saved correctly&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;echo isn't saved correctly&quot;);<br /> <br /> m_buffer.AddAtStart (opt.GetSerializedSize ());<br /> <br /> opt.Serialize (m_buffer.Begin ());<br /> }<br /> <br /> The value saved on the TcpOptionTS class are then written into a buffer, which will be read in another method, called (with a great focus on fantasy) TestDeserialize.<br /> <br /> void<br /> TcpOptionTSTestCase::TestDeserialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> Buffer::Iterator start = m_buffer.Begin ();<br /> uint8_t kind = start.ReadU8 ();<br /> <br /> NS_TEST_EXPECT_MSG_EQ (kind, TcpOption::TS, &quot;Different kind found&quot;);<br /> <br /> opt.Deserialize (start);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;Different TS found&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;Different echo found&quot;);<br /> }<br /> <br /> Various test are been proposed in the test suite.<br /> The code for TCP HighSpeed has been written following the RFC 3649. It consist in an extension to TCP New Reno, which deal with great congestion window. So, in the implementation, a NewReno derived class is created, and the methods NewAck and DupAck have been reimplemented to follow the RFC specifications.<br /> <br /> == Week 4 ==<br /> Hi all!<br /> <br /> In these days I worked on the HighSpeed implementation, spotting and<br /> (hopefully) fixing a problem.<br /> <br /> Other works done:<br /> <br /> * Testing the Timestamp option, writing down tests<br /> * Using the timestamps to calculate RTTs for packets<br /> <br /> == Week 5 ==<br /> Hi all!<br /> <br /> As for the things done, in this week I've produced the following thing:<br /> <br /> * Minor bug spotted in the TCP HighSpeed implementation<br /> * RTT test finished.. and the Timestamp class is working!<br /> * TCP Hybla implemented (but not committed yet.. see below)<br /> <br /> == Week 6 ==<br /> In this week I worked on the documentation part of TCP Hybla and<br /> HighSpeed. I've started to test the protocols with DCE, but it is a<br /> work-in-progress (few bug opened on the bugtracker).<br /> <br /> == Week 7 ==<br /> For personal issues, this week has delivered no code, but it has been<br /> interesting on the design point of view.<br /> <br /> I tried solutions for the RttEstimator class, in order to be usable from<br /> other pieces of code (patch - with consequent review - is expected<br /> tomorrow).<br /> <br /> I also have written down a test version of the Noordwijk TCP.<br /> <br /> I've validated the TcpHighSpeed and TcpHybla code versus Linux DCE<br /> (spotting also two minor bugs in the installation of the DCE itself).<br /> <br /> == Week 8 ==<br /> The main point focused were TcpNoordwijk and Rtt Estimator.<br /> <br /> For Rtt Estimator, a mail will follow with a proposal, in the right<br /> thread.<br /> <br /> I've updated the code review for Tcp Option [1] (wrt to Tom's comment).<br /> I also prepared a code review for others tcp variants [2]. Actually, I<br /> have run some test with dce, and the models work well.<br /> A note about TcpNoordwijk: IMHO it isn't in a &quot;ready-to-work&quot; state. It<br /> is public now, so it can be tested, but it should be refined.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8880 2014-07-14T14:58:09Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.<br /> <br /> == Week 3 ==<br /> This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.<br /> <br /> Testing the serialization is specified for each option. For example, there is the code for the Timestamp option:<br /> void<br /> TcpOptionTSTestCase::TestSerialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> opt.SetTimestamp (m_timestamp);<br /> opt.SetEcho (m_echo);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;TS isn't saved correctly&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;echo isn't saved correctly&quot;);<br /> <br /> m_buffer.AddAtStart (opt.GetSerializedSize ());<br /> <br /> opt.Serialize (m_buffer.Begin ());<br /> }<br /> <br /> The value saved on the TcpOptionTS class are then written into a buffer, which will be read in another method, called (with a great focus on fantasy) TestDeserialize.<br /> <br /> void<br /> TcpOptionTSTestCase::TestDeserialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> Buffer::Iterator start = m_buffer.Begin ();<br /> uint8_t kind = start.ReadU8 ();<br /> <br /> NS_TEST_EXPECT_MSG_EQ (kind, TcpOption::TS, &quot;Different kind found&quot;);<br /> <br /> opt.Deserialize (start);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;Different TS found&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;Different echo found&quot;);<br /> }<br /> <br /> Various test are been proposed in the test suite.<br /> The code for TCP HighSpeed has been written following the RFC 3649. It consist in an extension to TCP New Reno, which deal with great congestion window. So, in the implementation, a NewReno derived class is created, and the methods NewAck and DupAck have been reimplemented to follow the RFC specifications.<br /> <br /> == Week 4 ==<br /> Hi all!<br /> <br /> In these days I worked on the HighSpeed implementation, spotting and<br /> (hopefully) fixing a problem.<br /> <br /> Other works done:<br /> <br /> * Testing the Timestamp option, writing down tests<br /> * Using the timestamps to calculate RTTs for packets<br /> <br /> == Week 5 ==<br /> Hi all!<br /> <br /> As for the things done, in this week I've produced the following thing:<br /> <br /> * Minor bug spotted in the TCP HighSpeed implementation<br /> * RTT test finished.. and the Timestamp class is working!<br /> * TCP Hybla implemented (but not committed yet.. see below)<br /> <br /> == Week 6 ==<br /> In this week I worked on the documentation part of TCP Hybla and<br /> HighSpeed. I've started to test the protocols with DCE, but it is a<br /> work-in-progress (few bug opened on the bugtracker).</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8845 2014-06-30T13:18:11Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.<br /> <br /> == Week 3 ==<br /> This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.<br /> <br /> Testing the serialization is specified for each option. For example, there is the code for the Timestamp option:<br /> void<br /> TcpOptionTSTestCase::TestSerialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> opt.SetTimestamp (m_timestamp);<br /> opt.SetEcho (m_echo);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;TS isn't saved correctly&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;echo isn't saved correctly&quot;);<br /> <br /> m_buffer.AddAtStart (opt.GetSerializedSize ());<br /> <br /> opt.Serialize (m_buffer.Begin ());<br /> }<br /> <br /> The value saved on the TcpOptionTS class are then written into a buffer, which will be read in another method, called (with a great focus on fantasy) TestDeserialize.<br /> <br /> void<br /> TcpOptionTSTestCase::TestDeserialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> Buffer::Iterator start = m_buffer.Begin ();<br /> uint8_t kind = start.ReadU8 ();<br /> <br /> NS_TEST_EXPECT_MSG_EQ (kind, TcpOption::TS, &quot;Different kind found&quot;);<br /> <br /> opt.Deserialize (start);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;Different TS found&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;Different echo found&quot;);<br /> }<br /> <br /> Various test are been proposed in the test suite.<br /> The code for TCP HighSpeed has been written following the RFC 3649. It consist in an extension to TCP New Reno, which deal with great congestion window. So, in the implementation, a NewReno derived class is created, and the methods NewAck and DupAck have been reimplemented to follow the RFC specifications.<br /> <br /> == Week 4 ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8844 2014-06-30T13:17:29Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.<br /> <br /> == Week 3 ==<br /> This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.<br /> <br /> Testing the serialization is specified for each option. For example, there is the code for the Timestamp option:<br /> void<br /> TcpOptionTSTestCase::TestSerialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> opt.SetTimestamp (m_timestamp);<br /> opt.SetEcho (m_echo);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;TS isn't saved correctly&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;echo isn't saved correctly&quot;);<br /> <br /> m_buffer.AddAtStart (opt.GetSerializedSize ());<br /> <br /> opt.Serialize (m_buffer.Begin ());<br /> }<br /> <br /> The value saved on the TcpOptionTS class are then written into a buffer, which will be read in another method, called (with a great focus on fantasy) TestDeserialize.<br /> <br /> void<br /> TcpOptionTSTestCase::TestDeserialize ()<br /> {<br /> TcpOptionTS opt;<br /> <br /> Buffer::Iterator start = m_buffer.Begin ();<br /> uint8_t kind = start.ReadU8 ();<br /> <br /> NS_TEST_EXPECT_MSG_EQ (kind, TcpOption::TS, &quot;Different kind found&quot;);<br /> <br /> opt.Deserialize (start);<br /> <br /> NS_TEST_EXPECT_MSG_EQ (m_timestamp, opt.GetTimestamp (), &quot;Different TS found&quot;);<br /> NS_TEST_EXPECT_MSG_EQ (m_echo, opt.GetEcho (), &quot;Different echo found&quot;);<br /> }<br /> <br /> Various test are been proposed in the test suite.<br /> The code for TCP HighSpeed has been written following the RFC 3649. It consist in an extension to TCP New Reno, which deal with great congestion window. So, in the implementation, a NewReno derived class is created, and the methods NewAck and DupAck have been reimplemented to follow the RFC specifications.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8791 2014-06-24T09:07:33Z

<p>Natale: /* Weekly Reports */</p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.<br /> <br /> == Week 3 ==<br /> This week I've coded the serialization/deseralization test and the Tcp HighSpeed proposal.For the upcoming week, I want to add the testing class to the Tcp HighSpeed, and start to work on Tcp Hybla.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8790 2014-06-24T09:06:00Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/nat/ns-3-dev-socis2014/<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8671 2014-06-15T19:48:23Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/rmartinez/ns-3-dev-ltp<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> * Documented the existing code<br /> * Fixed a bug which could lead to a miscalculation of timestamp<br /> * Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> * snd_scale = log2(rxBuffer.Max())<br /> * adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky :-)<br /> Anyway, that let me to do things like: <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8670 2014-06-15T19:47:22Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/rmartinez/ns-3-dev-ltp<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==<br /> <br /> Imported the patches, and made edit to respect the comments over that changeset (including, but not limited to, enum the TCP Options, clear a little the namespace).<br /> <br /> ==== Initial work for Timestamp and Window Scaling. ====<br /> From a code point of view, each option is an attribute to the TcpSocketBase (for example &quot;Timestamp&quot;) in order to enable/disable the options. Associated with it, there is another boolean value to represent if the option is active or not (the counterpart could not have it enabled). All the semantics is done in methods of TcpSocketBase.<br /> <br /> == Week 2 ==<br /> <br /> Let's start from the easy part:<br /> <br /> - Documented the existing code<br /> - Fixed a bug which could lead to a miscalculation of timestamp<br /> - Code refactoring on TcpOption (objectFactory, and a static lookup table).<br /> Just a little word, for anyone, which doesn't want to look deep in the<br /> code. The solution I'm using is:<br /> <br /> 9.24 + struct kindToTid<br /> 9.25 {<br /> 9.26 - return CreateObject&lt;TcpOptionEnd&gt; ();<br /> 9.27 + TcpOption::Kind kind;<br /> 9.28 + TypeId tid;<br /> 9.29 + };<br /> 9.30 +<br /> 9.31 + static ObjectFactory objectFactory;<br /> 9.32 + static kindToTid toTid[] =<br /> 9.33 + {<br /> 9.34 + { TcpOption::END, TcpOptionEnd::GetTypeId () },<br /> 9.35 + { TcpOption::MSS, TcpOptionMSS::GetTypeId () },<br /> 9.36 + { TcpOption::NOP, TcpOptionNOP::GetTypeId () },<br /> 9.37 + { TcpOption::SACK, TcpOptionSack::GetTypeId () },<br /> 9.38 + { TcpOption::SACK_PERM, TcpOptionSackPermitted::GetTypeId () },<br /> 9.39 + { TcpOption::SNACK, TcpOptionSnack::GetTypeId () },<br /> 9.40 + { TcpOption::TS, TcpOptionTS::GetTypeId () },<br /> 9.41 + { TcpOption::WINSCALE, TcpOptionWinScale::GetTypeId () }<br /> 9.42 + };<br /> 9.43 +<br /> 9.44 + for (unsigned int i=0; i &lt; sizeof(toTid)/sizeof(kindToTid); ++i)<br /> 9.45 + {<br /> 9.46 + if (toTid[i].kind == kind)<br /> 9.47 + {<br /> 9.48 + objectFactory.SetTypeId(toTid[i].tid);<br /> 9.49 + return objectFactory.Create&lt;TcpOption&gt; ();<br /> 9.50 + }<br /> 9.51 }<br /> (...)<br /> 9.81 return 0;<br /> <br /> I suspect that it is the same which gcc is doing by enabling -O2 (and<br /> -O3) flag, but anyway the code look really clean now.<br /> <br /> And then, the two other part, which need some word.<br /> <br /> 1) Window scale<br /> <br /> Implemented the window scale option; it depends on the buffer side. The<br /> main algorithm is (where snd_scale is the scaling factor we send):<br /> <br /> - snd_scale = log2(rxBuffer.Max())<br /> - adv_win = (rxBuffer.Max() - m_rxBuffer.Size ()) &gt;&gt; snd_scale<br /> <br /> In the code, are present some other things to make it RFC-compliant.<br /> <br /> 2) Testing<br /> <br /> I've made the testing cases for the window scaling. The approach I used<br /> is the #define one; the first lines of tcp-wscaling-test are<br /> <br /> <br /> #define private public<br /> #define protected public<br /> <br /> <br /> Wow, that makes me free from encapsulation.. I'm flying free in the sky<br /> :-)<br /> <br /> Anyway, that let me to do things like: <br /> <br /> <br /> Ptr&lt;TcpSocketBase&gt; b = DynamicCast&lt;TcpSocketBase&gt; (sock);<br /> <br /> if (m_configuration == ENABLED)<br /> {<br /> NS_TEST_EXPECT_MSG_EQ ((b-&gt;m_rWnd.Get ()), m_maxSourceBufferSize,<br /> &quot;Miscalculating source window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ ((b-&gt;m_rWnd.Get () &gt;&gt; b-&gt;m_rcvScaleFactor),<br /> b-&gt;m_maxWinSize, &quot;Violating maximum adv window&quot;);<br /> <br /> NS_TEST_EXPECT_MSG_LT_OR_EQ (b-&gt;m_rcvScaleFactor, 14,<br /> &quot;Violating RFC for max value of the scale factor&quot;);<br /> }<br /> <br /> Going deep into TcpSocketBase details and see if all is working properly.</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8645 2014-06-09T08:16:06Z

<p>Natale: </p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/rmartinez/ns-3-dev-ltp<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> * Week 1: Initial report over the status of the TCP extensions, and the possibile changes of original patches<br /> * Week 2: TCP extension implementations<br /> * Week 3: TCP extension test implementation<br /> * Week 4: TCP Hybla implementation<br /> * Week 5: TCP Hybla implementation<br /> * Week 6: TCP HS implementation<br /> * Week 7: TCP HS implementation<br /> * Week 8: TCP Noordwijk implementation<br /> * Week 9: TCP Noordwijk implementation<br /> * Week 10: Safety week: will use it if needed at some point of the plan<br /> * Week 11: Safety week: will use it if needed at some point of the plan<br /> * Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=SOCIS2014TCP&diff=8644 2014-06-09T08:15:08Z

<p>Natale: Created page with &quot;{{TOC}} Return to Summer 2014 Projects page. == Project overview == * '''Project name:''' TCP Versions for Satellite communications. * '''Student:''...&quot;</p> <hr /> <div>{{TOC}}<br /> <br /> Return to [[Summer_Projects | Summer 2014 Projects]] page.<br /> <br /> == Project overview ==<br /> <br /> * '''Project name:''' TCP Versions for Satellite communications.<br /> <br /> * '''Student:''' [mailto:natale.patriciello@gmail.com Natale Patriciello]<br /> <br /> * '''Mentors:''' [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]<br /> <br /> * '''Abstract:''' With regards to transport protocols, and with satellite links in mind, at the moment ns-3 has only few TCP congestion control algorithms (Reno, Tahoe, and NewReno) and no one is targeted for satellite systems. It also doesn't support required extensions to improve performance over satellite's link, like TCP Window Scaling or SACK/SNACK, making it not really suitable to simulate (or emulate) modern satellite-based networks. Anyway, thanks to its modular architecture and flexibility of the entire framework, it is possible to add such extensions and write satellite-focused TCP congestion control algorithms. The goal of this project is to add to ns-3 TCP codebase the required extensions (RFC2488) and various satellite-focused TCP versions, in order to improve the simulator in this field.<br /> <br /> <br /> * '''Code Repository ''': http://code.nsnam.org/rmartinez/ns-3-dev-ltp<br /> <br /> = Approach =<br /> <br /> A list of possible TCP protocols designed for links with high bandwidth-delay product (e.g. satellite ones) to implement on ns-3 are TCP HighSpeed, TCP Hybla, and TCP Noordwijk. As these versions require TCP extensions named in the RFC 2488 (Enhancing TCP Over Satellite Channels using Standard Mechanisms). The approach is to add first such; there is already a pending patch for these features (namely TCP Window Scaling and TCP timestamps, used in RTT Measurement and Protection Against Wrapped Sequences, mandatory over a satellite link) with a series of comments by the community. The goal is to take these set of patches and implement the suggestions of the community, in order to be able to subsequently code the previously mentioned TCP variants.<br /> Each one has some distinctive points: TCP HighSpeed for example change the congestion avoidance phase with respect to standard TCP. To remove limitations of the high RTT, TCP Hybla try to perform like a NewReno connection would with a low reference RTT (for example 25ms). The last, TCP Noordwijk, completely change the paradigm of TCP, from window-based to burst-based. The testing of the code will be driven by DCE, as they are currently present in the Linux kernel (the only TCP to be developed kernel-side is Noordwijk).<br /> <br /> == Development methodology ==<br /> <br /> I will use an iterative-incremental development methodology, each iteration will include implementation, documentation (doxygen style comments, thorough the source code), and testing.<br /> <br /> == Testing approach ==<br /> <br /> This project will have testing and cross-validation against existing implementations. <br /> <br /> First, testing will we performed as part of the development cycle. It will use a test case based approach using the standard methods provided by the ns-3 API in the form of the TestSuite and TestCase classes.<br /> <br /> = Deliverables =<br /> <br /> As final deliverables, I'll present two set of patches which will cleanly apply over the last version of the ns-3 simulator: the first will regards the TCP extensions part, and the second the TCP congestion control algorithms for satellite communications.<br /> <br /> * Deliverable 1 - TCP Extensions<br /> <br /> ::Deliverable 1.1 - General TCP extension support<br /> ::Deliverable 1.2 - Timestamps<br /> ::Deliverable 1.3 - Window scaling<br /> ::Deliverable 1.4 - Test for the tcp options<br /> <br /> * Deliverable 2 - TCP versions<br /> <br /> ::Deliverable 2.1 - TCP Hybla<br /> ::Deliverable 2.2 - TCP HighSpeed<br /> ::Deliverable 2.3 - TCP Noordwijk<br /> ::Deliverable 2.4 - Unit Tests<br /> <br /> *Deliverable 3 - examples : this deliverable will contain several examples on how to install and use the various TCP protocols and options.<br /> <br /> = Schedule =<br /> <br /> Week 1: Initial report over the status of the TCP extensions, and the possibile<br /> changes of original patches<br /> Week 2: TCP extension implementations<br /> Week 3: TCP extension test implementation<br /> Week 4: TCP Hybla implementation<br /> Week 5: TCP Hybla implementation<br /> Week 6: TCP HS implementation<br /> Week 7: TCP HS implementation<br /> Week 8: TCP Noordwijk implementation<br /> Week 9: TCP Noordwijk implementation<br /> Week 10: Safety week: will use it if needed at some point of the plan<br /> Week 11: Safety week: will use it if needed at some point of the plan<br /> Week 12: Safety week: will use it if needed at some point of the plan<br /> <br /> = Weekly Reports =<br /> <br /> == Week 1 ==</div>

Natale https://www.nsnam.org/mediawiki/index.php?title=Summer_Projects&diff=8643 2014-06-09T08:06:46Z

<p>Natale: Added socis2014</p> <hr /> <div>{{TOC}}<br /> <br /> The project coordinates a few summer coding programs in which student developers are paired with mentors to produce code over the summer.<br /> <br /> = Google Summer of Code 2014 =<br /> <br /> ns-3 is participating with four projects in the 2014 [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code].<br /> <br /> * [[GSOC2014AcceptedProjects | List of accepted projects]]<br /> ** [[GSOC2014LteFFR]]<br /> ** [[GSOC2014LTP]]<br /> ** [[GSOC2014Bufferbloat]]<br /> ** [[GSOC2014MulticastIPv6]]<br /> * [[GSOC2014Projects | Project ideas page]]<br /> <br /> = European Space Agency Summer of Code in Space (SOCIS) 2014 =<br /> <br /> ns-3 is participating with one project in the 2014 [http://sophia.estec.esa.int/socis2014/?q=node/16 SOCIS2014 List of Accepted Students].<br /> <br /> * [[SOCIS2014TCP]]<br /> <br /> = Mentored summer projects =<br /> <br /> ns-3 maintainers will mentor additional summer projects (that students will work on using their own sources of funding) on a best-effort basis.<br /> <br /> * [[MentoredProjects2014 | Details]]<br /> * List of mentored projects<br /> ** To be determined<br /> <br /> = Past summer projects =<br /> <br /> * [[SOCIS2013BundleProtocolProject | SOCIS 2013 Accepted Project]]<br /> * [[GSOC2013AcceptedProjects | GSoC 2013 Accepted Projects]]<br /> * [[GSOC2012AcceptedProjects |GSoC 2012 Accepted Projects]]<br /> * [[NSOC2011AcceptedProjects |NSoC 2011 Accepted Projects]]<br /> * [[GSOC2010AcceptedProjects |GSoC 2010 Accepted Projects]]<br /> * [[GSOC2009AcceptedProjects |GSoC 2009 Accepted Projects]]</div>

Natale