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

["Kevin J. Ma" <[e-mail]>]

(as an individual) I think an explicit type is probably better from an interoperability standpoint; and if you go with one, I would make it mandatory.  The question I would ask is: Do we need a registry for types?  Or are there existing type specifications that we could reference/use (e.g., IANA media types would be great if they existed...)?

Sent from my iPhone

> On Feb 6, 2018, at 6:40 AM, Ori Finkelman <[e-mail]> wrote:
> 
> And, if we use the explicit option, is the type mandatory, or the implementation may choose to omit it and rely on the dCDN to be able to auto-detect it by file extension or format ?
> 
>> On Tue, Feb 6, 2018 at 9:42 AM, Ori Finkelman <[e-mail]> wrote:
>> 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] | Mobile: [phone] | [e-mail]
>>> 
>> 
>> 
>> 
>> -- 
>> Ori Finkelman
>> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: [phone] | Mobile: [phone] | [e-mail]