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

From: Ori Finkelman <[email-masked]>
Date: Tue, 6 Feb 2018 09:42:56 +0200

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 <[email-masked]> 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 <[email-masked]> wrote:
>
>> Hi Ben,
>> Please see some comments and answers below
>>
>> On Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <
>> [email-masked]> 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 <[email-masked]> 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: +972-72-2221647 <+972%2072-222-1647> |
>> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
>>
>
>

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: Ori Finkelman <[email-masked]>
Date: Tue, 6 Feb 2018 13:40:48 +0200

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 <[email-masked]> wrote:

> + 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
>
>
>
>
>> 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?
>>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile:
> +972-52-3832189 <052-383-2189> | [email-masked]
>

--

---

From: "Kevin J. Ma" <[email-masked]>
Date: Tue, 6 Feb 2018 23:38:48 -0500

(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 <[email-masked]> 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 ?
> 
>> 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:
>>     { 
>> + 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
>> 
>> 
>> 
>> 
>>> > [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 Tue, Nov 28, 2017 at 2:28 PM, Ben Niven-Jenkins <[email-masked]> 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.
>>>>> 
>>>>> 
>>>>> >   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: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
>>> 
>> 
>> 
>> 
>> -- 
>> Ori Finkelman
>> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | [email-masked]

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 7 Feb 2018 13:57:16 +0200

There is the CDNI protocol registry in
https://tools.ietf.org/html/rfc8006#section-7.3 but since these are used
for a different purpose it seems to me they should have a separate registry.
I am not sure about IANA media types as these are used for that specific
purpose, to serve as media types in HTTP responses, which are not what we
need.

I am starting with a new registry within the draft, if we find something
better I will switch to it.

Thanks,
Ori

On Wed, Feb 7, 2018 at 6:38 AM, Kevin J. Ma <[email-masked]>
wrote:

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

--