The current FNP protocol leaves a bit to be desired. It has more overhead than we'd like, it can only pad packets with random data (not useful bulk transfers), it doesn't handle small MTUs, and its congestion avoidance isn't as TCP-compatible as we'd like.
The most immediate problem is probably that it would make a transport plugin infrastructure overly complicated. For example, a lot of interesting steganographic transports (VoIP, chat, and video game imitators, for example) have a low MTU. That means the plugins would need to support packet fragmenting and reassembly, or add another layer between FNP and the transport plugins. Neither solution is particularly desirable. Toad and I have talked about this some on IRC. I've written up a partial draft proposal that draws heavily on the old "New protocol" proposal, but makes some improvements (I hope ;) ). You can find it at http://new-wiki.freenetproject.org/User:Evanbd/New_Packet_Format_Proposal . Comments are very welcome, especially from anyone well versed in network theory. We currently have two potential gsoc students who are interested in transport plugins. We should improve FNP in parallel with that, imho. It's also possible that one of them could work on FNP and the other on transport plugins, if there is interest. Evan Daniel
