[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-2020Q1  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+--------------------------

Comment (by uiouio27):

 Replying to [comment:4 dcf]:
 > Replying to [comment:2 uiouio27]:
 > > Does that mean that the required feature is covered? As far as I
 understand, that would switch the connection when a proxy leaves but not
 when it is very slow. Would it be still convenient to utilize several
 proxies but coordinately and congestion-based sending traffic to them?
 >
 > Good question. The multiplexing described in that document is simpler
 than what this ticket is about. You are correct that the failover only
 helps when a proxy dies, not when it is slow. But also, there's no way for
 a client to use, say, two 50 KB/s proxies as a single 100 KB/s channel—you
 can only use one at a time. The problem is that the bridge would be
 getting two streams of data and would not know how they should be
 interleaved.
 >

 Thanks for your answer, indeed the problem of resuming the session or any
 download with an alternate connection is necessary to be faced. I have
 seen the implementation of the Turbotunnel and seems interesting and I
 hope that can solve the usability problems. However, I still believe that
 a coordinated collaboration of multiple paths would be more beneficial.
 That would solve two problems: bridge churn, and slow bridges. I am not an
 expert on webrtc, but a solution to interleave multiple streams at
 application layer could also be convenient. I suppose such changes are not
 so complex inside the cgo wrapper of webrtc that Snowflake uses. Would you
 think it is worth to go on that (or a similar) direction?

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