mb field persistency

[bbert]

When CMSD support has been implemented in dash.js, among the player behavior requirements, the following requirement for mb parameter processing was provided (see https://github.com/Dash-Industry-Forum/dash.js/issues/4071):

"If the "mb" Max-suggested-bitrate is present, then use that value as an upper-bound for the ABR algorithm. If the player ... This restriction should hold until a higher or lower 'mb' value is received, or the end of stream is reached. ..."

And: "2.3 mb: Applies until another value is received. Cancel by setting high value."

What motivated to handle mb parameter in this manner, i.e. make mb being persistent on player side and request sending a new higher value from server in order to cancel any previous mb value?

Wouldn't be simpler and more sensible to make mb value not persistent and consider that if mb is not sent by the server then no limit is applied (anymore)?

One potential important issue can be raised in case of CDN switching: if a player switches from a server that sends an mb limit to a server that does send any mb limit, then the player will still apply the previously received mb from the 1st server.

[acbegen]

Wouldn't be simpler and more sensible to make mb value not persistent and consider that if mb is not sent by the server then no limit is applied (anymore)?

In that case, it needs to be repeated all the time till it is no longer applicable. Maybe, that was one of the reasons?

One potential important issue can be raised in case of CDN switching: if a player switches from a server that sends an mb limit to a server that does send any mb limit, then the player will still apply the previously received mb from the 1st server.

Yeah, this would be a problem, though the ABR client can be smart enough to cancel any mb restriction in case of a CDN switch. This could be clarified. Or maybe a middle ground is that mb is persistent for a brief amount of time (like fixed 10 seconds or for a duration indicated in a separate parameter)?

[thasso]

I would also like to get some clarification on this. I can understand that repeating the value with every request might seem like overhead, although I am not sure if this is really a practical problem.

Assuming that a bandwidth limit imposed by an edge node would only be the exception and not the rule, I would be in favour of having it strictly defined as a value that does not apply if it is not explicitly send.

The benefit of this would be that the client implementation would not need to maintain any state. Also the edge that sends the value would not need to track any session specific state.

From a client perspective I would argue that it is much easier to implement correctly if any values, and this one in particular, effect only the next request.

[wilaw]

I would support that in V2 of CMSD that we tighten the definition of 'mb' such that it is a restriction which applies until the next load of the object type on which it is sent. Setting it on every segment response is not an onerous requirement for a CDN and it provides fine-grained control for those who want to use it for server-guided ABR.

[bbert]

One more argument for having mb field not persistent is the use case of CDN mid-stream switching, when you switch from a CDN that limited to a given bitrate to another CDN that has no bitrate limit. In that case, if the mb is not persistent then the player would be able to request higher bitrate on the new CDN, at least from the second segment after switching.