On Sun, Dec 10, 2006 at 10:15:43AM +0100, freenetwork at web.de wrote: > >> - Fixed maximum packet size, at the moment this is 1400-28 (28 being > >> UDP headers). > >> - The above, but can be overridden by nodes who know their local MTU; > >> the overridden maximum sizes would be exchanged on connection setup. > >> - PMTU discovery using native code. > >> - PMTU discovery based on packet loss statistics. We would record the > >> sizes of packets recently successfully sent and lost, and try to > >> identify a threshold below which packet loss is significantly lower. > >> Not sure if this is feasible in the general case. > >> > >> In any case the next step is the new congestion control code, which > >> should make packet loss due to oversize packets being sent less of a > >> catastrophe. The above are on the assumption that we have congestion > >> control. > >> From what I can Google it looks like native code is the only way. > > > >To implement this would be way too much work for the benefit gained, IMHO > > >I suggest leaving it at 1400 with an override setting in advanced > >configuration page. That way if 2 knowledgeable peers both have their > >MTU set to 1476(etc) they can take advantage of it. Also make the > >description on the config page > > >Obviously the code should use the lowest number both nodes on a > >connection say they can handle. I.E. One node manually set at 1476 > >and one node at default of 1400 would use 1400 for that connection. > > I think there's a problem for auto-deteting the max MTU size. > If we use, for example, an algorithm that says MtuSize++ for every packet we > successfully send or receive the slow increase of the UDP packet size is > recognizable by network observers. > > Also a fixed size of, say, 1400 is bad if Freenet is the only application > that sends packets of this size. Also the network structure can be > reconstructed by checking for this packet size. This way it's posible to > follow every MTU=1450-link from node to node to draw the > network topology. > > In my opinion an easy to implement solution (but not optimal in says of max > packet size usage) would be to randomize the packet either every node startup > or even for every transmission, although that might be suspicious, too. But > this way there is no distinctive packet > size to be on the lookout for and also the MTU can be recognized if the node > never received a packet with a randomized packet size greater than x after, > say, 100 packets. Then x is the MTU for this connection and the packet size > randomizer can use x as an upper limit > of the random value range, so there is no packet loss anymore
If we want to look like something else, we'll have to wait until we've decided what that something else is. And randomization everywhere can be analysed statistically, although it's not always a bad thing.. For now we'll just have a fixed limit. In a little while, I will make it configurable and include it in the noderef. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20061211/3dac4b22/attachment.pgp>
