Multiple subscriptions could cause resource exhaustion

[ianswett]

Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit.

The simplest idea would be to have a limit specified as a parameter in the server's SETUP message.

As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?

[kixelated]

rofl I just came here to post the same issue. See: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack

I think we follow QUIC and have a MAX_SUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends SUBSCRIBE_ERROR or SUBSCRIBE_RESET (TODO).

I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.

[kixelated]

Also do we need MAX_ANNOUNCES? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.

[ianswett]

A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: #282

Announces also likely need some limits, but I'm less clear on how that might work.

[kixelated]

I propose a monotonically increasing Subscribe ID in the SUBSCRIBE message. You can't reuse Subscribe IDs. We add a MAX_SUBSCRIBES message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value.

The corresponding SUBSCRIBE_OK, SUBSCRIBE_ERROR, SUBSCRIBE_RESET, SUBSCRIBE_FIN, UNSUBSCRIBE messages use that ID instead of echoing the full track name. This removes ambiguity and overhead.

We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example:

<-- MAX_SUBSCRIBES max=2
--> SUBSCRIBE id=0 track_id=2314 track_name=foobar start_group=-1
--> SUBSCRIBE id=1 track_id=2314 track_name=foobar start_group=653
<-- SUBSCRIBE_OK id=0
<-- SUBSCRIBE_ERROR id=1 code=404
<-- OBJECT track_id=2314 group=673
<-- MAX_SUBSCRIBES max=3
--> SUBSCRIBE id=2 track_id=2314 track_name=foobar start=670
...

Same for s/SUBSCRIBE/ANNOUNCE.

[ianswett]

Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.

[ianswett]

This is related to #282

[suhasHere]

may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..

[ianswett]

As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAX_SUBSCRIBE_ID frame to increase the limit, similar to QUIC flow control.

[ianswett]

The consensus at the session today was to go with a QUIC style approach, so I wrote #491

There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.

[martinduke]

Will assign to Mike English