Matthew Toseland wrote: > RFC 2861 is rather late in the day for TCP. If we had set out to copy TCP we > would likely not have seen it.
So what's your point - that because TCP has bugs, anything that's not TCP won't have bugs? We're the only people looking for bugs in Freenet. Lots of people are looking at TCP. > Not possible. Well, maybe with transport plugins we'd have it as well as UDP, > but our primary transport will be based on UDP for the foreseeable future, > because of NATs. TCP NAT traversal is nearly as reliable as UDP now, and likely to get better as new NATs implement the BEHAVE standards. Plus we have UPnP (yes, it's ugly and unreliable, but it's better than nothing) and NAT-PMP. Again, a lot of other people are working on this. > Why should either affect the FNP layer? The link crypto won't affect it now. True. > The congestion control does, but won't with the new transport layer because > in the new transport layer all messages will be subject to congestion control > and output limiting. Even with the new transport layer, congestion control needs to be aware of weirdness caused by not splitting messages across multiple packets. For example the fix in RFC 2861 wouldn't work because sometimes we don't use the whole window even though there's data waiting, because there isn't room in the window for a whole message. > Transport plugins are of no use if it takes six months to implement and debug > one. Yes, exactly... > Obviously we will need several different interfaces for different classes of > transport. Agreed - maybe three classes: "IP-like", "TCP-like" and "TLS-like". The first just provides an unreliable flow of (possibly very small) packets. The second provides a reliable, ordered, congestion-controlled stream. The third provides an encrypted, authenticated, reliable etc stream. Then we have a default TLS-like layer that can use any TCP-like plugin, and a default TCP-like layer that can use any IP-like plugin. > AFAICS all you need > to do is pass in some information about the desired packet sizes, which the > node will then try to meet on outgoing packets (just as in my proposal you > are replying to), and it will pass packets to the plugin. TCP exists for a reason: so applications don't have to worry about stuff like packet sizes. Let's say we have an RTP plugin that can only deliver 160 bytes per packet. Should we redesign FNP around the needs of the transport plugin? No, we should have a layer in between. >> 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. > > No, that's not the problem. That sucks, but it doesn't suck as bad as the > REAL > problem, which is that for a lot of connections, fragmented packets are > dropped, either more often, or more usually always, because of hardware > firewalls along the route. Exactly - if they were always dropped we could work out the MTU by gradually increasing the packet size, but because they sometimes get through we just see horrible performance. Maybe we could guess the MTU by recording the sizes of dropped packets and looking for a threshold, but once again we'd be reinventing the wheel - TCP already discovers the path MTU. Anyway I can see I'm not going to convince you to switch to TCP or even a TCP-like transport, I just wanted to throw the idea out there one last time before you rewrite the transport layer. Cheers, Michael
