15:11 < jrandom> 0) hi
15:11 < jrandom> 1) Net status and 0.6.1.12
15:11 < jrandom> 2) Road to 0.6.2
15:12 < jrandom> 3) Miniprojects
15:12 < jrandom> 4) ???
15:12 < jrandom> 0) hi
15:12  * Complication quickly reads notes
15:12  * jrandom waves
15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html
15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting!  ;)
15:13 < jrandom> ok while y'all read those oh-so-exciting bits, lets jump on in to 1) Net status and 0.6.1.12
15:14 < jrandom> as mentioned, the primary goals of the 0.6.1.10-0.6.1.12 releases seem to have been met, addressing the tunnel creation crypto change and improving creation reliability substantially
15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again
15:16 < jrandom> anyone have anything else to bring up for 1) Net status and 0.6.1.12, or shall we mosey on over to 2) Road to 0.6.2?
15:17 <+Complication> Net status over here: no more going back under 20 KB/s :)
15:18 < jrandom> cool, yeah 0.6.1.12 fixed a pretty large bug in 0.6.1.11 where it wouldn't exploit the bandwidth available.  it should now make better use of available resources
15:20 < jrandom> ok, lets jump on to 2)
15:20 < jrandom> as mentioned, there are a few things that need to get sorted before the last functional change is put in place for 0.6.2, but we're making progress on that front
15:20 < nymisis> net status is fine :)
15:22 < jrandom> word.  there'll be more info available on the specifics of the new peer ordering strategies before they come out, but the gist of them should be clear from their brief mention in the notes
15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2?
15:23 < postman> jrandom: any testnets this time?
15:24 < postman> (need any routers, particpants to test stuff)
15:24 < postman> ?
15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data
15:25 <+Complication> Sounds like a fairly desirable feature
15:25 < jrandom> postman: the new stuff should work transparently on the live net using local-only info, so shouldn't need a separate net to test
15:25 < jrandom> aye, exactly Complication 
15:26 < postman> ok
15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :)
15:27 < blubb> 1 april
15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april
15:27 < postman> hehe
15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;)
15:29 <@cervantes> more like an mi6 catflap
15:29 <@cervantes> (budget cuts)
15:29 < postman> in an elephant house
15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :)
15:30 < jrandom> well, lets just call them Them ;)
15:31 < jrandom> ok, anything else for 2)?
15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects
15:31 <@cervantes> sorry "the firm"
15:34 < jrandom> ok, I just wanted to point out a few neat things that would be 1) simple to do and 2) really useful
15:34 <+Complication> On the miniprojects side, I'm not sure if my Syndie reply made it or not, but I'm wondering if I could snatch one.
15:34 <+Complication> Not sure which one yet. Currently practising a little more Java (doing a micro-project :D) just to have added certainty that when I try, I'll be able to handle one
15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed?
15:35 <+Complication> When I get ready with the "micro-project" (assuming of course the table hasn't been cleared yet), I'll try picking one
15:35 < jrandom> w3wt, great Complication 
15:36 < jrandom> DeltaQ: immediately 
15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler
15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over)
15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs
15:37 < jrandom> cervantes: hmm, not necessarily.  1) is pretty focused, and also includes pushes, while 4) is prety generic
15:37 <+Complication> cervantes: sounds like it could
15:37 < jrandom> but yeah, the engine behind both is EepGet
15:37 < jrandom> (eepget does syndie's http transfers, programatically)
15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s
15:38 < DeltaQ> i set 64kb/s with 192 burst down
15:38 < DeltaQ> 32/64 up
15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api...
15:39 <@cervantes> still, in probably ceases to become a mini-project at that point
15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate
15:39 <+Complication> sorry, s/average/actual bandwidth
15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though.
15:40 < DeltaQ> heh it finally went up
15:40 < DeltaQ> 1s: 30.82/29.33KBps
15:40 < DeltaQ> guess i needed up upp the ul bw
15:40 < jrandom> DeltaQ: the average will also be affected by how other people view you, which depends upon your actions, not any advertized rate, so it'll take a bit
15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out
15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two
15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity
15:42 < DeltaQ> oki
15:43 <+Complication> If they think it can route well, they'll ask more often
15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ???
15:43 < jrandom> anyone have anything else to bring up for the meeting?
15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc
15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy
15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^
15:44 <+Complication> Someone asked the other day, about possible attacks based on clock skew. I think I saw your answer about the tunneling part (creation message holds only tunnel validity period, not time from its creator's perspective)...
15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_
15:46 <+Complication> So I thought, actually, about asking... which points if any at all, in I2P messaging, could contain time from a sender's perspective?
15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it
15:47 < jrandom> Complication: nothing explicitly says "I think it is now $time", but with sufficient traffic and timing analysis, one could likely narrow it down substantially
15:48 < jrandom> we do quantize the times at a large period, though not as large as our max clock skew, so there is room there
15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client?
15:49 <+Complication> One which would / could easier keep skews smaller?
15:50 < jrandom> well, since the sntp client was introduced into i2p, its been getting better and better so that now we don't see the variation we used to
15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less
15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews
15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value?
15:53  * Complication doesn't know which way would be more practical, just suggesting random possibilities :D
15:53 < jrandom> no, we know the clock skew of directly connected peers
15:55 < Magii> is there anyway to tell if the update was done successfully?
15:55 <+Complication> Aha, so session protocol really depends on that info..
15:55 < tethra> look at your version number
15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs
15:55 < tethra> :/
15:55 <+Complication> Then, it should count down minutes to a graceful restart
15:56 <+Complication> And finally restart
15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"?
15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :)
15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks
15:59 < jrandom> s/sequential/ordered/
15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"?
16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject?  :)
16:00 <+Complication> I was thinking of something along those lines
16:01 <+Complication> I guess I'm now thinking a bit more about it :)
16:01 <+Complication> Other miniprojects first, though :)
16:02 < jrandom> ok, anyone have anything else for the meeting?
16:03 < nymisis> Muffins?
16:04 < jrandom> no, pancakes
16:04 < jrandom> (mmMMmm pancakes)
16:04 < jrandom> speaking of which
16:04  * jrandom winds up
16:04 < nymisis> Oh, darn, good point.
16:04  * jrandom *baf*s the meeting closed