[tor-bugs] #25723 [Circumvention/Snowflake]: Multiplex - one client splits traffic across multiple proxies

[Tor Bug Tracker & Wiki]

#25723: Multiplex - one client splits traffic across multiple proxies
------------------------------------------+--------------------------
 Reporter:  dcf                           |          Owner:  dcf
     Type:  defect                        |         Status:  assigned
 Priority:  Low                           |      Milestone:
Component:  Circumvention/Snowflake       |        Version:
 Severity:  Normal                        |     Resolution:
 Keywords:  anti-censorship-roadmap-2020  |  Actual Points:
Parent ID:  #19001                        |         Points:
 Reviewer:                                |        Sponsor:
------------------------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:10 cohosh]:
 > Sounds great. As far as weighting it based on proxy bandwidth or
 latency, can we use something similar to the connection migration you
 mentioned in
 [https://github.com/net4people/bbs/issues/14#issuecomment-542898991 one of
 your initial TurboTunnel posts]? That way if more packets are coming
 through one snowflake, more packets will be sent out to it? Or is this
 going to choke out the other snowflakes too easily?

 I was actually thinking about weighting at the client, so connection
 migration at the server wouldn't come into it. But now that you mention
 it, some kind of prioritization may be necessary at the server as well--
 currently all proxies for a client will pull from the outgoing queue
 equally and perhaps undo whatever prioritization the client tried to use--
 though I'm not sure what would actually happen. It may interact in weird
 ways with SCTP's congestion control in the DataChannel layer.

 What I was thinking is that the client keeps a moving average of bandwidth
 for each of its current proxies (using EWMA or something), then allocates
 sends based on the ratios of those bandwidth averages. So if proxy A has
 recently done 100 KB/s and proxy B has 50 KB/s, you send 2/3 on proxy A
 and 1/3 on proxy B. But that may not be a good idea because there's not a
 way for a proxy to "recover" and get prioritized after the client has
 decided it's slower. Honestly for a first draft I would just prioritize
 proxies uniformly (either round-robin or uniform random selection per
 send) and see if the backpressure of SCTP or other layers automatically
 causes convergence to a good ratio.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25723#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online