Set TOS in packet

Summary

The middleware must be able to set the Type-of-Service (TOS) field of the IP header.

Tasks

• Implement a way to set TOS of a packet

Tests

• Check if TOS is set (Wireshark)

Notes

Configuring the TOS field from a service comes later, in sprint 4.

Testing with netem

Summary

During this sprint we need to start testing the API and service using netem (and possible Scapy?)

Tasks

• Set up netem and send normal data
• Add more tasks when we know more.

Tests

This is a "test" in and of itself, so it doesn't make sense to test the test, so to speak.

Notes

Should test all different kinds of situations that one might encounter:

• complete disconnects and buffering for it to send at "a later date"
• frequent disconnects
• very slow bandwidths
• high latencies
• more?

I have a rack server that I can use for testing, going to look into this. - Ola J.

Documentation of the API in the README file

Summary

Short summary of the issue.

Tasks

• Architecture and how the middleware works
• Technical description of the fragmentation header / proprietary information
• Description of endpoints and what they do
• Example code snippet
• Configuration options and what they do / how it interacts with the underlying system.

Multicast support for the middleware

Summary

It would be nice for the middleware to have support for multicast over networks that might not support it natively.

Tasks

• Creation, configuration and leaving of multicast groups
• Support for multicast (duh)

Tests

• Test that all clients in the group get the data

Notes

Not to my knowledge.

TOS field not set properly

Summary

When calling setsockopt(IPPROTO_IP, IP_TOS, tos), getsockopt(IPPROTO_IP, IP_TOS) does not reflect this value on tcp sockets.

Tasks

What tasks should be solved, for this issue to be complete?

• Set TOS field on tcp sockets

Tests

What test cases should be implemented for this issue to be completed?

• Ensure TOS is set correctly and that both get_tos and outbound packets reflect this value

Increase ease of deployment

Summary

Relates to #16. The Middleware should be deployable easily, by non-developers. Documentation should be at a level where someone outside the dev-team can use the middleware. Deploying the middleware and getting a test service up should be relatively quick, not requiring too many commands.

Perhaps some shell scripts for deploying each service (which does poetry set up etc.)

Tasks

What tasks should be solved, for this issue to be complete?

• Implement whatever

Tests

What test cases should be implemented for this issue to be completed?

• Test whatever

Notes

Anything else?

Defragmentation bug

Summary

Our current custom header makes it impossible to defragment the packets on the receiving end, as we do not know where one packet ends and another begins in the bytestream. To fix this the header must include a length field so we can identify where one packet ends and another begins.

Tasks

• Expand the header with a 2byte length field. Must also be included in the Packet header, not just fragment header.
• Adapt the middlewareApi to make use the length field for defragmentation.

Tests

• Test that it works correctly.
• Either rewrite existing tests, or add new ones that check that checks that the entire fragmentation process works, that is "data->packet->fragments->bytestream->fragments->packet->data. Current tests, do not check the middle part.

Notes

New header format.

Config initialization

Summary

The config system must be initialized before use. "load_config_from_file" must therefore be called at middleware startup both during actual use and testing. Currently this is not done at middleware startup, and during testing it is only done when the config system is tested.

Tasks

• Decide on when the config should be loaded and actually load it
• Decide on what config should be used during testing and ensure the corrent one is loaded before tests (except config tests) are run
• Ensure no config is loaded before the config tests are run

Tests

• Tests actually work when the config is both loaded and used

Improved fragmenting

Summary

Including the entire final fragment number with each packet is inefficient, and increases overhead while limiting the number of fragments we can include in a sequence. It should instead be possible to indicate the final fragment in a sequence by setting a single bit flag instead (as is done in IP fragmentation).

Secondly, the current reassembly code is somewhat fragile, as it requires a list of fragments presorted by identification to successfully reassemble a packet. It would be nice if the fragmenting module could handle processing fragments, and any other part of the program just needs to send any mix of fragments to this module (even if incomplete), and receive finished packets back whenever they are ready.

Tasks

• Implement the new header format.
• Improved reassembly.
  • FragmentSequence class - For storing partially reassembled packets.
  • Reassembly of mixed packets / fragments and mixed identification.
  • Configurable timeout of old fragments.
  • Separate FragmentSequence() instance for each sender.
    • Sender identified by IP+port.
  • Collect statistics about discarded fragments, and provide interface to query them (e.g. percentage of packets lost due to missing fragment during reassembly).
• Integrate with changes from #6
• Refactoring
  • Be consistent with naming. Packet id and identification is both used interchangably currently. Borrow the "identification" label from IP fragmentation and use it everywhere.
  • Move the public interface for fragmentation and reassembly to its own class: Fragmenter class.

Tests

• Test cases for various fragmentation and reassembly scenarios, using the new interface.
  • Simple ordered fragmentation/reassembly.
  • Unordered fragmentation/reassembly.
  • Mixed packet fragmentation/reassembly.
  • Mixture of many packets/fragments reassembly in multiple calls to Fragmenter.process_packets(): Should represent a realistic scenario of real world use.

Notes

New header format:

Questions

• Do we want configurable timeout of packages on a per destination application basis?
• Memory usage, buffering a lot of partial packets will eat memory. Have to experiment with timeout.

Fragmentation of large packets

Summary

When trying to send data that's larger than the configured MTU, the middleware should fragment the packet and send multiple packets through the socket. This is not something the socket should do, but rather the middleware.

Tasks

• MTU
• Fragmenting the data (chopping it up)
• Assembling the data (putting it back together)
• Creating multiple packets
• Inserting headers? (If using UDP, insert proprietary header)
• Buffering of packets waiting to be sent

Tests

• Using configured MTU
• Correctly fragments data
• Correctly assembles data
• Headers inserted in each packet
• All buffered packets sent

Notes

It could be interesting to think about how this should be represented in the header of the packet.

Network information configuration and service info

Summary

Through file config and/or API, the middleware needs to be able to set different parameteres about how it behaves and what it should know about the network as a whole.

Tasks

Configuration for:

• MTU
• Retransmission delay

Config for expected:

• Congestion
• Bandwidth
• Packet loss
• Jitter?

The service must configure:

• TOS-value

Tests

• Configuration getting applied as intended

Notes

Expand tasks when we know more.

API outline

Summary

To be able to use the middleware and test it, there needs to be a basic outline of an API that services can use.

Tasks

• Sending endpoint
• Receiving endpoint / wait call?
• Decide on configuration endpoints and meta-information about the network to be communicated with the service

Tests

• Sending small data, like text
• Sending large data, image?
• Receive text / image data

Notes

This should be expanded upon later, but for sprint 3 we need to have something basic for sending and receiving.

First product release

Summary

First product release should be created on Github, and made available.

Tasks

What tasks should be solved, for this issue to be complete?

• Implement whatever

Tests

What test cases should be implemented for this issue to be completed?

• Test whatever

Notes

Anything else?

Documentation

Summary

Make sure that all documentation in the product is up to date. This includes docstrings, readmes, etc.

Tasks

• Readme for middleware.
  • Add a paragraph about the preconfigured configs, perhaps just table 9 from the report.
• Readme for example service.
• Docstrings.
• Readme for test-service.
• Licence (MIT).
• Reference the documentation in the report.

Har testet mellomvaren med en video tjeneste, men jeg har litt problemer med å sende når jeg bruker MiddlewareReliable. Det virker som at noen av pakkene ikke kommer frem til den tjenesten som skal motta, som gjør at videoen ikke blir helt jevn. Dette er testet mellom to maskiner på samme nettverk. Testing med MiddlewareUnreliable har fungert uten problemer.

Jeg har lagt ut koden til video tjenesten på Github som dere skal ha tilgang til (den er public). Det er bare å bruke denne til testing og gjøre endringer dersom dere trenger det. For å hente inn mellomvaren brukte jeg poetry som beskrevet i example-service. Det er bare å si fra hvis det er noen problemer med oppsettet.

https://github.com/EPA1/simple_video_service

Reliable communication

Summary

The middleware needs to be able to use reliable communication, like TCP, for services that need it.

Tasks

• Retransmission
• ACKs
• Buffering and receive / send windows
• Detect packet loss

Tests

• Transmission of data and ACKs
• Data gets properly designated as ACKed
• Retransmission in poor networks according to configuration

Notes

Expand on this description

Test service

Summary

Configurable test service for sending a lot of random data according to some configuration (eg. lots of small packets/a few big packets / reliable/unreliable / burst/regular interval. For received data, send back a hash of the data to source to allow for verification. Collect statistics about the provided service, and report it.

Should allow for systematic testing of many network patterns, and realistic sending patterns.

Tasks

• Controller
  • Load test configuration from config file and configure worker(s).
    • Simple port discovery when connecting to workers.
    • Configuration should support setting a distribution of packet size to send, what type of connection to use (reliable/unreliable) and whether traffic should be spaced evenly or in bursts.
  • Run tests and collect statistics.
  • Reporting of test results
    • RTT, packet lost, retransmission overhead, amount of data received/sent on either end, etc.
    • Console
    • HTML report (??)
• Worker
  • Receive and set configuration from Controller
  • Echo data as well as measured statistics to Controller.

Tests

• Verify that the correct data is being sent and received
• Verify correct statistics

Notes

Anything else?

Fix hardcoded config.ini path

Summary

Currently we load config.ini from a hardcoded path ("middleware/configuration/config.in"). This only works when running the program from the ./middleware/ folder, and otherwise it will error out the ass.

We should support a commandline parameter to set the configuration file path eg. "--config config.ini", and fall back to "config.ini" in the current working dir, if not provided. This relates to #26 #31.

Tasks

What tasks should be solved, for this issue to be complete?

• See above.

Tests

What test cases should be implemented for this issue to be completed?

• Test whatever

Notes

Anything else?

TCP maxseg might not control packet size

Summary

In testing related to the Emil issue, we discovered that the middleware seemed to disregard configured MTU when using reliable connection. This might be bacause of Thorbjørns whacky OS (not ubuntu), but worth investigating.

Tasks

Tests

What test cases should be implemented for this issue to be completed?

• Test Emil service and monitor with Wireshark with Ubuntu

Notes

It is also possible to set interface MTU with "sudo ifconfig <interface> mtu <mtu>", but this will restrict MTU for all traffic across the interface, not just MW connections. This is also capped to a minimum of 1280 if ipv6 is enabled.

Send and receive data using TCP

Summary

Implement a program that can send and receive TCP packets using the decided python package.

Tasks

• Decide on which python socket (scapy/sockets) library to use.
• Send some data.
• Receive data.

Tests

• TBD

Failing tests due to default configuration as of merging #49

Summary

Pipeline fails due to missing Vegas congestion algorithm on Github's Ubuntu workers (see comment in #49).

Tasks

• Fix the problem by (a) changing the default configuration to use a congestion algorithm available on the worker or (b) use a test-specific custom configuration.

Tests

What test cases should be implemented for this issue to be completed?

• Test whatever

Notes

Anything else?

Pytest random failure when running in Github actions, even though they work locally.

Summary

It appears that pytest randomly fails when running on Github Actions sometimes. This occurs even if the tests run fine locally.

If this happens you will see a Timeout error in the pytest output of the failing task.

A workaround for now is to simply rerun the test until it succeeds.

Tasks

• Implement whatever

Tests

What test cases should be implemented for this issue to be completed?

• Test whatever

Notes

Anything else?

Bug in fragmenting packet when size<MTU

Summary

Fragment.fragment fails when attempting to fragment a packet that doesn't get fragmented because its size is smaller than the MTU. In this case intended behaviour is that the original packet is returned.

Tasks

• Fix bug where fragment() does not return original packet when packet size<MTU.

Tests

• Add testcase to verify that fragmenting a packet with size<MTU returns the original packet as intended.

Notes

Anything else?

We need a good, high-level diagram of the architecture of the project. Will be useful for the report as well. NEEDS to be done by prelim. deadline!

Before we begin working with any code, it's probably a good idea to set up a Docker image, or some sort of easy deployment method, as per the request of FFI.

TCP tuning

Requires #27

Summary

For release 2, FFI wanted a tuned TCP to begin testing on their NATO radio emulator. This needs to be done in order to start satisfying their needs.

Tasks

• Test different TCP settings

Tests

Nothing; this is research based and should only result in findings about TCP and network environment variables. For testing of the demo suite, see #27.

Use service to send and receive data

Summary

Instead of using some testing code or built-in testing, we should use an actual service to send and receive data to start using the API early.

Tasks

• Build easy, low effort service to use for sending and receiving e.g. text

Tests

• API endpoint connection works as intended
• Takes user input
• Gives expected output from network

Notes

None.