NGI Assure project: Layer-2-Overlay

TNG Service

• Introduced frags_in_flight flag. With this flag we check if fragments of a PendingMessage are being send right now, to not resend single fragments, but the PendingMessage at once.
• The time to wait for resending a PendingMessage - which was fragmented - is calculated, depending on the number of fragments present, and how much of the PendingMessage was already fragmented.
• ValidationState now contains the addres prefix of the address being validated, because we have to check which communicator gave us the validation response.
• Handling flow control takes used window size into account, together with data loss.
• We do not update queue performance if PendingMessage was resend.
• Changed test case to except 0.5% packet loss.
• Removed misplaced sending of an acknowlegement in udp communicator.
• GNUNET_SERVICE_client_continue was misplaced after receiving CORE Ack, blocking the service.
• Fixed bug when checking, if fragment sub tree is done.
• Fixed bug in calculation of delay for PendingAcknowledgement.
• Fixed bug in calculation of subtree fragment message size.
• Fixed bug that additional queues for the same communicator inherit the validity period.
• Fixed logic bug when searching for QueueEntry matching acknowledgement.
• Fixed misplaced increase of queue length.

Configuration

Performance Measurement

The outcome of the performance measurement was ~66 MByte/s for packets with size of 65000 bytes. To follow up on this measurement one has to get the mean time the packets of 65000 bytes needed to reach another peer, to calculate the data rate, by doing

grep "mean time traveled" 811c040a2_test.out|tail -1

on the log file 811c040a2_test.out of the performance test case. The performance increased from ~24 MByte/s measured with the code revision of milestone 5 by using TCP only to ~66 MByte/s measured with the code revision of milestone 6 for packet size of 65000 bytes using TCP and UDP together. There are still possibilities to increase performance documented as TODOs in the source code.

Synergie with Interpeer Channeler project.

The Interpeer library Channeler and the L2O project have some goals in common. These include independence of the transmission protocol used, congestion control, reliability. Other goals of the Channeler project are not goals of the L2O project, but are already implemented or planned for other layers of GNUnet, such as multiplexing and ordered delivery of packages. There are also goals of the L2O project that are not goals of the Channeler project, such as metadata protection and identity assurance of communication partners. Due to these half overlapping half disjoint targets it is not reasonable that on project makes use of the other as a whole. However, parts of one project may well be applicable in the other. Since the Channeler project is not yet completed, it is not yet possible to identify the interesting parts beyond doubt. Interesting for the further development of L2O is the "Zero-Copy and Buffering" functionality of the Channeler project. This is also planned for future versions of L2O. In conclusion, both projects can benefit from each other. At this point in time, it is still too early to tackle this concretely.