[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25723 [Circumvention/Snowflake]: Multiplex - one client splits traffic across multiple proxies
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs