#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

zzz 0) Hi

zzz hi

eyedeekay hi

zzz what's on the agenda for today?

orignal hi

R4SAS hi

orignal SSU2 status as usual

zzz I'll say up front my last week is mostly non-ssu2 bug fixing, and non-i2p stuff

eyedeekay If orignal's not here you're the only one who might do an SSU2 update

eyedeekay I'd like to ask a question about SAM interactive auth

zzz ok that's 1) eyedeekay

orignal huh?

zzz I guess 2) is SSU2 status

zzz anything else for the list?

orignal than I have some question about peer test

zzz ok 3) is peer test

eyedeekay OK so I've almost got the whole thing figured out, I've even got it working on Android, but I've hit a snag and I think I can fix it but I might have to do something drastic and I want to know if I'm not missing a simpler alternative

zzz 1) SAM interactive auth

eyedeekay Jumped the gun, my bad

zzz back up and remind us what it is?

eyedeekay Pop up a dialog during "HELLO" that asks the user if they want to "authorize" an application to make a SAM connection

orignal so what's an issue with it?

orignal you can't make a callback of what?

eyedeekay Implementing the UI on Java on Desktop, the way that I'm doing it on Android is I'm passing an implementation of the interface "SAMSecureSessionManager" to the SAMBridge constructor, which I can do because I use the SAMBridge constructor directly

orignal use a singleton for it

eyedeekay But as far as I can tell when the SAM API is started on Desktop it's being run with args and uses a different constructor, where I can't do that

zzz is there any desktop use for this feature?

eyedeekay And moreover I wasn't sure if I should add javax.swing stuff into SAM to implement the UI, or put it somewhere else and pass it like I do for Android

eyedeekay I mean hypothetically there's still malware on every platform

eyedeekay It's less useful for Debian maybe but on Windows it might make sense

zzz the code you have now for android, does it go in the android tree or the i2p tree?

orignal it's a bad idea to use for CLI apps

eyedeekay Part of it goes into apps/sam and part of it goes into i2p.android.base

eyedeekay Yeah that's my point orignal, in it's default state the interface gets a "dummy" implementation that does nothing and breaks nothing

eyedeekay I don't know how to inform it of a GUI

orignal if we decide to implment it

zzz I'd recommend for now that you put as much code as you can on the android side, and minimize sam changes

orignal we would use #ifdef ANDROID

orignal and that's it

zzz I agree with orignal it's kinda messy to put GUI stuff in a CLI (or really an embedded) protocol

zzz maybe you provide some auth hook in sam, and register it, to make it generalizable later

zzz but I wouldn't fight with desktop at this time

zzz no ifdef in java (((

eyedeekay OK then that was really my last hangup so I should be able to proceed

eyedeekay Desktop later then

zzz that's what I suggest, yeah, it's really a different set of problems

zzz anything else on 1) ?

orignal no

eyedeekay No I don't think so

zzz ok

zzz 2) SSU2 status

zzz I don't have much to report, as I said at the top

zzz orignal, what about you?

orignal so, I see incoming sessions form to time

orignal and bunch of tunnel messages through it

orignal I have rewritten resend code

orignal to encrypt with new packet num on each resend

zzz nice

orignal started implementing window and RTT

orignal so I'm almost done

zzz ok

zzz I think I mentioned the other day:

orignal excepting peer tests and introducers

zzz I think we're going to need an ack-immediately flag like we have in streaming

orignal we are going to run some perforance test soon

zzz you set it when your send window is full, or almost full

orignal good point

orignal but for now I always do "ack immediately"

orignal basically I read a batch of packet from socket

orignal and send Ack after it

zzz so the question is a bit in the header, or a new block. In the spec I added a "congestion" block, but I think a header bit might be better

zzz I don't have a recommendation today. Just something to think about

orignal 128K buffer

zzz let me tell you our delayed-ack algorithm - one sec

zzz we recently changed it

orignal please

orignal I didn;t implement it but going it

zzz after some simulation tests

zzz looking...

zzz after first incoming packet that needs to be acked, we delay for:

zzz max(10, min(rtt/6, 150)) ms

orignal so you start timer for it?

zzz that's now for both SSU 1 and 2

zzz yes

orignal that's bad

orignal remeber you have throusands of connections

zzz yes, but most are idle

orignal and a file descriptor for each

orignal why?

zzz one timer per connection - that's what we do for both SSU and streaming

orignal you start time after receiving a data packet

zzz long ago, we had one timer per packet !!!!!

zzz at least for retransmission... but thats outbound

zzz anyway, that's what we do. We've had one timer per SSU connection since our redesign last year

orignal I use single time for all connetion for retrans in SSU2

orignal because people keep complaining about SSU1

orignal where one time per connection

zzz the thing about SSU 1/2 is you really don't want it to be too "bursty"

zzz because the packets will get dropped somewhere if you send everything at once

orignal I'm just thinking about delayed ack

orignal I do the same stuff for streming

orignal but number of streams is much less than SSU sessions

orignal I have a better idea basically

orignal to check is retrans list is not empty

orignal *if

zzz ok, just wanted to let you know what we do, I don't have any advice really, except that delayed ack is important so you don't send too many packets

zzz how you do delayed ack is up to you

orignal see my point

orignal if we have something to retrans

orignal we have to send a new message soon

zzz yes I understand

zzz thing is, unfortunately, most of the time the traffic is "one-way" if it's only one tunnel

orignal yes

orignal that's why read and handle packets in batch

zzz sounds good

orignal up to 32 at the time

zzz anything else on 2) ?

orignal nothing

orignal I keep working ))

zzz 3) SSU2 peer test

orignal yes

zzz keep up the good work :)

orignal I'm confused about separate Peer Test message

orignal not just a block

orignal what is it for?

zzz ok, I'll answer as best I can

zzz I wrote all that a month or two ago

zzz and I plan to restart work on peer test tomorrow :)

orignal yes

zzz but basically:

orignal nice ))

zzz one sec let me copy in the chart

zzz Alice Bob Charlie

zzz 1. PeerTest ------------------->

zzz Alice RI ------------------->

zzz 2. PeerTest ------------------->

zzz 3. <------------------ PeerTest

zzz <---------------- Charlie RI

zzz 4. <------------------ PeerTest

zzz 5. <----------------------------------------- PeerTest

zzz 6. PeerTest ----------------------------------------->

zzz 7. <----------------------------------------- PeerTest

zzz 1-7 are almost like SSU 1

zzz 1-4 are in-session, so they are blocks

zzz 5-7 are NOT in session, so they're separate messages

orignal yes

orignal my questuin why we can't do the same for 5-7?

zzz I don't think we need to do a whole handshake

orignal epecially since cost of SSU2 session if much less

zzz I don't think it's necessary

orignal and this session could be reused later

zzz put probably wound not be reused later... what do they have to talk about?

orignal why?

zzz charlie is chosen randomly by bob

orignal yes

zzz so alice doesn't naturally have anything to send to charlie, or vice versa

orignal but when Alice selects first hop

orignal she migh pich Charlie from existing sessions

zzz the thing is, peer test should not be expensive

orignal agree

orignal so what's the format of PeerTest message?

zzz if alice wants to set up a session, she can. she got charlie's RI from bob

zzz I think it's in the spec, type 7

zzz basically, similar to retry. long header, AEAD with maybe datetime only? can't remember

orignal so no blocks

orignal of it's still PeerTest block?

zzz datetime block, address block

zzz here's what the spec says:

zzz In messages 5 and 7, the Peer Test block is identical to the block from in-session messages 3 and 4, containing the agreement signed by Charlie.

zzz In message 6, the Peer Test block is identical to the block from in-session messages 1 and 2, containing the request signed by Alice.

orignal fine

zzz let's not make any decisions or changes today. I really don't remember it well enough to say if it's good or bad

zzz happy to make changes but let me read what I wrote first

orignal no problem

zzz it's been too long

orignal or maybe better to start with introducers first

zzz I have this almost all coded. introducers is more complex

zzz just give me a couple days to get smarter

zzz thanks

orignal introducers are more important however

zzz agreed

zzz anything else on 3) ?

orignal тщ

orignal no

zzz anything else for the meeting?

eyedeekay No

orignal as I said we will try performance test soon

orignal of SSU2

zzz orignal, FYI our release will probably be either May 16 or May 23

orignal great

zzz ^^ R4SAS too

orignal will be reasy with most of SSU2 by that time

zzz great stuff, thanks everybody