Subject: Re: [CDNi] Fwd: New Version Notification for draft-finkelman-cdni-sva-extensions-00.txt

From: Kevin Ma <[email-masked]>
Date: Thu, 16 Nov 2017 06:57:43 -0500

Hi All,

  As we discussed in the CDNI Session today, the chairs have begun looking
at WG rechartering and would like to gauge general WG interest in the
Streaming Video Alliance Open Caching proposals presented by Ori and Sanjay.

  We encourage you to read the draft and send mail to the list if you have
comments, questions, concerns, or just a thumbs up/down on any of the
topics discussed.

thanx!

--  Kevin and Francois

On Mon, Oct 30, 2017 at 4:42 PM, Ori Finkelman <[email-masked]> wrote:

> Dear CDNI working group,
> I have just submitted a draft for extension proposals for CDNI,
> These extensions are derived from the work done within the Open Caching
> working group of the Video Streaming Alliance (SVA).
> Open Caching is a specific case of CDNI and therefore we are looking to
> standardized these extensions and proposed new functionalities under the
> CDNI wg.
>
> Looking forward to get feedback from the cdni group.
>
> Best regards,
> Ori
>
>
>
> A new version of I-D, draft-finkelman-cdni-sva-extensions-00.txt
> has been successfully submitted by Ori Finkelman and posted to the
> IETF repository.
>
> Name:           draft-finkelman-cdni-sva-extensions
> Revision:       00
> Title:          CDNI SVA Extensions
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          25
> URL:            https://www.ietf.org/internet-
> drafts/draft-finkelman-cdni-sva-extensions-00.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-finkelman-cdni-sva-extensions/
> Htmlized:       https://tools.ietf.org/html/d
> raft-finkelman-cdni-sva-extensions-00
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-finkelman-cdni-sva-extensions-00
>
>
> Abstract:
>    The Open Caching working group of the Streaming Video Alliance is
>    focused on the delegation of video delivery request from commercial
>    CDNs to a caching layer at the ISP.  In that aspect, Open Caching is
>    a specific use case of CDNI, where the commercial CDN is the upstream
>    CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <072-222-1647> | Mobile:
> +972-52-3832189 <052-383-2189> | [email-masked]
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>
>

---

From: Kevin Ma <[email-masked]>
Date: Thu, 16 Nov 2017 07:27:08 -0500

Hi Ori,

  (As an individual) For request router address, I think you may want to
consider a prioritized list of endpoints.  My initial thought is that this
is something better suited for a Control/Bootstrap interface, but if the
request router addresses change over time, then perhaps FCI is the right
place for it.  Either way, I agree some discovery mechanism would be useful.

  For Fallback address, I don't see any issue with adding a new metadata
object for this purpose.

  For Triggers regex, I think this falls into the same category as the URI
Signing glob question Phil posed.  We have the simple pattern matching
because we originally thought regex would be too heavy, but if folks like
regex, conceptually I don't see a reason why we couldn't add it (or replace
the pattern match with regex).

  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.

  For Triggers geo-limit and scheduling, I think the concepts are useful.
The implementation probably needs to be hashed out more, per the
discussions in the working group meeting.  I think it would be good to use
these as a first implementation of trigger extensibility.  In general, I
like the idea of having something like generic-metadata for triggers.  We
didn't have a use case for it originally, but I think you have provided
valid use cases therefor.

  For Relayed token auth, this one I have concerns about.  I'm not sure how
the security folks will feel about this, but I think if you and Phil could
iterate on this, perhaps there's a reasonable solution to be found.

  For Logging, it would be unfortunate if the logging interface we
specified had to be completely bypassed.  If there is a need, then we
should address it, but I would be interested in hearing from vendors on
this.

  For CORS, I think this is an interesting topic and unfortunately we did
not have time to talk about it in the WG session.  I will be interested to
hear thoughts from the rest of the WG on the proposals.  It doesn't really
have to be in CDNI, but it might be useful to have.

thanx.

--  Kevin J. Ma

---

From: [email-masked]
Date: Fri, 17 Nov 2017 02:57:40 +0000

Kevin Ma wrote:
>For Logging, it would be unfortunate if the logging interface we specified had to be >completely bypassed.  If there is a need, then we should address it, but I would be interested in >hearing from vendors on this.
Primary motivators for specifying logging requirements in draft-finkelman-cdni-sva-extensions is largely because of CDNs already have and use Squid based logging and would rather not add a separate process to receive and process logging information sent by the dCDN (ISP’s open caching nodes). The other motivation was to add a negotiation capabilities between a dCDN and a uCDN on how to “transport” those logs across the two domains. The logging spec in “draft-finkleman…” allows this and again may leverage transport types (logstash, SFTP, Kafka etc).

Thanks
Sanjay

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma
Sent: Thursday, November 16, 2017 8:27 PM
To: Ori Finkelman <[email-masked]>
Cc: [email-masked]
Subject: [E] Re: [CDNi] Fwd: New Version Notification for draft-finkelman-cdni-sva-extensions-00.txt

Hi Ori,

  (As an individual) For request router address, I think you may want to consider a prioritized list of endpoints.  My initial thought is that this is something better suited for a Control/Bootstrap interface, but if the request router addresses change over time, then perhaps FCI is the right place for it.  Either way, I agree some discovery mechanism would be useful.

  For Fallback address, I don't see any issue with adding a new metadata object for this purpose.

  For Triggers regex, I think this falls into the same category as the URI Signing glob question Phil posed.  We have the simple pattern matching because we originally thought regex would be too heavy, but if folks like regex, conceptually I don't see a reason why we couldn't add it (or replace the pattern match with regex).

  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.

  For Triggers geo-limit and scheduling, I think the concepts are useful.  The implementation probably needs to be hashed out more, per the discussions in the working group meeting.  I think it would be good to use these as a first implementation of trigger extensibility.  In general, I like the idea of having something like generic-metadata for triggers.  We didn't have a use case for it originally, but I think you have provided valid use cases therefor.

  For Relayed token auth, this one I have concerns about.  I'm not sure how the security folks will feel about this, but I think if you and Phil could iterate on this, perhaps there's a reasonable solution to be found.

  For Logging, it would be unfortunate if the logging interface we specified had to be completely bypassed.  If there is a need, then we should address it, but I would be interested in hearing from vendors on this.

  For CORS, I think this is an interesting topic and unfortunately we did not have time to talk about it in the WG session.  I will be interested to hear thoughts from the rest of the WG on the proposals.  It doesn't really have to be in CDNI, but it might be useful to have.

thanx.

--  Kevin J. Ma

On Thu, Nov 16, 2017 at 6:57 AM, Kevin Ma <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

  As we discussed in the CDNI Session today, the chairs have begun looking at WG rechartering and would like to gauge general WG interest in the Streaming Video Alliance Open Caching proposals presented by Ori and Sanjay.

  We encourage you to read the draft and send mail to the list if you have comments, questions, concerns, or just a thumbs up/down on any of the topics discussed.

thanx!

--  Kevin and Francois

On Mon, Oct 30, 2017 at 4:42 PM, Ori Finkelman <[email-masked]<mailto:[email-masked]>> wrote:
Dear CDNI working group,
I have just submitted a draft for extension proposals for CDNI,
These extensions are derived from the work done within the Open Caching working group of the Video Streaming Alliance (SVA).
Open Caching is a specific case of CDNI and therefore we are looking to standardized these extensions and proposed new functionalities under the CDNI wg.

Best regards,
Ori

Name:           draft-finkelman-cdni-sva-extensions
Revision:       00
Title:          CDNI SVA Extensions
Document date:  2017-10-30
Group:          Individual Submission
Pages:          25
URL:            https://www.ietf.org/internet-drafts/draft-finkelman-cdni-sva-extensions-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dfinkelman-2Dcdni-2Dsva-2Dextensions-2D00.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=G57__ggdP8hJ3uZ3F0PGazlgq9ZfaQ4rT-jvMxEe9B8&e=>
Status:         https://datatracker.ietf.org/doc/draft-finkelman-cdni-sva-extensions/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfinkelman-2Dcdni-2Dsva-2Dextensions_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=z6r5V-t04fZvyCaT0Ou58tauQbLewrDJkt5arT18F9w&e=>
Htmlized:       https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfinkelman-2Dcdni-2Dsva-2Dextensions-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=3PN14xFCX28RVLaeylVgnu5XLf5NrCl0T8mzo5TXX7o&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-finkelman-cdni-sva-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dfinkelman-2Dcdni-2Dsva-2Dextensions-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=sHMfBp_rcLT3h0eQVAwceqM7RJUo1jt7MQ6ACv3G4tY&e=>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=H_4GnM-WRyvcG6tLMcbS4npdeovndNO2oMsru5EInwM&e=>.

The IETF Secretariat

--
Ori Finkelman
Qwilt | Work: +972-72-2221647<tel:072-222-1647> | Mobile: +972-52-3832189<tel:052-383-2189> | [email-masked]<mailto:[email-masked]>

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=PMnY8KpuUopuFhL6K52t4itbaoUkReKaZaVaU8J_HZM&s=6hmp7qo1TZSSiNlcW7bG_ucwl31519kZiI0tAEWTpLs&e=>

---

From: Ori Finkelman <[email-masked]>
Date: Fri, 17 Nov 2017 11:06:59 +0800

Hi Kevin,
I will try to pull more people from the SVA OCWG into CDNI so we can get
better perception of how content providers and CDNs will be using these
interfaces.
Please see comments below:

> place for it.  Either way, I agree some discovery mechanism would be useful.
[OF] >> Agree, will updated.

> think I like content.playlists better than playlist.urls, but that's a
[OF] >> I will change to content.playlists

>   For Relayed token auth, this one I have concerns about.  I'm not sure
> how the security folks will feel about this, but I think if you and Phil
> could iterate on this, perhaps there's a reasonable solution to be found.
>
[OF] >> Sanjay, maybe we can pull in to this discussion relevant people
from commercial CDNs so they can explain how they see logging from their
perspectives ?

> have to be in CDNI, but it might be useful to have.
[OF] >> As far as I understand, some relation to CORS is a must when
delegating between CDNs, otherwise the dCDN will not be sending the proper
CORS response headers and the client will not receive the content.
I agree tough, that this is a general caching issue, so technically that
could go into the generic caching specifications rather than CDNI. Do you
think there is an option to define it in a different working group ?
See what Fastly has to say about this
https://www.fastly.com/blog/caching-cors/
Basically they say you either have to use Vary, in which case you will get
different copies for different origins, or you can use logic to filter on
allows origins and set them properly in the ACAO response header, Fastly
use VCL for that, but that is an implementation detail.

>>   As we discussed in the CDNI Session today, the chairs have begun
>> looking at WG rechartering and would like to gauge general WG interest in
>> the Streaming Video Alliance Open Caching proposals presented by Ori and
>> Sanjay.
>>
>>   We encourage you to read the draft and send mail to the list if you
>> have comments, questions, concerns, or just a thumbs up/down on any of the
>> topics discussed.
>>
>> thanx!
>>
>> --  Kevin and Francois
>>
>>

--

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Nov 2017 12:15:48 +0000

Ori,

I have a question on the background to the extensions. Did the need for these extensions come from deploying the CDNI and Open Caching specifications and encountering limitations in the field?

Would be good to hear any feedback on implementing the CDNI specs and whether the RFCs are clear enough to implement from or whether there are ambiguities in the RFCs we should think about addressing e.g. via Errata.

Thanks
Ben

> On 30 Oct 2017, at 20:42, Ori Finkelman <[email-masked]> wrote:
> 
> Dear CDNI working group,
> URL:            https://www.ietf.org/internet-drafts/draft-finkelman-cdni-sva-extensions-00.txt <https://www.ietf.org/internet-drafts/draft-finkelman-cdni-sva-extensions-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-finkelman-cdni-sva-extensions/ <https://datatracker.ietf.org/doc/draft-finkelman-cdni-sva-extensions/>
> Htmlized:       https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00 <https://tools.ietf.org/html/draft-finkelman-cdni-sva-extensions-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-finkelman-cdni-sva-extensions-00 <https://datatracker.ietf.org/doc/html/draft-finkelman-cdni-sva-extensions-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> 
> -- 
> Ori Finkelman
> Qwilt | Work: +972-72-2221647 <tel:072-222-1647> | Mobile: +972-52-3832189 <tel:052-383-2189> | [email-masked] <mailto:[email-masked]>_______________________________________________
> CDNi mailing list
> [email-masked]

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Nov 2017 12:28:15 +0000

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

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.

Support for multiple optional playlist formats therefore (IMO) works against interoperability. What is the use case for requiring multiple optional playlist formats?

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?
 
Thanks
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Nov 2017 14:27:05 +0000

Sanjay, Ori, Colleagues,

> On 17 Nov 2017, at 02:57, [email-masked] wrote:
> 
> Kevin Ma wrote:
> Primary motivators for specifying logging requirements in draft-finkelman-cdni-sva-extensions is largely because of CDNs already have and use Squid based logging and would rather not add a separate process to receive and process logging information sent by the dCDN (ISP’s open caching nodes).

I do not find this argument particularly persuasive. Our purpose at IETF is to specify interoperability and introducing a new format works against that goal IMO. Not all CDNs produce squid-format logs, so squid-format is not a magic bullet, people are always going to have to support some kind of transformation if they want CDNs that use different logging formats to interoperate.

The working group standardised on the format specified in RFC7937. Introduction of a second format just to satisfy a subset of CDNs that use a different format doesn’t solve the problem it just moves it around and places the burden of transformation on another party, it doesn’t solve it.

The example cited in the draft of logging the hit/miss status of the request is already supported by RFC7937 through the s-cached field. It only logs hit vs miss although could be extended to support additional granularity rather than introducing a new log format along which would bring with it the interoperability concerns having another format raises.

Regards
Ben

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 29 Nov 2017 18:57:29 +0200

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

-- 

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

---

From: Ori Finkelman <[email-masked]>
Date: Wed, 29 Nov 2017 19:06:03 +0200

Hi Ben,
We are only at the beginning of implementation, most of the issues were
raised in spec phase, not implementation phase, I will update as we
progress into implementation.
I have already raised several issues on CDNI drafts, editorial, typos and
some functional, which have led to changes in draft and some errata to
existing RFCs.
However, I have done so by working directly with Kevin Ma as it was before
I have joined the CDNI group and mailing list, my bad I suppose.
All future such communications will be done over the CDNI mailing lists.

Thanks for bringing it up.

Best regards,
Ori

On Tue, Nov 28, 2017 at 2:15 PM, Ben Niven-Jenkins <[email-masked]>
wrote:

> Ori,
>
> I have a question on the background to the extensions. Did the need for
> these extensions come from deploying the CDNI and Open Caching
> specifications and encountering limitations in the field?
>
> Would be good to hear any feedback on implementing the CDNI specs and
> whether the RFCs are clear enough to implement from or whether there are
> ambiguities in the RFCs we should think about addressing e.g. via Errata.
>
> Thanks
> Ben
>

--

---

From: Kevin Ma <[email-masked]>
Date: Thu, 30 Nov 2017 00:35:35 -0500

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

> 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.
>>
>>
>> Support for multiple optional playlist formats places a burden on the
>> dCDN to support the multiple playlist formats. Multiple optional playlist
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 <+972%2072-222-1647> |
> Mobile: +972-52-3832189 <+972%2052-383-2189> | [email-masked]
>