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

[Ori Finkelman <[e-mail]>]

Kevin, Ben,  Colleagues,

I am working on the playlist specifications and would like to get your
views on the question of playlist types.

Should it be implicit from the playlist file extension (or even from the
file format) for example *.m3u8 is HLS, *.ismc is MSS, *.mpd is DASH.
or, the palylist object should explicitly state that type of playlist, for
example:
    {
       "playlist": "https://www.example.com/a/b/c/1/index.m3u8",
       "type": hls
    }

I think that the explicit option is preferable due to the following
+ it allows to register more types
+ it allows for private implementations to have their own private types.
+ it allows the dCDN to advertise which types it supports via the FCI (I am
working on extending it to support trigger objects).

Thanks,
Ori




On Thu, Nov 30, 2017 at 7:35 AM, Kevin Ma <[e-mail]> wrote:

> (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]
>>
>
>


-- 

*Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
[e-mail]