On Wednesday 24 Apr 2013 21:48:41 Vladislav Sterzhanov wrote: > 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?
Well there are 2 problems: First, a path may drop packets over a given size. Second, a path may fragment them, and thus increase the chances of losing a packet greatly, while not necessarily losing them. > > >but on wifi there may be other tradeoffs? > > Not sure about this one - can you clarify it a bit? I mean on wireless you might have more packet loss on bigger packets because of more errors - independant of MTUs. > > 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. > We have a config option for MTU, and we detect it from the interface. I agree that detecting PMTU "properly" is probably a bad idea though.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
