So it's time for the first community report from me. During the last week I was delving into the countless standard and experimental RFCs to build up a skeleton for the future work. The first modification that has come to mind is "selective acknowledgement" in the TCP terminology, though it's more "cummulative" than the one freenet utilizes right now. It's described in RFC 2018<http://datatracker.ietf.org/doc/rfc2018/>and can be tweaked even more, taking into account that freenet node protocol doesn't care about the order in which packets are received. There is a vast number of possible advantages of this technique including faster acknowledgement, reducing the amount of unneeded retransmits and increasing the payload of transmitted packets. Then came the idea that smoothly enchances the previous one - if, as proposed in the document, we will always sort the acknowledged ranges in the ack-part of the message in order they were received on the receiver-side than we could judge upon how often the link used for a connection rearranges the packets. This, in turn, will assist the retransmission policy - currently, over a link which does not preserve the order of the sent packets, the current fast retransmission strategy "got ack for n+3? -> retransmit n, if it's not acked" can cause a huge number of spurious retransmits. In general, the direction of acks and retransmission strategies seem to be the fertile space for improvements - there are already some ideas that possibly can be improved, but I need to first of all get to know how they are currently implemented in FNP.
Though some of usefull standards require tweaking the layers beyound fred's competence (e.g. mentioned earlier PMTU detection algorithm which needs to alter the DontFragment IP flag; or this ieee paper<http://www.ee.kth.se/~niels/papers/cdc2004.pdf>on the tcp-over-wifi, which adds the required functionality to link layer) there are some thoughts about how to adopt them for our needs. (Although I'm still not really sure whether it's so undesirable to stamp messages with DF bit - the technique is in wide use nowadays so perhaps it'd even improve the "message conspiracy" instead of diminishing it. Potentially, this could turn out to be a viable and usefull option for the current needs). Currently I continue the search for the ways of direct one-side improvements for the protocol, the next focus will be on the wifi-related direction - how to make the actions of freenet's congestion control algorithm more reasonable and concious when opertaing over wireless networks. After that will come the global traffic prioritization - the part that seems most difficult right now. If you would like to emphasize my attention on something or you have something important and\or usefull for me to know\read\study about - I'm open for help and guidance. Quadrocube
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
