2013/4/17 Matthew Toseland <[email protected]> > > - providing the ability for dynamic detection of the currently > available > > MTU size along the path to the node, making it possible to forecast > nearly > > exact suitable packet size for the connection. (issues > > 0000976<https://bugs.freenetproject.org/view.php?id=976> > > , 0005294 <https://bugs.freenetproject.org/view.php?id=5294>) > > Sounds good. Any ideas how to implement this?
The most straightforward and naive way to do it would be the negotiation about MTU for the connection at the beginning of conversation. It's most major disadvantages are: 1) It's a great overhead in case of send-and-forget and other transient handshakes, where the start-up cost of such detection could easily exceed the amount of useful data sent. 2) Path MTU could vary over time, so we can end up blocking ourselves up if the packets suddenly start being routed over weaker hosts. A bit more advanced path would be to determine the actual MTU as the conversation goes on. We could keep useful connection stats for nodes that we've recently heard from and use it as the indicator for current choice of MTU. E.g. if we receive acks for 90% of requests, why not to try broadening the route? The amount of each reduce/increase can be based on previous MTU values for the node, e.g. a bit mutated dichotomy if we could assume that MTU is more or less stable in borders of single connection. This solves both of stated above problems, but introduces a new one: - Generally, it's a bad idea to keep track of all nodes that we've talked to in decentralized p2p applications; and I'm still not sure about it's significance in FreeNet context. There are many ways to reduce the amount of stored information (forget about inactive for long time nodes, etc.), but they depend heavily on the aims and tendencies of the network that I'm not familiar with right now. 2013/4/17 Matthew Toseland <[email protected]> > > > > > But starting with a plugin, getting that to work and only once the > plugin is production ready, starting a spin off with more features. > > No, I disagree. This is all stuff in a higher layer, that any packet-based > transport plugin (that doesn't provide its own congestion control) might > need. In particular the default UDP transport needs quite a lot of work. > > Obviously *some* more advanced steganographic plugins will need to provide > their own congestion control, PMTU discovery protocols etc. They will be > able to turn off features, or use a separate API. > > But IMHO this proposal is not about transport plugins. It's about > improving the middle layer. Yep, I thought about it this way. Transport plugins are awesome concept but the base should be as effective and usable as it could be.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
