XSF Discussion - 2014-02-04


  1. Ge0rG

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

  2. fippo

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

  3. Ge0rG

    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

  4. fippo

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

  5. ralphm

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

  6. Ge0rG is on a flaky 2G connection right now. can't do extensive surfing :(

  7. ralphm

    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?

  8. Ge0rG

    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.

  9. Ge0rG

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

  10. Ge0rG

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

  11. Ge0rG

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

  12. fippo

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

  13. Ge0rG

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

  14. Ge0rG

    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

  15. Ge0rG

    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 ;)

  16. fippo

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

  17. Ge0rG

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

  18. fippo

    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 :-/

  19. ralphm

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

  20. ralphm

    (which of course doesn't cover all headers)

  21. fippo

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

  22. ralphm

    yeah, of course

  23. ralphm

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

  24. fippo

    well, voip is timecritical. http isn't

  25. ralphm

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

  26. ralphm

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

  27. Zash

    But you still need servers to find them.

  28. Zash

    ralphm, like what XTLS was supposed to be?

  29. fippo

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

  30. ralphm

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

  31. ralphm

    that was using XTLS

  32. ralphm

    They never left the XEP inbox

  33. ralphm

    and then were IETF drafts

  34. fippo

    but we bumped the jingle namespace for XTLS at least!

  35. Kev

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

  36. Kev

    I forget, this was a while ago.

  37. ralphm

    Kev: indeed

  38. ralphm

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

  39. ralphm

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

  40. ralphm

    in fact, that spec mentions dtls

  41. fippo

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

  42. ralphm

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

  43. ralphm

    OpenSSL is the bane of everyones existance

  44. ralphm

    existence even

  45. ralphm

    unfortunately, there aren't many alternatives

  46. Zash

    fippo: Why would you use that directly?

  47. fippo

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

  48. fippo

    zash: for doing xtls over ibb

  49. ralphm

    fippo: can we forget about that use case?

  50. Zash

    fippo: Oh. Yeah. :/

  51. ralphm

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

  52. Kev

    ralphm: Why's that?

  53. Kev

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

  54. fippo

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

  55. ralphm

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

  56. Kev

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

  57. Zash

    You /could/ run multiple client connections ...

  58. fippo

    ralphm/zash: +1000!

  59. Kev

    And in reasonably small chunks.

  60. fippo

    kev: bad traffic properties. bad karma

  61. Kev

    There is clearly an upper limit on what is sensible.

  62. ralphm

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

  63. Kev

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

  64. Kev

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

  65. ralphm

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

  66. ralphm

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

  67. ralphm

    If only with co-located proxies

  68. Kev

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

  69. ralphm

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

  70. ralphm

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

  71. Kev

    Well, it's guaranteed interop.

  72. Kev

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

  73. ralphm

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

  74. fippo

    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 :-)

  75. ralphm

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

  76. ralphm

    fippo: agreed

  77. ralphm

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

  78. ralphm

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

  79. ralphm

    :-P

  80. Kev

    The DoS did that already :(

  81. Kev

    Although it's back now.

  82. intosi

    That's not Kev breaking things.

  83. ralphm

    intosi: don't break things

  84. intosi

    I'm trying to unbreak it.

  85. ralphm

    hehe

  86. ralphm

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

  87. Kev

    I don't have strong opinions on this.

  88. Kev

    Well, actually, I do.

  89. ralphm set the topic to

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

  90. Kev

    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.

  91. Tobias

    you welcome anything that takes load of jabber.org?

  92. Tobias

    :)

  93. Kev

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

  94. Kev

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

  95. Tobias

    i know..was just joking

  96. Kev

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

  97. ralphm

    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.

  98. MattJ

    I can handle it ;)

  99. Tobias

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

  100. ralphm

    Kev: are the DoSsers targetting jdev specifically?

  101. Kev

    No.

  102. Tobias

    all DoS packets are JIT compiled to a single NOP

  103. Kev

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

  104. ralphm

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

  105. Kev

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

  106. ralphm

    awesome

  107. Zash

    Create a new room for general discussions?

  108. ralphm

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

  109. ralphm

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

  110. Kev

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

  111. ralphm

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

  112. Kev

    And some old spam in the history.

  113. ralphm

    techreview@ points here

  114. Tobias

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

  115. Zash

    Destroy all rooms!

  116. ralphm

    Tobias: they are public

  117. Kev

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

  118. ralphm

    Tobias: like we discuss mostly everything on the members list

  119. Tobias

    Kev, let's move council meetings here?

  120. Kev

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

  121. ralphm

    Tobias: that crossed my mind, but what Kev says

  122. Tobias

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

  123. ralphm

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

  124. ralphm

    board@ should probably be a restricted room

  125. ralphm

    like the mailing list

  126. intosi

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

  127. ralphm

    except we would almost never use it

  128. intosi

    You wouldn't for board meetings, at least.

  129. Kev

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

  130. intosi

    Kev: right

  131. ralphm

    Kev: I'd merge them, of course

  132. Kev

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

  133. ralphm

    Kev: indeed

  134. Ge0rG 's got one good reason for IBB. With 0198, you can have stream resumption for file transfers.

  135. ralphm

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

  136. fippo

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

  137. Ge0rG

    how does SCTP-DTLS handle live network changes?

  138. ralphm

    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

  139. fippo

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

  140. fippo

    ge0rg: using ice / mice

  141. fippo

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

  142. Ge0rG puts mice on his read-list

  143. Ge0rG

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

  144. ralphm

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

  145. Ge0rG

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

  146. ralphm

    Ge0rG: hang in there!

  147. Ge0rG whistles Jeopardy tune...

  148. dwd

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

  149. dwd

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

  150. Kev

    dwd: Other than board@?

  151. dwd

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

  152. Kev

    OK.

  153. Kev

    Also on xmpp.org?

  154. dwd

    Yes

  155. Kev

    OK.

  156. ralphm

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

  157. ralphm

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

  158. ralphm

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

  159. emcho

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

  160. emcho

    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

  161. emcho

    are those readable to you?

  162. Tobias

    emcho, seems so

  163. emcho

    cool

  164. ralphm

    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?

  165. emcho

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

  166. Tobias

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

  167. ralphm

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

  168. ralphm

    hi Lance

  169. emcho

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

  170. simon

    ralphm: dates extended. Photos should be addable.

  171. bear

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

  172. dwd

    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.

  173. bear

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

  174. ralphm

    emcho: thanks!

  175. ralphm

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

  176. dwd

    [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

  177. dwd

    I'm *so* cruel.

  178. fippo

    rotfl

  179. Tobias

    hehe

  180. bear

    LOL

  181. ralphm

    dwd: good thing you have a thinking cap now

  182. bear

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

  183. ralphm

    bear: ack

  184. ralphm

    bear: sent

  185. bear

    ta

  186. dwd

    bear, You messed up my spreadsheet. :-)

  187. Zash

    BEAR, WHYYYYY

  188. Tobias

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

  189. waqas

    Tobias: Which one?

  190. Tobias

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

  191. dwd unmesses the sheet.

  192. dwd

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

  193. waqas

    They train you to make losses look smaller?

  194. dwd

    No, they train you to get the signs correct.

  195. Neustradamus

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

  196. dwd

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

  197. ralphm

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

  198. dwd

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

  199. Zash

    Maybe it'll be a person.

  200. Zash

    Or two

  201. Zash

    or more

  202. ralphm

    Zash: what!

  203. Zash

    Just maybe