[tor-talk] Multicast Onion Services for video-streaming?

[Ben Tasker]

I don't have an answer on the multicast front, but I've been playing around
with Video delivery via onion recently - partly as an intensive way to test
delivery and partly to see how feasible it actually is.

The delivery infrastructure was/is a tiered caching heirachy, with each
tier having it's own HS

I'm not quite ready to write it all up yet, but as it partly ties into your
question figured I'd mention some of what I've observed so far.

HTTP Adaptive Streaming (HAS) works well using hidden services (I've
primarily been using HLS), subject to a couple of caveats.

- If the edge cache has to go upstream (to the midtier), it's incredibly
expensive and introduces substantial delay.

- There seems to be a risk of circuit collapse if a cache is taking too
many requests. If that cache happens to the midtier, then you're stuck
unless there are multiple caches in the midtier or the edge is also allowed
to go to the origin.

Caveat 1 can be offset by increasing the video segment length. 2 second
segments were nigh on unwatchable, whereas 10 second segments play pretty
reliably.

I haven't checked in depth yet, but the acquisition times look about the
same for both, so it's possible the overhead is in establishing a circuit
rather than necessarily how quickly the bits can be delivered to the edge.

1080p video at 60 fps is do-able but highly unreliable (but then, it's the
same on the clearnet). Compression could help here.

480p works reliably. I've not got as far as 720 yet.

My theory on the bandwidth consumption side was that each edge device could
be capped at a certain throughput (say 100Mb/s for easy maths). A number of
new relays could then be added to contribute back the same (or more).

So, 6 edges, means adding 3 200Mb/s relays.

Alternatively as it's tiered, the edge knows nothing about the origin, so
you could conceivably have the edges also act as relays.

There's a bit of setup involved, but then even on the clearnet, delivering
video to a lot of clients requires a bit of infrastructure.

Ben
On 17 Jan 2016 12:08, "Fabio Pietrosanti (naif) - lists" <
lists at infosecurity.ch> wrote:

> Within the Italian Nexa Center for internet and Society mailing list,
> there was recently a discussion on the IP-level blocking forced by the
> government's judges to ISPs against "informal/unofficial" football video
> streaming services.
>
> I learned that those kind of services, usually provide browsers plug-in
> to distribute the streaming in a semi-p2p-bittorrent-way.
>
> Btw, the IP-blocking regardless of the reasons, is basically censorship.
>
> I was wondering if Tor network couldn't be a network/platform for that
> kind of video-streaming-services.
>
> Obviously the problem is that video-streaming require a lot of bandwidth
> and massive-services attract a lot of users, so even brainstorming
> something about it, would imply thinking a network/application design
> that does not increase linearly the bandwidth resources required for
> each new user.
>
> So, it come up to my mind that in MAN (metropolitan area network) that
> share a common network topology and software, multicast is used for that
> kind of purposes.
>
> On my italian fiber service provider Fastweb, when i use their own TV
> with their own set-top-box and click "Channel X", there's basically a
> "join" to a multicast group, that will then deliver me the streaming and
> in their network topology there are "edges" that does cache and
> redistribute the content.
>
> So, i was wondering if the multicast streaming concept for content
> distribution with edges-caching, couldn't fit somehow in a future Tor
> network use-cases or design.
>
>
> --
> Fabio Pietrosanti (naif)
> HERMES - Center for Transparency and Digital Human Rights
> http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
> https://ahmia.fi
> --
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>