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