13:05 < jrandom> 0) hi
13:05 < jrandom> 1) Congestion
13:05 < jrandom> 2) Streaming
13:05 <+dinoman> pgforge's key has changed :/ sorry
13:05 < jrandom> 3) BT
13:05 < jrandom> 4) ???
13:05 < jrandom> ah cool, we can do some magic for that
13:05 < jrandom> 0) hi
13:05  * jrandom waves
13:05 < ant> <lucky> hi
13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html
13:05 < wiht> Hello.
13:06 < jrandom> (and we got the notes posted *before* the meeting.  w00t)
13:06 < jrandom> might as well jump on in to 1) Congestion
13:07 < jrandom> for people who have been hanging around the channel the last few days, you've heard lots of discussions about wtf has been going on, and both this email and duck's post earlier should cover it generally
13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss?
13:09 < wiht> What do you mean by "wild peer selection"?
13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers
13:10 < jrandom> if those fast peers don't fail occationally, we simply use them, period, rather than explore beyond them in our tunnel building
13:11 < jrandom> that means that when they *do* fail later on, we have pretty much no idea how much capacity the rest of the network has, and as such, choose peers fairly arbitrarily
13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better?
13:12 < jrandom> DrWoo: the 0.4.3 release will include a new way of pooling tunnels so that we can have more 'experimental' backup tunnels (allowing us to learn more about the network without sacrificing performance)
13:13 < jrandom> more aggressive load balancing through ATM-style reservations are also in the pipeline, but aren't plotted at a particular release yet (aka we'll do it when we need it)
13:14 < ant> <Connelly> bleh
13:14 < ant> <Connelly> no meeting yet?
13:14 < jrandom> (ATM-style reservations, as in, keep track of how much bandwidth tunnels use, on average, multiply that by the number of tunnels we participate in, and compare that to our bandwidth limits / capacity, using that comparison to accept / reject further tunnel requests)
13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;)
13:15 <+DrWoo> jrandom: what impact will that have on performance?
13:15 <+DrWoo> local pc performance
13:15  * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT.
13:16 < jrandom> DrWoo: the 0.4.3 pooling will give us greater resiliance (less failures), and the reservations will allow for more capacity-based load sharing (aka reduce contention)
13:16 < jrandom> neither of those are particularly latency based though
13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP
13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion
13:18 < jrandom> what was really killing irc.duck.i2p the other day was the fact that during congestion, duck's irc server still had to pump out 20x the number of messages it received
13:19 < jrandom> add on the automatic message resending every.10.seconds.with.no.backoff, and that grows to 120 messages for every line of text ;)
13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;)
13:19 <+DrWoo> is there such a beast?
13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead)
13:20 <+dinoman> is there a good one
13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year
13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p
13:21 < ant> <duck> silc == irc+somecrypto
13:21 < susi23> (as answer on the question, which protocols are used too)
13:21 < jrandom> ah, i thought silc got away from the ircd concept
13:21 < jrandom> oh, shit, right, i forgot about those two :)
13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now.
13:21 < ant> <duck> not far atleast
13:21 < jrandom> 'k
13:21 < ant> <protok0l> meeting?
13:22 < ant> <lucky> rite now protok0l 
13:22 < ant> <protok0l> k
13:22 < jrandom> ok, do we have anything else for 1) congestion?
13:23 < jrandom> if not, moving on to 2) streaming
13:23 < jrandom> [see the email]
13:24 < jrandom> i've kept all the streaming lib updates out of the history.txt, but you can watch whats going on via the cvs list
13:24 < jrandom> (if you're crazy)
13:24 < jrandom> i dont really have anythign else to add though.  so, any questions/comments/concerns?  
13:25 <+postman> just one
13:25 <+postman> thanks :)
13:25 < ant> <protok0l> what speed increase will there be
13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;)
13:25 < jrandom> protokol: some.  varies.  
13:25 <+postman> jrandom: i would bet on you blindfold
13:26 <+DrWoo> jrandom: I'm going to ask you what you hate, is there an ETA on the new streaming lib, the current situation obviously is a point of vulnerability?
13:27 < jrandom> if tests this week go well, we can pencil in next week
13:27 < jrandom> there'll be services up and running on the new streaming lib before then though, so that we can test it under load conditions
13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true?
13:29 < jrandom> for some of them, yeah
13:29 < jrandom> when i dont use the sim, i just run it on the live net
13:30 < jrandom> (because i like to abuse your bandwdith ;)
13:30 < susi23> you're welcome ;)
13:30 <+dinoman> hehe turn it on a see if it blows up?
13:31 -!- x is now known as fidd
13:31 < jrandom> pretty much - i've got some logging code that essentially dumps the streaming packet headers, allowing me to make sure everything is sent properly and various situations are handled as they should be
13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params
13:33 < wiht> How well do the simulation tests reflect observed network usage?
13:33 < jrandom> pretty well, as the simulation code is the same as the live network code
13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark
13:35 < ant> <cat-a-puss> will the new streaming lib use the same interface? Or will Java apps have to do something new?
13:35 < wiht> Thanks for clarifying that.
13:36 < jrandom> cat-a-puss: same interface.  there are a few additional config options that you might want to tack on when building an I2PSocketManager, but thats a good ol' properties map
13:36 < ant> <cat-a-puss> k
13:37 < jrandom> k, anything else, or shall we jump to 3) BT?
13:38 < jrandom> duck: ping
13:38 <@duck> *quack
13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some 
13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers).
13:38 <@duck> Updates since last week:
13:38 <@duck> GUI work (wxPython), included tracker, bugfixes.
13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD
13:39 <@duck> also the code is at the CVS on cvs.i2p
13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/
13:39 <@duck> The included tracker is very spartanic and you still have to provide the
13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at 
13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts.
13:39 <@duck> *flierp*
13:40 < jrandom> w00t
13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that,
13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution,
13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/
13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt
13:40 <@duck> .
13:40 < jrandom> kickass
13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up
13:41 <+DrWoo> there's nothing big to gum up the net heh
13:41 < jrandom> what, you dont want us to download more episodes of Lost?  :)
13:41 <@duck> if thetower's is up..
13:42 < jrandom> the bytemonsoon port is looking really nice.
13:42 <+DrWoo> I can't get thetower right now here
13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need
13:42 <+dinoman> what kind of speed r ppl seeing?
13:43 <@duck> ~5kb/s per peer
13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer
13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks)
13:44 <+dinoman> wow better then i thought
13:44 <@duck> til i2p crashes; see 1)
13:44 < jrandom> heh
13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm
13:44 <@duck> there have been various calls for improving the GUI
13:45 <+DrWoo> dinoman: and some 0 hop peers ;)
13:45 <@duck> not many takers on it though
13:45 < jrandom> duck (& gang): what can we do to help?
13:45 <@duck> you: get the new streaming lib ready
13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt
13:46 <@duck> lucky is working on a howto
13:47 <@duck> DrWoo: anything else?
13:47 < jrandom> nice
13:47 <+DrWoo> jrandom: can you talk a bit about where you stand regarding the importance (or not) of file sharing(and other popular services currently run over the internet) and what it's means to to I2P's anonymity prospects.
13:47 < ant> <lucky> i am?
13:48 < ant> <lucky> oh
13:48 < ant> <lucky> i am
13:48 < ant> <lucky> :)
13:48 <+DrWoo> duck: there's always something else heh
13:48 < jrandom> file sharing is critical to I2P's success, as its realistically the largest potential pool of users to blend into our anonymity set
13:49 < ant> <lucky> uh oh.
13:49 < ant> <lucky> So that means i should really, really, work on that howto then.
13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps
13:50 < jrandom> which we are doing - susi's and postman's work is quite promising
13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer
13:51 < jrandom> while I2P itself scales to whatever size (if things are as we hope ;), we need a large anonymity set to support anything wortwhile 
13:51 < jrandom> </my $0.02>
13:52 <@duck> what do you think about default settings for those filesharing apps?
13:52 < jrandom> that i dont know
13:53 <@duck> or isn't that really relevant yet giving todays possibilities
13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way?
13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3
13:57 < jrandom> ok, do we have anything else for 3) BT?
13:57 <@duck> notme
13:57 <+DrWoo> thanks to duck and the dudes
13:58 <+DrWoo> that was pretty awesome work
13:58 < jrandom> aye, y'all are doing a kickass job
13:58 <+dinoman> i did not do it
13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :)
13:58 <@duck> dinoman: you started it
13:58 <+Ragnarok> headless spew... sounds dirty
13:59 <+DrWoo> dino: pushing the effort along is a real contribution
13:59  * Ragnarok will put together a patch for the command line option stuff on the todo list
13:59 < jrandom> w00t
14:00 < ant> <dm> Don't forget anonymous WWW, that's a big one as well.
14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions
14:01 < jrandom> (for outproxy stuff, imho)
14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ???
14:01 < jrandom> anything not yet raised that should be?
14:02 < wiht> postman: What is the status of the mail system? How well is it working, especially with respect to communications outside the I2P network?
14:02 <+DrWoo> dm: it's all part of life's rich pageant :)
14:03 < ant> <dm> a lotta people use da web
14:03 < ant> <dm> (they just installed surfcontrol at my workplace) ;)
14:03 < jrandom> aye, anonymous www hosting will be critical for those who really need i2p, though they probably won't be the anonymity set necessary 
14:03 < jrandom> ah, lame
14:04 < jrandom> wiht: if he's not around, i can say that in and outproxy has worked pretty well for me - none lost yet
14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway)
14:05 < jrandom> ok, is there anything else?
14:06 < ant> <dm> are you baffing the meeting?
14:07 < jrandom> seems like it
14:07  * jrandom winds up
14:07  * jrandom *baf*s the meeting closed