XSF Discussion - 2014-02-04

mhm. looks like it all started here: http://mozilla.6506.n7.nabble.com/SCTP-and-WebRTC-FYI-td228999.html

ge0rg: i think it was earlier... i'll check the notes from the kickoff

fippo: I'd be glad to get to the root of it. I'm looking for material supporting the not-quite-obvious decision of SCTP-over-DTLS

http://rtc-web.alvestrand.com/ might have some hints... but I can't find anything obvious right now

Ge0rG: I might have missed earlier discussion on this, but what is the issue?

Ge0rG: I mean, why is SCTP-over-DTLS a thing that needs to be gotten to the root of? Why is it an unexpected choice?

ralphm: what I am looking for is extensive documentation of the possible alternatives, and why stacking a transport-layer protocol implemented at the app layer on top of another transport layer protocol has been chosen.

also, my 2G connection lags. icmp_req=454 ttl=40 time=34930 ms

ralphm: I can understand the choice was made because of NAT, but I fail to believe it was the only possible choice.

you know, if all you ave is a srtp/dtls hammer, file transfer might look like a nail as well.

ge0rg: RTMFP was/is way more cool imo :-)

sometimes people make brave decisions and stack protocols like it is Babel all over again. And sometimes it even works out reasonably well.

so far, the guardianproject managed twice already to impress and to disgust me at the same time with their protocol stacking: one was serverless XMPP over avahii over OLSR on mobile, and the other was HTTP over OTR text messages over XMPP

and I'd like to form a strong opinion on that SCTP-over-DTLS thing before opening my mouth and ranting it to the moon ;)

ge0rg: shout at rtcweb for using DTLS-SRTP instead of ZRTP :-)

fippo: I have no strong opinion on RTP encryption mechanisms, and do not intend to form one soon

the bad thing about all RTP encryption mechs is that they don't encrypt the header. which really makes me wonder about the https://www.schneier.com/blog/archives/2011/03/detecting_words.html kind of stuff :-/

fippo: what about http://tools.ietf.org/html/rfc6904?

(which of course doesn't cover all headers)

ralphm: the basic problem is that there is alot of infrastructure that wants to have access to the rtp headers for QoS.

yeah, of course

I suppose the same holds for http v.s. https

well, voip is timecritical. http isn't

with Internet "service" providers mucking around with your javascript, styling and images if you use http

Ge0rG: but just so you know, server-less XMPP over SCTP/DTLS/SRTP will be a thing.

But you still need servers to find them.

ralphm, like what XTLS was supposed to be?

ralphm: i think the guys from the RWTH aachen have a prototype for exactly that ,-)

Zash: Yeah, there have been proposals to negotiate peer-to-peer XML Streams over Jingle to do end-to-end encryption.

that was using XTLS

They never left the XEP inbox

and then were IETF drafts

but we bumped the jingle namespace for XTLS at least!

That was why they never left the inbox, wasn't it?

I forget, this was a while ago.

Kev: indeed

tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02

http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02

in fact, that spec mentions dtls

i tried implementing XTLS, but found the openssl BIO api to be ... hard to use.

I think it might be picked up again to match the new webrtc reality

OpenSSL is the bane of everyones existance

existence even

unfortunately, there aren't many alternatives

fippo: Why would you use that directly?

i do think the approach in xep-0320 (mapping rfc 5763 without much more thought) is better than the one shown in draft-meyer

zash: for doing xtls over ibb

fippo: can we forget about that use case?

fippo: Oh. Yeah. :/

I think we should maybe move beyond thinking that we want to fall back on ibb

ralphm: Why's that?

And are you saying that as a general policy, or just for some use cases?

https://code.google.com/p/webrtc/issues/detail?id=2796 -- ah, they're going to fix the wrong m-line then!

Kev: for streaming, file transfer, IBB is an unholy approach. Most servers will not handle it well and large stanzas block streams, I believe.

I'm not sure why server shouldn't handle it well, it's just message switching, same as everything else.

You /could/ run multiple client connections ...

ralphm/zash: +1000!

And in reasonably small chunks.

kev: bad traffic properties. bad karma

There is clearly an upper limit on what is sensible.

Kev: and I think the upper limit is probably around GSM encoded audio.

fippo: That's choosing not to handle it, rather than being unable to handle it.

I have no idea if fallback for media streams is viable. It feels like it's probably not.

I'd rather have a single model here, having byte streams out of band.

If you need alternative transports there, Jingle should be able to handle that.

If only with co-located proxies

I see your point. But equally, I'm not sure we should dismiss IBB out of hand.

I'd love to see a counter argument besides "it might still be useful".

We've been dragging on this forever and it always felt icky

Well, it's guaranteed interop.

Which seems slightly more than 'it might be useful'.

I mean, base64 encoded RTP wrapped in XML on stanza-switched (neologism?) connection. Meh.

i like it as last-resort for file transfer. but I'd actually prefer to see how well webrtc with all its nat traversal requires it. no decisions without data :-)

I /could/ kind of see how we might do inband if there's going to be a HTTP/2.0 binding for XMPP eventually.

fippo: agreed

fippo: but I do like the idea of separation of concerns, while being sympathetic to Kev's argument.

Kev: don't break jabber.org, please!

:-P

The DoS did that already :(

Although it's back now.

That's not Kev breaking things.

intosi: don't break things

I'm trying to unbreak it.

hehe

Meanwhile, I updated the topic for jdev to point here, as many discussions seem to happen here instead of over there

I don't have strong opinions on this.

Well, actually, I do.

XSF discussion room | Logs: http://logs.xmpp.org/xsf/

Which is that this room gets used for official purposes from time to time, so we shouldn't encourage entry from the types of people who will be a nuisance.

you welcome anything that takes load of jabber.org?

:)

But it's not clear to me that this fails that test.

Tobias: The jdev load really isn't a problem.

i know..was just joking

Although if it encourages the DoSsers to start attacking muc.xmpp.org instead, we will possibly have issues. Athena is...not as powerful.

Kev: I'm trying to reflect reality, still forming my opinion. Arguably, since standards@xmpp.org is hosted by the XSF, maybe the discussions on MUC should too.

I can handle it ;)

yeah...it's Lua, not some C/C++ stuff

Kev: are the DoSsers targetting jdev specifically?

No.

all DoS packets are JIT compiled to a single NOP

Which is why I'm not jumping up and down and calling you a lunatic for pointing them here :)

Do you think pointing to it in the topic gives them ideas?

Probably not. I think this is probably not going to lead to problems.

awesome

Create a new room for general discussions?

Zash: I don't see the point, to be honest

But, one could argue we should reflect the mailinglists in rooms. I've seen a trend to reduce the number of lists, though.

I don't see much value in moving jdev here. I don't see much harm in it.

oh, heh, there is a board room. Single occupant is a non-board member.

And some old spam in the history.

techreview@ points here

also been wondering why board meeting happen here and not at board@

Destroy all rooms!

Tobias: they are public

Tobias: There's no reason for them not to happen here :)

Tobias: like we discuss mostly everything on the members list

Kev, let's move council meetings here?

Council and Board sometimes overlap slightly, so that seems like a not great idea.

Tobias: that crossed my mind, but what Kev says

i just seem to remember they've been hold in the board@muc...but if that's wrong nvm

Tobias: we won't any time soon, I think

board@ should probably be a restricted room

like the mailing list

A board-only back channel doesn't sound like a bad idea to me.

except we would almost never use it

You wouldn't for board meetings, at least.

intosi: A /second/ Board-only back channel.

Kev: right

Kev: I'd merge them, of course

I think Board can decide if they want such a thing. I don't see the value, but I'm not Board.

Kev: indeed

While that might be an argument, I am not sure if it is a particularly strong one.

if your server doesn't like IBB and kills you for bad karma, you might trick the karma mechanism :-)

how does SCTP-DTLS handle live network changes?

I.e. for file transfers, if the transfer is broken at some point, you know which pieces you have, and can simply start a new transfer for the missing pieces

(i don't want to look further down the road... karma was always simplified too much)

ge0rg: using ice / mice

ge0rg: http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-02

ralphm: resuming a file transfer somewhere in the middle is a security problem, as well

Ge0rG: I don't see how the transport method affects that statement

ralphm: maybe I'm just hanging at the slight semantic difference between "resume" and "continue"

Ge0rG: hang in there!

We (the Board) do actually have a seperate MUC for private discussion, but we've rarely used it.

I think we used it to discuss an incoming sponsor once, and that's it.

dwd: Other than board@?

Yes; seemed easier to setup a new one than repurpose an existing one at the time.

OK.

Also on xmpp.org?

Yes

OK.

simon: I want to add pictures from the Lounge to the Summit event in Plus. Can you extend the dates?

or any other suggestion for collecting pictures from both in one album

emcho: you guys have a bunch of pictures of the lounge, yes?

ralphm: I'll ask around and I'll come back to you

https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaT3ZxUlNYbWdSWE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaYWxCWXdLbW9LeUE/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaU1d0TTBjZUVXNFU/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitadUF4bUFNc3lrZE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaVXdvY2VlSzNrRkk/edit

are those readable to you?

emcho, seems so

cool

emcho: cool. Since they are in the Googleplex already, can you add them to the photos on the XMPP Summit event on G+ by Simon?

ralphm: where's that. can't find anything on simon's page other than the BC photos from the mountains

https://plus.google.com/events/cducp61naq050ce9cufjlfh37d8?authkey=CIjS4KHjiq2zpAE this is it i think

emcho: what Tobias says. It is in the XMPP community page

hi Lance

ralphm: ok done. will add more as people check them in

ralphm: dates extended. Photos should be addable.

dwd - can you send that link to my andyet email address?

BTW, I personally have no issues with the spreadsheet currently being played with by Board being made public; but I wasn't happy doing that unilaterally or when the figures were still rough.

once we get all the final data, no reason to not publish a read-only version IMO

emcho: thanks!

simon: thanks! It seems Plus doesn't actually mind

[17:27:17] Dave Cridland: http://ubber.com seems to give me German error messages. Might want to check that out. [17:35:20] Florian Jensen: hmm [17:35:21] Florian Jensen: our geo db is off then

I'm *so* cruel.

rotfl

hehe

LOL

dwd: good thing you have a thinking cap now

ralphm - remember to send me an email for the cost of the realtime logo'd bean bags

bear: ack

bear: sent

ta

bear, You messed up my spreadsheet. :-)

BEAR, WHYYYYY

yeah...didn't you get that memo?

Tobias: Which one?

waqas, about the spreadsheets....right next to the one about the TPS reports

bear had made the loss look bigger, whereas now it's much better. Benefits of some ad-hoc training in accountancy.

They train you to make losses look smaller?

No, they train you to get the signs correct.

one guy will post an article about FOSDEM on the website?

Yes, we'll get to that. The Summit, too.

dwd: what if is isn't one. Or not even a guy?

ralphm, I'm somewhat hoping it won't be a guy. :-)

Maybe it'll be a person.

Or two

or more

Zash: what!

Just maybe