On Wednesday 02 December 2009 14:13:14 vive wrote:
> It sounds like matching newly arrived nodes to free opennet slots works bad.
> If I understand the source correctly, this also seems natural in the current
> setting. Since after some time of network operation, most nodes will have
> announced and gotten their desired number of opennet peers. There will still
> be a steady inflow of announces and requests, which makes arriving or
> existing nodes compete and grab the slots whenever they are open. Therefore,
> increasing /both/ the number of desired and available opennet connections is
> not going to fix the problem: they will quickly be consumed by dynamics in
> the existing network. We should consider how there could be more available
> slots than the established nodes themselves require.
>
> I propose to discuss the following solution, based on separating normal
> ("persistent") opennet connections, and announcements:
> Nodes keep announcing as before. But let every opennet node offer a small
> number of temporary slots, say 3, that it does /not/ use itself for path
> folding but it only offers to announcing opennet nodes. The announcing nodes
> would then get a better chance to establish themselves during a short time
> window. These temporary slots could be FIFO/LRU-dropped after 1 minute upon
> new announcements from other opennet nodes, or automatically after 10 minutes
> to reduce the burden on nodes. When there are free persistent slots, nodes
> should offer these instead than temporary ones. But when there are no
> persistent slots to offer, tempoary ones are offered for a short while. Newly
> arrived nodes only use these up to, say, maximally 10 such temporary
> connections simultaneously - and drop them as they operate and get persistent
> connections.
>
> I think this scheme has the following benefits:
>
> 1. Give newly announcing nodes a chance to get onto the network (to get
> opennet connections that are persistent, rather than temporary ones, by
> routing as well as announcing).
>
> 2. Prevent established nodes to consume the available slots using requests,
> since they do not desire more than their persistent ones.
>
> 3. Allow newly added opennet nodes to receive requests and path fold with
> each other.
>
> (Perhaps nodes also need to become more greedy about getting these temporary
> connections close to its identity key.)
>
> Does this sound interesting? If interesting enough, I could try to simulate
> this.
>
> Cheers,
> /vive
>
>
> On Fri, Nov 27, 2009 at 05:36:09PM +0000, Matthew Toseland wrote:
> > The question boils down to why do the vast majority of nodes on an
> > announcement chain reject the announcement. The answer appears to be:
> >
> > Most of the time, we reject a new node (from path folding or an
> > announcement) because we only drop a connected peer every 10 minutes, even
> > if it is isDroppable(). Of course, we drop disconnected isDroppable() peers
> > (= peers that disconnected more than a few minutes ago) very quickly, but
> > most peers are usually connected.
> >
> > Generally there are peers we could drop according to isDroppable() (more
> > heuristics, e.g. don't drop a node if we added it less than 5 minutes ago),
> > but we don't drop them because of the 10 minute throttle.
> >
> > Also, we only drop a connected peer after every 10 successful requests.
> > This appears not to be very significant on my node however.
> >
> > Thoughts? evanbd suggested a token bucket for the intervals in
> > OpennetManager - we have two, this one and one for adding
> > old-opennet-peers. This would allow more burstiness.
> >
> > Or we could scrap the 10 minute interval altogether (or cut it drastically)
> > and rely on the 10 successful requests criterion?
> >
> > Anything we do to opennet may disrupt the network if we get it wrong, and
> > even if it's right it may take time to settle...
>
There are several problems here:
- Announcements are slow and inefficient: We send announcements to several
seednodes, these pass through hundreds of nodes, and the vast majority reject
them. Eventually we get some connections, and through those connections we get
more connections.
- Most announcements, in normal circumstances (i.e. not during a slashdot), are
from existing nodes that have been offline for a while. Reconnection to
existing peers can serve the same function, however on many nodes this won't
work due to NATs (or will be slow and only work after we have some connections
e.g. ARKs), and on those where it could work, it doesn't because reconnections
are treated the same as announcements and path folding - the vast majority are
rejected.
- So there are worries both about announcements being crowded out by path
folding, reconnections being crowded out by announcements and path folding, and
in general the algorithm for deciding whether to connect not taking into
account what sort of connection it is. This can be resolved by reserving slots
somehow. IMHO these slots should not be additional to the peers limit, they
should be included in it; and when nodes exit their grace periods they should
be treated as any other node i.e. dropped if we need the slot and they are at
the bottom of the LRU list. Hence, the proposal is to have limits on the number
of nodes that may be in their grace periods for each category - path folding,
announcements and reconnects. In a given category, if we reach the limit, we
summarily reject new connections of that type. We would need to pick arbitrary
limits for each category e.g. 2 announcements 2 reconnects (max_peers - 4) path
folding. The numbers must add up to no more than the peers limit, but whether
they should be less than it or equal to it I am not sure of. This mechanism
could slow down announcement during slashdottings, and in fact at other times,
but at least it would keep path folding working; it would likely make
reconnections much more successful. Overall I hope it would be an improvement
in performance even in terms of time to connect newbies, but it does involve
alchemy in the parameter setting.
- The code is overly complex with regards to dropping disconnected, droppable
peers. We should count the number of peers which are either connected or are
not droppable, and if this is less than the peers limit, accept the incoming
peer unconditionally. If it isn't, we need to apply the above logic.
- Currently the dominant reason for us to reject a connection is the fact that
we only drop a connected opennet peer (whether it is in its grace period or
not) every 10 minutes. This limit should probably be significantly reduced, and
should apply separately to each category e.g. a new announcement connection can
only kick out an existing connection every N minutes. We have a similar limit
based on the number of successful requests since we last dropped a connected
peer. We might want this to apply just to path folding, or to apply for each
category, maybe with different limits.
It looks like improving announcement is probably going to have to include
alchemy, but well, evanbd and vivee started that, and they're theoreticians,
they can tell us what to set the parameters to :)
Thoughts?
The conversation between me and evanbd (and a little with vivee) on this topic
is on this bug:
https://bugs.freenetproject.org/view.php?id=3753
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20091202/c5ef9ef1/attachment.pgp>
