Two major new-load-management related issues suggest we may want to merge new packet format before new load management is completed - i.e. we will probably merge it before new year. This is partly provoked by my internet connection being in less than perfect health no doubt due to weather. 1. We should probably get rid of turtles, and greatly reduce the inter-block timeouts in the block transmission code. 2. Accepted/Rejected timeouts are complex to deal with and occur frequently on some nodes with QoS issues. The basic issue with both of these is that our current transport layer deals with packet loss fairly poorly. It uses exclusively pull-based retransmission, to be specific. This results in fairly humongous latency spikes.
The other benefits of merging it: - It would allow any MTU for any sized messages. We can then reduce the max packet size a bit, be sure Freenet will respect it, and allow those with specific problems to reduce it further. We can also in the medium term add logic to detect problems with sending big packets and automatically send smaller ones. (Classical PMTU detection is unfortunately not possible). - Significantly better payload percentage - Slightly better crypto. - It's a big step towards stego, although the minimum packet overhead is still large enough that a Skype mimicing transport isn't really feasible. The second item is worth investigating a little. It depends on packet size. There can be different policies: Currently, once we've decided to send a packet (based on size and timers), we send as many messages as will fit (starting with the highest priority, and stopping when we can't add any more at that priority, otherwise moving downwards). Then we pad the packet to disguise what it contains. With the new packet format, the obvious strategy to maximise the payload percentage is to send as big a packet as possible within the MTU. If there is plenty of data queued we will always be able to reach it exactly, so won't need padding (unless we decide to set a lower limit and randomise above it). This also minimises any possible exposure to traffic analysis. The catch is big packets are more likely to be dropped and tend to have higher latency. The other option is if there are high priority messages in the queue, we should pack them into a packet, then pad it, then fill the padding with data from lower priority messages. This was more or less what was originally envisaged when we started with the new packet format. We should probably make this configurable. Zidel, what's left in your view? I will have a look at the remaining issues with your code ASAP.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
