Thank you, Matthew! Got more focused. Just a couple of clarifications in pursuit:
2013/4/24 Matthew Toseland <[email protected]> > On Tuesday 23 Apr 2013 21:29:40 Vladislav Sterzhanov wrote: > > Some questions about your would-like expectations for this project: > > > > We do NOT vary packet sizes to maximise throughput under loss/corruption > that depends on packet size. IMHO we should; if there is significant loss > then we should be able to detect the MTU directly even if we can't do ICMP; Since we do not have the access to the IP-headers, this would only effectively work for the IPv6 where the "don't fragment" is the default behavior for a sender. In v4 then we are not able to distinguish whether the packet was dis- and re-assembled while passing through, or it managed to squeeze without splitting, right? Then in v4-case it is not so much about actually detecting Path MTU, but more of determining general optimal packet size, isn't it? But we can adjust the algorithm a bit to reach optimal packet size / performance ratio, since we don't actually care purely about Path MTU value. Did you mean it when talking about maximizing the throughput? >but on wifi there may be other tradeoffs? Not sure about this one - can you clarify it a bit? Or we could have a (potentially priveliged) helper, but it'd need to be a > separate process, and it'd be problematic for installing on linux again for > security reasons (maybe even call out to ping!). Of course any of this > would make the protocol more easily detected, and wouldn't apply to other > transport plugins... > Potentially, we could make this a configurable option for a Really poor connection (low MTU, high latency, poor routers). But will it be effectively-worthy? For me it seems to be a very unpleasant overhead, especially taking into account that the careful implementation of previous idea could handle such situation by itself.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
