15:57:46 <meskio> #startmeeting tor anti-censorship meeting
15:57:46 <MeetBot> Meeting started Thu Nov 30 15:57:46 2023 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:57:50 <meskio> hello everybody!!!
15:57:52 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
15:57:58 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
15:58:00 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
15:58:13 <onyinyang[m]> Hello!
15:58:19 <shelikhoo> hi~
16:02:41 <meskio> from last week there is the bridgestatus format change point
16:02:47 <meskio> shelikhoo: is there something to discuss on this?
16:02:51 <meskio> or should I just remove it?
16:02:59 <shelikhoo> let's remove it
16:03:06 <shelikhoo> there isn't anything to discuss
16:03:20 <meskio> yes, I don't think we have anything to discuss this week
16:03:30 <shelikhoo> just I have confirmed that amp cache don't work in china with its default setting
16:03:32 <meskio> the manifest v3 will wait a couple of weeks for cecylia to be back
16:03:51 <meskio> is nice to have amp cache tests in logcollector :)
16:04:08 <ggus> o/
16:04:11 <shelikhoo> on the other hand, I was thinking if there is some known kcp setting that works well under lossy udp connection
16:04:18 <shelikhoo> https://jsfiddle.net/Sheilkhoo/s9kx4h8m/1/
16:04:33 <dcf1> I tried cdn.ampproject.org in the Greatfire analyzer, it said it was unblocked. That might work as a front for AMP cache in China, though not a very good one.
16:05:22 <dcf1> btw diff of shelikhoo's WIP performance branch: https://gitlab.torproject.org/shelikhoo/snowflake/-/compare/main...f3b46dad387486c9526ec1876cc73264935a8f75
16:05:25 <shelikhoo> I draw a chart of speed with udp and tcp like transport, and it seems tcp-like is faster than udp-like
16:06:00 <shelikhoo> I have fixed one bug and is currently rerun the experiment
16:06:14 <shelikhoo> and wonder if an alternative kcp setting should be tried
16:06:35 <shelikhoo> (in the chart, x=packetloss, y=delay)
16:06:48 <shelikhoo> z=speed
16:08:41 <meskio> isn't counterintuitive that tcp is faster here?
16:09:21 <shelikhoo> I think it could because kcp treat packet loss as congestion and reduce sending rate
16:10:35 <dcf1> you can look at past documentation of KCP tuning
16:10:36 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40026
16:11:15 <dcf1> I believe we already turn the congenstion window off, for better performance with the TCP-like transport, so you might try turning it _on_.
16:11:22 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40026#note_2720235
16:11:25 <dcf1> 1, // nc=1 => congestion window off
16:11:40 <dcf1> Also see
16:11:45 <dcf1> https://lists.torproject.org/pipermail/anti-censorship-team/2021-July/000178.html "Improving Snowflake performance by adjusting smux parameters"
16:12:14 <shelikhoo> or maybe it is SetStreamMode
16:12:24 <shelikhoo> because it is no longer a stream
16:12:32 <shelikhoo> this just create invalid packets?
16:13:03 <dcf1> I can only recommend reading the KCP documentation for that
16:13:18 <shelikhoo> I will have a look at these issues and try different settings
16:13:30 <shelikhoo> plus read kcp documents...
16:14:17 <dcf1> You may have to go to the original C-KCP for documentation on stuff such as SetStreamMode
16:14:20 <dcf1> https://github.com/skywind3000/kcp
16:14:32 <dcf1> Because the kcp-go documentation is not very helpful:
16:14:33 <dcf1> https://pkg.go.dev/github.com/xtaci/kcp-go#UDPSession.SetStreamMode
16:14:57 <dcf1> https://github.com/skywind3000/kcp/blob/master/README.en.md#protocol-configuration
16:15:20 <shelikhoo> Yes! Thanks for the links and suggestion!
16:16:15 <dcf1> https://repo.or.cz/dnstt.git/commitdiff/de15c5a51291cae19dfad26149f00b2b836edfb3 performance tuning commit in dnstt
16:17:35 <shelikhoo> yes! I will have a look.
16:17:38 <dcf1> There are also some links to performance-related commits in Champa and Snowflake at
16:17:41 <dcf1> https://www.bamsoftware.com/software/dnstt/performance.html#download-20210802
16:18:36 <meskio> shelikhoo: it looks like you have a lot to read now :D
16:18:40 <meskio> anything else on this topic?
16:18:49 <shelikhoo> yes... nothing more from me
16:19:11 <meskio> or any other topic to discuss
16:19:12 <meskio> ?
16:19:22 <dcf1> As a first pass, you might try copying the settings in dnstt, because that similarly uses an unreliable transport.
16:20:48 <shelikhoo> yes. I think I will copy the settings from dnstt and have a look at stream mode
16:21:26 <onyinyang[m]> I just wanted to mention that some of us are planning to attend splintercon next week
16:22:05 <meskio> yes, and I will be talking in an online conference: https://bitwarden.com/open-source-security-summit/
16:22:10 <dcf1> https://splintercon.net/ "the first conference dedicated to identifying and beginning to challenge connectivity restrictions of the splinternet."
16:22:13 <meskio> but will be a 10min talk very basic
16:22:56 <onyinyang[m]> Nice!
16:23:15 <dcf1> "Bypassing Online Censorship: Open-Source Tools as a Critical Lifeline"
16:23:16 <dcf1> cool
16:23:16 <shelikhoo> great! nice!
16:23:24 <shelikhoo> cool!
16:23:31 <meskio> yes, I'm still figuring out what to say there
16:23:38 <meskio> but will be an introduction of what we do
16:24:27 <meskio> in the interesting links there are two papers:
16:24:29 <onyinyang[m]> Oh also, one of the interesting links I shared from PETS uses Lox to test their work. I haven’t had time to read the paper yet but wanted to share: https://petsymposium.org/popets/2024/popets-2024-0027.php
16:24:31 <meskio> https://www.cs-pk.com/papers/3/ "NetShuffle: Circumventing Censorship with Shuffle Proxies at the Edge" S&P 2024
16:24:33 <meskio> https://petsymposium.org/popets/2024/popets-2024-0027.php "Communication Breakdown: Modularizing Application Tunneling for Signaling Around Censorship" PETS 2024
16:24:43 <onyinyang[m]> Sorry, jumped the gun there lol
16:24:46 <meskio> :D
16:25:04 <meskio> that reminds me, should we pick up something for our reading group?
16:25:10 <meskio> I guess it will be the last of the year
16:25:28 <meskio> there is these two and some weeks ago there were also few shared
16:25:33 <meskio> any preferences?
16:26:11 <meskio> onyinyang[m]: congrats for being reused :)
16:26:29 <onyinyang[m]> Hehe XD
16:28:16 * meskio is looking into the previous links
16:28:51 <meskio> * "Covertness Analysis of Snowflake Proxy Request"
16:28:54 <meskio> * https://ieeexplore.ieee.org/document/10152736
16:28:56 <meskio> * https://github.com/Xanole/SnowDT
16:29:07 <meskio> * "TorKameleon: Improving Tor's Censorship Resistance With
16:29:09 <meskio> K-anonymization and Media-based Covert Channels"
16:29:11 <meskio> * https://arxiv.org/abs/2303.17544
16:29:13 <meskio> * https://github.com/AfonsoVilalonga/TorKameleon
16:30:31 <onyinyang[m]> Hmmm
16:31:05 <meskio> should we do the snowflake one?
16:31:10 <meskio> https://ieeexplore.ieee.org/document/10152736
16:31:18 <meskio> looks like a research comming from china
16:32:15 <onyinyang[m]> I’d say that or netshuffle but only because I know some of the authors lol which maybe isn’t the best reason
16:32:30 <meskio> that is a reason :D
16:33:22 <shelikhoo> I wasn't able to find a link to Covertness Analysis of Snowflake Proxy Request at scihub...
16:33:23 <meskio> I'm happy with that, and the snowflake one doesn't seem to have the pdf public in the IEEE website :(
16:33:54 <meskio> yes, let's do netshuffle then
16:34:00 <onyinyang[m]> Ok!
16:34:03 <dcf1> I have a PDF of the SnowDT one. It doesn't have much to say imo, though it is short.
16:35:05 <onyinyang[m]> I can reach out to some Netshuffle authors and see if they would be interested to join our meeting when we discuss it too
16:35:10 <meskio> dcf1: if you don't mind to share it, I'll like to have a look to it
16:35:21 <meskio> should we do December 14?
16:35:25 <meskio> in two weeks
16:35:37 <onyinyang[m]> Sure
16:36:09 <shelikhoo> yes
16:36:28 <meskio> anything else for today?
16:36:35 <shelikhoo> EOF from me
16:36:36 <onyinyang[m]> Not from me
16:36:43 <meskio> I'll close the meeting then
16:36:46 <meskio> #endmeeting