Re: [CDNi] Triggers playlist: draft-finkelman-cdni-sva-extensions-00.txt

[Kevin Ma <[e-mail]>]

(as an individual)

> [OF] >> I think the dCDN should return an error for unsupported format
and the uCDN should not delegate that service to the dCDN

Ideally, the uCDN would not attempt to send a playlist URL if the dCDN has
not advertised the playlist URL trigger capability.

> Is the uCDN expected to fallback to producing a trigger request with the
URLs from the playlist enumerated as *.urls/*.patterns?

I would expect so.  I think of the playlist URL more as an optional
optimization.  Without this optimization, the uCDN would be using
individual urls/patterns anyway -- though for prepositioning, patterns are
trickier and the playlist becomes arguably more useful.

On Wed, Nov 29, 2017 at 11:57 AM, Ori Finkelman <[e-mail]> wrote:

> Hi Ben,
> Please see some comments and answers below
>
> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <
> [e-mail]> wrote:
>
>> Ori, Colleagues,
>>
>> I just read draft-finkelman-cdni-sva-extensions-00 and have some
>> comments I will send in separate emails to keep each conversation to a
>> single topic.
>>
>>
>> > On 16 Nov 2017, at 12:27, Kevin Ma <[e-mail]> wrote:
>> >
>> >   For Triggers playlist, a long time ago we decided to not deal with
>> HTTP adaptive streaming to simplify the initial scope, but I think video
>> and HAS awareness is probably necessary and worthwhile for us to
>> re-address.  I think I like content.playlists better than playlist.urls,
>> but that's a detail.
>>
>> Support for multiple optional playlist formats places a burden on the
>> dCDN to support the multiple playlist formats. Multiple optional playlist
>> formats places a burden on the uCDN, e.g. it needs to be able to handle a
>> dCDN that does not support a particular playlist e.g. by transforming the
>> playlist to a dCDN supported format or by falling back to a list of URLs
>> carried in the triggers request.
>>
> [OF] >> Another option would be for the uCDN NOT to delegate traffic of
> un-supported playlist format. That would motivate the dCDN to support all
> of them.
>
>>
>> Support for multiple optional playlist formats therefore (IMO) works
>> against interoperability. What is the use case for requiring multiple
>> optional playlist formats?
>>
> [OF] >> I agree that multiple formats is not in favor of interoperability,
> but this is where the video industry currently stands, so we can decide not
> to standardize it but then we will need to find other solutions for the
> video use cases. ABR protocol awareness is something video CDNs have to do
> anyway. Features like trans-packaging at the edge are already being
> discussed and developed, and for trans-packaging the dCDN cache has to be
> manifest type aware.
> So, basically we could treat it as just a list of files, but I am not sure
> it is in favor of the whole solution.
>
>>
>> What is the envisioned model if a dCDN does not support playlists in
>> trigger requests? Is the uCDN expected to fallback to producing a trigger
>> request with the URLs from the playlist enumerated as *.urls/*.patterns?
>>
> [OF] >> I think the dCDN should return an error for unsupported format and
> the uCDN should not delegate that service to the dCDN.
>
>
>>
>> Thanks
>> Ben
>>
>>
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] <+972%2072-222-1647> |
> Mobile: [phone] <+972%2052-383-2189> | [e-mail]
>