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