Matthew Toseland wrote: >> * Makes it easier to copy TCP's good bits instead of reinventing the wheel > > Much easier?
Cumulatively, yes. At the beginning of SoC 2006 I thought we could design something much better suited to Freenet than TCP, but we kept coming up against problems that had already been solved by TCP - you found another one recently with the congestion window - and eventually I realised it would have been less work, and less risky, to just copy a well-engineered and well-tested design. (Or, even better, just use it - but I know you and Ian are both opposed to going back to TCP.) >> * Well-defined interface between the transport layer and the FNP layer > > In the sense that messages are never reordered, yes. I was thinking more about modularity - we should, for example, be able to change the link crypto or the congestion control without affecting the FNP layer. > We won't be passing Message's to > transport plugins, certainly not for most transport plugins. We will provide > a framework that makes it easy to write transport plugins, which your plugin > can feed its parameters into. I can't honestly see what kind of API you could wrap around the current system that wouldn't require each transport plugin to reimplement major parts of the node. When I talk about a well-defined interface I'm thinking of something like the BSD sockets API or the J2ME Connector API: pass the transport plugin a string identifying an endpoint, get back a failure code or an InputStream and an OutputStream. >> * Transport layer problems like small MTU can be isolated from FNP > > Messages really ought to be small. This will be the case with the changes I > have suggested: e.g. SSK data (including headers) will be a stream. That's great, I do think those changes are a good idea, but why stop there? Why not make everything a stream? >> * Makes it easier to write stego transports > > Marginally. A lot of interesting stego tranports are packet based. Right, but they'll still need retransmission and congestion control, so we can either reimplement it in each plugin or implement it once on top of all the plugins. With the current system it seems like each plugin would have to handle encryption, authentication, congestion control, etc... > Would you still have packet level retransmission, or some sort of range > retransmit scheme? What exactly does TCP do? AFAIK it retransmits ranges rather than packets, because the MTU can decrease during path MTU discovery. > If we send a packet which is > over the safe packet size, what happens? Is it exactly the same as it is now? Unfortunately so - I don't think there's a way to get the path MTU in Java, so you basically have to guess, and the only really safe guess is 512 bytes. > In the current scheme, we'd send the rest of the maximum window, and timeout > and have to resend it; that's what would happen in the new scheme too. Not > the congestion window, the maximum window (128 packets now, 64k with the new > transport layer). So we can keep sending messages while we retransmit the > packet repeatedly, and eventually give up on it, tell the other side that, > and split it up and send the messages in smaller packets. In your scheme, > what happens? This is probably the worst case in terms of increased latency. Big packets will be fragmented rather than dropped, and occasionally all the fragments will get through. That's the problem, in a way, because if big packets were always dropped we could work out the MTU for ourselves. > Reasonable, yes. But it will always be more than a real out of order > transport. OK, but how much is that little bit of extra performance worth? You've said yourself that Freenet isn't low-latency - unlike Tor, which uses TCP. ;-) Cheers, Michael
