On Tuesday 23 Apr 2013 21:29:40 Vladislav Sterzhanov wrote: > Some questions about your would-like expectations for this project: > > *Path MTU detection*:
(I wrote) > >Yes, a statistical approach is probably the only viable option since > >it's very difficult to set Don't Fragment from within Java. (Is this still > >true with recent versions?). > I mostly thought about it in context of an unpleasant issue with > traditional MTU discovery - on-the-way routers with disabled ICMP > functionality - which can be avoided by implementing something similar to > rfc 4821 (I don't think it'd be an overkill for transport layer). Okay, this looks good. (One problem is the connection setup packets may be too big for some MTUs) > And, all > in all, this kind of per-connection statistics could still be useful in > other aspects of implementation. But the question about DF bit and general > control over IP layer is crucial. Does anyone know, are we still only able > to hard-hack it with native interfaces or it can nowadays be accessed > directly from Java? Intermediate searching has shown > only unfavorable results.. Even if we can set it directly from Java, we'd need an appropriate CAP bit, or to run as root, no? We could call interfaces directly (e.g. with JNA) but then we can't use the other Java socket APIs, although this is less of a problem for packet transports as we only really do 2 calls anyway... 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... There's nothing on java 1.7 DatagramSocket; we can set the traffic class but not the DF flag. (Mostly we want to use 1.6 at the moment) > * > *Congestion control*: Since transport layer behaves in a similar to TCP > way, should the new version of congestion control be also inherited from > TCP or are there any important issues that need to be taken into account > when designing the algorithm? Yes IMHO, it should be close to TCP. Also it'd be nice to have options for rapidly scaling down bandwidth usage when there is other traffic, as some BT clients have. We can be bursty in some circumstances although mostly traffic is fairly level. > > Also, where there any wishes about what can be changed between operating > over a lossy- or stable- link types? Now I'm thinking about > possible varying of packet sizes (which is currently already done > automatically, if I'm not mistaken) and timeouts, retransmit and > acknowledge policies. 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; but on wifi there may be other tradeoffs? > > And, in case somebody has already planned this out roughly - what interface > for configuration should the transport layer provide upwards (ponder over > subsequent implementation of transport plugins)? Currently it goes straight to the global config. > > P.s. I'm not quite sure whether mailing list is the right place to discuss > it. Should I rather ask in IRC? Either is fine. I'm on IRC most of the time but you may need to get my attention, call my name ( toad_ ). Email is better for long detailed arguments. > > Thank you all! 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
