search

moq-wg / moq-requirements

Other
11 stars 3 forks source link

QUIC transport: P2P or client/server? #103

Open aboba opened 1 year ago

aboba commented 1 year ago

Today there are streaming services that support P2P caching (eCDN). This is done to improve scalability. For example, consider a use case involving a Company-wide meeting. Using P2P caching, bandwidth usage can be reduced. Instead of having every employee receive their own stream from the server or CDN, the media could be obtained from a neighboring employee, reducing ingress bandwidth usage. Typically these P2P caching services are implemented using a P2P transport such as WebRTC data channel, since this enables traversal of firewalls and NATs within the enterprise network.

The question is whether it would be desirable for MoQ to support P2P QUIC transport natively. The advantage is that a single protocol (MoQ) would be used to receive a stream as well as for "fan out", rather than using two distinct protocols (e.g. MoQ and WebRTC data channel).

fiestajetsam commented 1 year ago

Just for note taking - I presume this is in conjunction with this W3C draft document and the surrounding work.

SpencerDawkins commented 1 year ago

@aboba - you're asking an interesting question, but I find myself wondering whether this relies on at least some extension to the base QUIC protocols, which are rather client-server. We need to think/talk about this, and if extensions are required, whether we should start work on that in MOQ, or in QUIC.

(@SpencerDawkins finds himself wondering whether this needs to be discussed in an architecture draft context, but that's another story)

SpencerDawkins commented 1 year ago

I think the Right Thing To DO is for us to participate in, and gate this issue on, discussion of draft-seemann-quic-nat-traversal-00 and draft-thatcher-p2p-quic-00 in the QUIC working group. @lpardue, is that WRONG?

I'll leave this tagged "Deferred for now" for now.

SpencerDawkins commented 1 year ago

@SpencerDawkins and @fiestajetsam chatted about this, and we think MoQ is probably lined up behind RoQ on this. @SpencerDawkins will follow up with the relevant authors and QUIC working group chairs on behalf of RoQ, and if we end up with a plan that works for RoQ, we can circle back for MoQ.