Re: [tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arlolra):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Agreed, let's decline.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 In my opinion, WebSocket wins for simplicity and robustness. I don't know
 why WebRTC would have higher performance either (but I haven't tried it).
 Even WebRTC has to do a DTLS handshake, you still have overhead there.

 With a WebSocket bridge, the issue of Cgo and threads doesn't come up. We
 only use Cgo on the client, which doesn't have to scale very much. The
 proxies are running in browsers, no Cgo there. (proxy-go is another story,
 but that's orthogonal to the protocol used for the proxy–bridge link.) And
 the WebSocket bridge is essentially just an HTTPS server, like meek-
 server, which scales pretty well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #25592 [Obfuscation/Snowflake]: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy

[Tor Bug Tracker & Wiki]

#25592: Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 > webrtc <-->websocket is the current situation, which works.
 > webrtc <--> webrtc would take a bit more work.

 \\

 > Quoting @Yawning,
 >
 > What are your plans for actually getting the server side to scale well?
 Since you're using cgo you will run into Really Interesting behavior wrt
 OS threads as you try to increase concurrency.
 >
 > https://lists.torproject.org/pipermail/tor-dev/2016-January/010311.html

 \\

 > Yes, that does complicate the potential of using a second WebRTC
 connection to the relay...
 >
 > The benefit of WebRTC on both sides should be performance / latency,
 whereas right now the websocket connection to the relay is most likely
 bottlenecking the first WebRTC data channel from the client.
 >
 > But maybe it's actually not, at least significantly. It's quite possible
 the typical latency of the network is already most of what the user
 experiences compared to the websocket relay, in which case the benefit of
 the 2nd WebRTC would be negligible with respect to the effort of making it
 happen maybe we need to measure this (I haven't found any obvious
 latency numbers on metrics.torproject.org), or we could just decide not to
 bother and close this.

 \\ Migrated from https://github.com/keroserene/snowflake/issues/8

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs