{% extends "_layout.html" %}
{% block title %}I2P Status Notes for 2006-02-28{% endblock %}
{% block content %}<h3>I2P Status Notes for 2006-02-28</h3>
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey y'all, time for our tuesday ranting again

* Index
1) Net status and 0.6.1.12
2) Road to 0.6.2
3) Miniprojects
4) ???

* 1) Net status and 0.6.1.12

The past week has seen some substantial improvement on the net,
first with widespread deployment of 0.6.1.11 last Tuesday,
followed by this past Monday's 0.6.1.12 release (which has been
pushed out to 70% of the net so far - thanks!)  Overall, things are
much improved over both 0.6.1.10 and earlier releases - tunnel build
success rates are a full order of magnitude higher without any of
those fallback tunnels, latency is down, CPU usage is down, and
throughput is up.  In addition, with TCP fully disabled, the packet
retransmission rate is staying under control.

* 2) Road to 0.6.2

There is still some improvement to be made in the peer selection
code, as we are still seeing 10-20% client tunnel rejection rates,
and high throughput (10+KBps) tunnels aren't as common as they
should be.  On the other hand, now that CPU load is down so much, I
can run an additional router on dev.i2p.net without causing problems
for my primary router (which serves up squid.i2p, www.i2p, cvs.i2p,
syndiemedia.i2p, and others, pushing 2-300+KBps).

In addition, I'm trying out some improvements for people on highly
congested networks (what, you mean there are people who aren't?).
There looks to be some progress on that front, but more testing will
be necessary.  This should, I hope, help out the 4 or 5 people on
irc2p who seem to have trouble keeping reliable connections (and, of
course, help out those who suffer silently from the same symptoms).

After thats working well, we've still got some work to do before we
can call it 0.6.2 - we need the new peer ordering strategies, in
addition to these improved peer selection strategies.  As a
baseline, I'd like to get three new strategies -
= strict ordering (limiting each peer's predecessor and successor,
  with a MTBF rotation)
= fixed extremes (using a fixed peer as the inbound gateway and
  outbound endpoint)
= limited neighbor (using a limited set of peers as the first remote
  hop)

There are other interesting strategies to be worked through, but
those three are the most relevent.  Once they're in place, we'll be
functionally complete for 0.6.2.  Vague ETA of march/april.

* 3) Miniprojects

There are more useful things to do than I can shake a stick at, but
I just want to draw your attention to a post up on my blog
describing five small projects that a coder could whip up without
investing too much time [1].  If someone is interested in jumping on
those, I'm sure we'd allocate some resources [2] out of the general
fund as a thanks, though I realize most of y'all are driven by
the hack and not the cash ;)

[1] <a  rel="nofollow" href="http://syndiemedia.i2p.net:8000/blog.jsp">http://syndiemedia.i2p.net:8000/blog.jsp</a>?
    blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&amp;
    entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1140652800002
[2] <a  rel="nofollow" href="http://www.i2p.net/halloffame">http://www.i2p.net/halloffame</a>

* 4) ???

Anyway, thats a quick roundup of whats going on afaik.  Congrats to
cervantes as well on the 500th forum user, btw :)  As always, swing
on by #i2p for the meeting in a few minutes!

=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEBKdbWYfZ3rPnHH0RAjncAJ9yk3tZfyfOh/L/IHBhhSMpN3snnACeIpAR
rALo7pJF3TQlZYXxikyKBaI=
=Nzly
-----END PGP SIGNATURE-----


</pre>
{% endblock %}