Client requirement regarding how to handle multiple MPD Location elements is ambiguous

[chrisfillmore]

DASH IOP v4.3 in the section on MPD Location and Reference Resolution says the following:

3.2.15.3. Client Requirements and Recommendations Based on these descriptions, a DASH client operating on MPD updates and segment requests is expected to operate as follows:

• For MPD update requests (when due) according to clause 5.4, the DASH client requests the MPD according to the following priority
  • If at least one MPD.Location element is present,
  • any the value of any MPD.Location element is used as the MPD request URL

Suppose there are multiple <Location> in the MPD. How is the client expected to prioritize these? It seems that content providers may have different goals in providing multiple <Location> elements:

• Clients should respect the order of the elements, because each subsequent <Location> is a failover for the one which precedes it.
• Clients should select randomly from these elements, for load-balancing purposes.

This could be remedied with a new attribute, e.g. sequenceGroup which could clarify the order and grouping of the elements:

<Location sequenceGroup="0">url1.mpd</Location>
<Location sequenceGroup="0">url2.mpd</Location>
<Location sequenceGroup="1">url3.mpd</Location>

Thus the client could randomly select between url1.mpd and url2.mpd, and if both fail, attempt url3.mpd as a failover. The order of the <Location> elements is irrelevant. If only one <Location> is present, the attribute can be omitted.

This is just an idea off the top of my head so of course feedback is welcome. If you think it is a good idea, I could write a more formal and clear specification for inclusion in the spec. Thank you.

[sandersaares]

I suppose this logic should be synchronized also with multiple <BaseURL> elements?

[chrisfillmore]

Yes I expect they could share the same definition for this new attribute.

[technogeek00]

Oddly the 23009-1 DASH specification mentions that clients may implement any suitable algorithm to determine which BaseURL to use for requests, but doesn't provide a mechanism for signaling author usage preference.

Seems like a fairly beneficial mechanism to add. As a point of reference the majority player implementations I've seen use XML parse order as fallback order.

[sandersaares]

We also run into this in security chapter with DRM service URLs. Ideally, we could reference a single recommended algorithm everywhere the URL is used.

Anyone volunteer to write up a global-scope URL handling chapter?

[chrisfillmore]

I just noticed the DVB DASH profile has a definition for this:

10.8.2.2 Selection of BaseURL When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows:

• It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in clause 10.8.2.1, that have the lowest @priority attribute value.
• If there is more than one BaseURL with this lowest @priority attribute value then the Player shall select one of them at random such that the probability of each BaseURL being chosen is proportional to the value of its @weight attribute. The method described in IETF RFC2782[24] or picking from a number of weighted entries is suitable for this, but there may be other algorithms which achieve the same effect.
• If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error.

Once a random selection has been carried out amongst a group of BaseURLs with the same @priority attribute value, then that choice should be re-used if the selection needs to be made again unless the blacklist has been modified or the available BaseURLs have changed.

https://dvb.org/wp-content/uploads/2019/12/a168_dvb_mpeg-dash_oct_2019.pdf