On Saturday 08 Jun 2013 11:09:54 Vladislav Sterzhanov wrote: > 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.
Good idea. > 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. Currently any Freenet packet (NPFPacket.java) contains one full 4 byte sequence number and then a series of 1 byte offsets. So we can acknowledge a largish number of packets, but only if they are close together in sequence number. The previously proposed next steps were (there are bugs for these): 1) allow including packets more than 255 apart (via a bit flag probably) 2) allow sending ranges (again use a bit flag) 3) allow including packets in a range that we've already sent an ack for, if it makes it shorter. > 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. Interesting idea. We could still use relative offsets most of the time for the start of the range. Or if we're only interested in rearranging, we could just send a flag, or a counter, for the number of times when we've received packet n and then received packet n-1? > 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. Hmmm, interesting. There are some delays here; most things get queued for 100ms (coalescing delay). The packet encoding logic is in NPFPacket.java. Where is the retransmit logic now? NewPacketFormat I think? NewPacketFormat.createPacket() is *always* used for sending a packet. We resend at the byte-range level; we never resend exactly the same packet. But we *do* mark packets as failed, and thus resend their contents: NewPacketFormat.SentPacket.lost() is called by NewPacketFormatKeyContext.checkForLostPackets() NewPacketFormat is per-peer, and tracks the messages in flight; NewPacketFormatKeyContext is per-key, and tracks the packets. NewPacketFormatKeyContext.checkForLostPackets is worth a look. I *think* what is going on here is we only implement "slow" retransmission. I'm not sure that the timeout is sensible though, it looks like 1 RTT plus 220ms for coalescing at both ends. So you may want to make changes here... > > 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). It may be worth considering. But it would be very difficult to implement, and we need a fallback. Plus, lots of paths will block it. > > 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. Right, sounds good. See PacketThrottle.java. > After that will come the global traffic prioritization - the part that > seems most difficult right now. Yes, especially given that we have bandwidth limits (which don't always apply to all peers). PacketSender tries to be fair between peers but it's a difficult problem. I think we ended up with a deadline-like system (which isn't necessarily fair, but should usually prevent starvation). Probably there are standard solutions. You may want to make significant changes. > 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. Let me know if you need anything. Hope some of the hints above will help. Please let us know where the repository is when you start coding. Also, it sounds like you are hoping to give some before and after measurements? Is this "in vivo", or could you implement them as unit tests (test/) / integration tests (src/freenet/node/simulator/)? (A few benchmarks are set up this way, and there is support for randomly dropping packets). Thanks! > > Quadrocube
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
