Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 7 Jun 2011 09:41:09 +0100

Kevin,

I have a couple of questions to better understand the use case you are thinking of, please see inline.

On 25 May 2011, at 01:01, Kevin J Ma wrote:

> Francois,
> 
>  We had discussed updating three of the requirements:
> 
>  - R36 discusses limiting the number of redirects for a content request.
>    We interpret this as a hop count?  For certain types of live content
>    (e.g., HLS) it might be advantageous to include a time-based limit.
>    Can we modify the text to include an optional temporal limit?  e.g.:

Your mention of "certain types of live content (e.g. HLS)" gives me the impression that you think that type of content has some special properties for which a time-based limit may be advantageous where it may not be advantageous for other types of content? Could you expand on what those properties of HLS/live content are?

Is your concern that an excessively long request routing chain will negatively impact the "startup time" of the content (which would apply to all content types), or something else?

>    "R36  The CDNI Request-Routing protocol SHOULD support an optional
>          mechanism enforcing a limit on the number of successive CDN
>          redirections or the total elapsed time for a given request."

An upstream CDN is always in the position where it can timeout a Request Routing request to a downstream CDN and take some alternative action without needing to pass timing (or timing budgets) between CDNs.

Is the intent to enable an upstream CDN to control the timeout used by downstream CDNs (e.g. an upstream CDN can communicate a timeout budget to an intermediate CDN which can take its portion of that budget and pass the remainder on to a downstream CDN, etc) so the timeout between CDNs can be more finely tuned by an upstream CDN, or something else?

Thanks
Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 10 Jun 2011 14:20:25 +0200

Hi Kevin,

Working my way through your suggestions:
> 
>  - R58 lists potential content distribution control policies.  There are
>    sometimes contractual obligations which limit which CDNs may be used.
>    Can we add a bullet for whitelisting/blacklisting CDNs?  e.g.:
> 
>      "*   delegation whitelist/blacklist (i.e.  Information defining
>           which Downstream CDNs the content may be delivered through)"

That makes sense to me.
And in any case, the bullets are described as examples, so we'll add this bullet in the next rev, unless someone else objects/

Thanks

Francois

> 
> thanx!
> 
> --  Kevin J. Ma
> 
>> -----Original Message-----
>> From: Francois Le Faucheur [mailto:[email-masked]]
>> Sent: Tuesday, May 24, 2011 9:49 AM
>> To: Kevin J Ma
>> Cc: Le Faucheur Francois; [email-masked]
>> Subject: incorporating a few requirements from cdni-publisher-use-cases
>> into cdni-requirements
>> 
>> Hello Kevin,
>> 
>> I believe we had agreed in Prague that a couple of requirements that were
>> implied in cdni-publisher-use-cases should make their way into cdni-
>> requirements.
>> Could you recap on those so we can consider/discuss as we rev up cdni-
>> requirements?
>> 
>> Thanks
>> 
>> Francois
>> 
>> PS: I believe the IESG has not yet made a final determination with respect
>> to creation of a CDNI WG. But I suggest we resume the work/progress on
>> this list nonetheless.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 10 Jun 2011 14:47:48 +0200

> 
> 
>  - R38 discusses pushing upstream metadata to the downstream CDN.

Just to make sure we are on the same page:
I would say that R38 discusses the option of the upstream CDN providing to the downstream CDN, inside the Request Routing request, a pointer to CDNI metadata. So more of an option to allow metadata "pull" (than "push")..
I think we agree, right?

>  It
>    was not clear if this was inclusive of all hierarchical metadata,
>    i.e., can/should the upstream send aggregate default metadata, which
>    may be useful in future requests for related content?  Can we modify
>    the text to clarify the conveyance of inherited metadata?  e.g.:

That makes sense to me.

>    "R38  The CDNI Request-Routing protocol MAY also allow the Upstream
>          CDN to convey information pointing to CDNI metadata associated
>          with the requested content or an object set to which the
>          requested content belongs."

To ensure full consistency with the terminology used in the rest of the document already discussing metadata inheritance (e.g. R55), I'd propose :

"
   R38  The CDNI Request-Routing protocol MAY also allow the Upstream CDN to convey information pointing to CDNI metadata applicable (individually or through inheritance) to the requested content. For illustration, the CDNI metadata pointed to could potentially include  metadata that is applicable to any content, metadata that is applicable to a content collection (to which the requested content belongs) and/or metadata that is applicable individually to the requested content.

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 10 Jun 2011 15:49:53 +0200

Folks,

On 27 May 2011, at 17:47, David Harrington wrote:

> Hi,
>  
> This is a status update from your Responsible AD.
>  
> 1) The IESG has discussed where a CDNI WG would be best located. It was decided that, if approved, CDNI WG belonged in the TSV area and I would remain the Responsible area director.
>  
> 2) I have requested the IESG discuss the proposed WG charter in the IESG telechat 6/9.
>  
> 3) I have asked the BOF chairs to request a BOF session at ietf81 Quebec. This ensures the CDNI community will have a session at ietf81.

To allow forward progress while the IESG determination is being made, Richard and I put together a first draft of a BOF agenda for bashing:
http://www.ietf.org/proceedings/81/agenda/cdni.htm

Please pass on comments and let us know if you plan posting new I-Ds or if you are listed as a tentative presenter but don't plan attending.

Generic info on the CDNI session in Quebec is available from the IETF BOF wiki:
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

>  
> 4) If the IESG approves the WG, the BOF session will simply become a WG session.

and the appointed WG chairs will then take over and presumably adjust the agenda as needed.

Cheers

Francois & Richard

PS: 

>  
>  
> David Harrington
> Director, IETF Transport Area
> [email-masked] (preferred for ietf)
> [email-masked]
> +1 603 828 1401 (cell)
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Jun 2011 12:12:40 -0400

Hi,
 
FYI.
 
The IESG reviewed the proposed charter and was satisfied that it was
ready to be reviewed externally.
The proposed charter will now be circulated to the IETF general list
plus other standards organizations for comment.
After that, it will return to the IESG for further discussion.
 
During that period, the IAB and IESG will also discuss it as a
potential second BOF.
 
David Harrington

  _____  

From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Friday, June 10, 2011 9:50 AM
To: [email-masked]
Cc: Le Faucheur Francois; Richard Woundy; David Harrington
Subject: Re: [CDNi] cdni status

Folks, 

Hi,

1) The IESG has discussed where a CDNI WG would be best located. It
was decided that, if approved, CDNI WG belonged in the TSV area and I
would remain the Responsible area director.
 
2) I have requested the IESG discuss the proposed WG charter in the
IESG telechat 6/9.
 
3) I have asked the BOF chairs to request a BOF session at ietf81
Quebec. This ensures the CDNI community will have a session at ietf81.

To allow forward progress while the IESG determination is being made,
Richard and I put together a first draft of a BOF agenda for bashing:
http://www.ietf.org/proceedings/81/agenda/cdni.htm

Please pass on comments and let us know if you plan posting new I-Ds
or if you are listed as a tentative presenter but don't plan
attending.

Generic info on the CDNI session in Quebec is available from the IETF
BOF wiki:
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

4) If the IESG approves the WG, the BOF session will simply become a
WG session.

and the appointed WG chairs will then take over and presumably adjust
the agenda as needed.

Cheers

Francois & Richard

PS: 

 
David Harrington

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 10 Jun 2011 13:36:10 -0400

Hi Ben,

  responses inline:

> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 4:41 AM
> To: Kevin J Ma
> Cc: Francois Le Faucheur; [email-masked]
> Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-
> use-cases into cdni-requirements
> 
> Kevin,
> 
> Your mention of "certain types of live content (e.g. HLS)" gives me the
> impression that you think that type of content has some special properties
> for which a time-based limit may be advantageous where it may not be
> advantageous for other types of content? Could you expand on what those
> properties of HLS/live content are?

The qualification was for streaming (RTP) vs file-based (HLS), i.e. push vs pull.
In the former, the latency can be handled by drops, but in the latter, the client
has other recourse if a request takes too long.

> Is your concern that an excessively long request routing chain will
> negatively impact the "startup time" of the content (which would apply to
> all content types), or something else?

I was really thinking about the mid-stream rate adaptation/error recovery case.
The client, at some point, will try its alternatives, e.g., different bitrate, 
different locations, etc.  The latency of the request impacts those features.

> An upstream CDN is always in the position where it can timeout a Request
> Routing request to a downstream CDN and take some alternative action
> without needing to pass timing (or timing budgets) between CDNs.
> 
> Is the intent to enable an upstream CDN to control the timeout used by
> downstream CDNs (e.g. an upstream CDN can communicate a timeout budget to
> an intermediate CDN which can take its portion of that budget and pass the
> remainder on to a downstream CDN, etc) so the timeout between CDNs can be
> more finely tuned by an upstream CDN, or something else?

That was the intent, yes.

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 10 Jun 2011 19:05:53 -0400

sounds good.  thanx.

> Sent: Friday, June 10, 2011 8:48 AM
> To: Kevin J Ma
> Subject: Metadata pointer in Request Routing (was Re: incorporating a few
> requirements from cdni-publisher-use-cases into cdni-requirements)
> 
> >
> >
> I would say that R38 discusses the option of the upstream CDN providing to
> the downstream CDN, inside the Request Routing request, a pointer to CDNI
> metadata. So more of an option to allow metadata "pull" (than "push")..
> I think we agree, right?
> 
> >  It
> To ensure full consistency with the terminology used in the rest of the
> document already discussing metadata inheritance (e.g. R55), I'd propose :
> 
> "
>    R38  The CDNI Request-Routing protocol MAY also allow the Upstream CDN
> to convey information pointing to CDNI metadata applicable (individually
> or through inheritance) to the requested content. For illustration, the
> CDNI metadata pointed to could potentially include  metadata that is
> applicable to any content, metadata that is applicable to a content
> collection (to which the requested content belongs) and/or metadata that
> is applicable individually to the requested content.
> 
> Francois
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:09:10 +0100

Kevin,

Thanks, please see inline.

> has other recourse if a request takes too long.

I don't quite understand, in both cases the client is able to "timeout" due to latency (or some other issue) and take a different course of actual (attempt a re-connect, fallback to alternative source, etc.)

> different locations, etc.  The latency of the request impacts those features.

Thinking out loud...That's true but in typical HTTP adaptive streaming deployments that I have experience of the client typically holds open one or more persistent connections over which it requests the files/chunks so request routing is not performed per file/chunk in the stream and therefore request routing latency is an issue for "startup time" but not for mid stream adaptation.

Regarding error recovery, I suspect typical recovery is to an alternative IP address returned in the same A/AAAA record as the IP address that just "failed" so there wouldn't be any request routing latency there either (as I'm not aware of HTTP adaptive manifests/playlists being able to encode multiple alternative URIs for the same files/chunks).

I guess more complex error recovery could be performed (e.g. by the client going back to whatever "portal" issued the original URI for the manifest/playlist) but that's as close as it gets to being the same as a "channel change" type scenario rather than mid-stream adaptation.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:09:07 +0100

Kevin, Francois,

> And in any case, the bullets are described as examples, so we'll add this bullet in the next rev, unless someone else objects/

I don't want to actually object but I would urge some caution as fulfilling this sort of requirement starts to stray into the problem of how to uniquely name different CDNs and that's a whole new potential can of worms that I'd prefer we avoid but not introducing a requirement for it at the protocol level.

I'm certainly aware of contractual obligations that restrict where a CDN may store content, where it may deliver content from and who it may deliver content to but I haven't (yet) come across a requirement from Content Providers to be prescriptive on which CDNs are allowed to be used (versus the minimum delivery protection/capabilities the CDN must support/use).

Maybe describing a use case of why such a restriction may be requested would help make the need for the requirement clearer?

Thanks
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:09:00 +0100

Francois,

> Please pass on comments and let us know if you plan posting new I-Ds or if you are listed as a tentative presenter but don't plan attending.

I see you have put a yet to be written Framework draft on the proposed agenda. I've been intending to produce such a framework draft for a few weeks but haven't quite had the cycles to put pen to paper.

I'll try and pull something together before Quebec, if others are interesting in contributing to that I'm happy to co-ordinate any inputs they have.

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 13 Jun 2011 19:27:18 -0400

Ben,

  inline:

> Sent: Monday, June 13, 2011 6:09 PM
> To: Kevin J Ma
> I don't quite understand, in both cases the client is able to "timeout"
> due to latency (or some other issue) and take a different course of actual
> (attempt a re-connect, fallback to alternative source, etc.)

This is true.  But, if the CDN thinks that it is going to time out, and can
make that decision earlier, then the client does not have to timeout if the
CDN just responds to that affect.  In that case, it leaves the client extra
timing margin to go try its alternatives.

> Thinking out loud...That's true but in typical HTTP adaptive streaming
> deployments that I have experience of the client typically holds open one
> or more persistent connections over which it requests the files/chunks so
> request routing is not performed per file/chunk in the stream and
> therefore request routing latency is an issue for "startup time" but not
> for mid stream adaptation.

Persistent connections are not necessarily a given.  My iPhone does not use
persistent connections.

> Regarding error recovery, I suspect typical recovery is to an alternative
> IP address returned in the same A/AAAA record as the IP address that just
> "failed" so there wouldn't be any request routing latency there either (as
> I'm not aware of HTTP adaptive manifests/playlists being able to encode
> multiple alternative URIs for the same files/chunks).
> 
> I guess more complex error recovery could be performed (e.g. by the client
> going back to whatever "portal" issued the original URI for the
> manifest/playlist) but that's as close as it gets to being the same as a
> "channel change" type scenario rather than mid-stream adaptation.

Fair point.  An application may choose to implement it like a channel change,
but if it is done under the covers, it is still mid-stream adaptation in the
eyes of the end-user.  It is still an example of something an application may
wish to do that is affected by latency.

thanx.

--  Kevin J. Ma

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 13 Jun 2011 20:11:39 -0400

Ben,

  inline:

> To: Francois Le Faucheur
> Cc: Kevin J Ma; [email-masked]
> Subject: Re: [CDNi] Delegation white/blacklisting Re: incorporating a few
> requirements from cdni-publisher-use-cases into cdni-requirements
> 
> Kevin, Francois,
> 
> > And in any case, the bullets are described as examples, so we'll add
> this bullet in the next rev, unless someone else objects/
> 
> I don't want to actually object but I would urge some caution as
> fulfilling this sort of requirement starts to stray into the problem of
> how to uniquely name different CDNs and that's a whole new potential can
> of worms that I'd prefer we avoid but not introducing a requirement for it
> at the protocol level.

Doesn't the upstream CDN need a way to identify the downstream CDN anyway,
whether by name or by some other means, for delegation?

> I'm certainly aware of contractual obligations that restrict where a CDN
> may store content, where it may deliver content from and who it may
> deliver content to but I haven't (yet) come across a requirement from
> Content Providers to be prescriptive on which CDNs are allowed to be used
> (versus the minimum delivery protection/capabilities the CDN must
> support/use).
> 
> Maybe describing a use case of why such a restriction may be requested
> would help make the need for the requirement clearer?

I was primarily thinking about billing use cases, though was attempting
to be sufficiently vague as to not have to open a separate can of worms
relating to how CDNs negotiate fees with peers and how content providers
may negotiate reduced fees with those same peers, or how the cost of
delegation is aggregated, etc.

Another use case may be trust related.  Perhaps a given downstream CDN
has had known security or performance issues in the past, which the 
content provider would like to just avoid.

It kind of goes back to a previous discussions about federated trust and
SLA negotiation, which I think we agree we dont want to discuss here, but
having whitelisting/blacklisting provides the ability to customize the
request routing, in a generic way, should a content provider have issue
with the baseline interconnection.

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 14 Jun 2011 02:24:57 +0000

> I'll try and pull something together before Quebec, if others are interesting in contributing to that I'm happy to co-ordinate any inputs they have.

That sounds good. Just remember that the -00 draft submission deadline is July 4.

<http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF81>

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Monday, June 13, 2011 6:09 PM
To: Francois Le Faucheur
Cc: [email-masked]
Subject: Re: [CDNi] cdni status

Francois,

Ben

---

From: Bruce Davie <[email-masked]>
Date: Tue, 14 Jun 2011 08:45:56 -0400

> I see you have put a yet to be written Framework draft on the proposed agenda. I've been intending to produce such a framework draft for a few weeks but haven't quite had the cycles to put pen to p…

Ben,
 I've started work on a Framework with Francois and Larry Peterson, will definitely have something before the I-D cutoff for ietf81. If you have text you want to contribute, send it along.

Bruce

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 14 Jun 2011 16:52:53 +0100

Kevin,

Please see inline for a couple more thoughts.

> Persistent connections are not necessarily a given.  My iPhone does not use

Hmmm I didn't know that (and I'm not in a position to test my iPhone right now) but I'm almost certain the iPad does use persistent connections if it can so I would have thought the iPhone would too. Anyway that's a side-issue...

> wish to do that is affected by latency.

Sure. So where I've been trying to go with these questions is to dig a little under the surface of your original comment that "For certain types of live content (e.g., HLS) it might be advantageous to include a time-based limit." to understand what are the particular properties of HLS that makes tuning timeouts more advantageous.

As part of this discussion I'm coming to the conclusion that there probably aren't any special properties in the majority of HLS use cases. That's not to say the requirement you suggest for time-out is not valid but just that HLS doesn't drive any special consideration for it - i.e. it is probably a more generally applicable requirement than just HLS.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 14 Jun 2011 17:11:48 +0100

Kevin,

> whether by name or by some other means, for delegation?

There's a difference in scope. For an upstream CDN to identify a downstream CDN it needs to give it a "name" but that name only has local significance within the upstream CDN.

For a Content Provider to be able to express policies regarding white/black lists of downstream CDNs requires a global naming schemes for all CDNs.

HTH
Ben

---

From: "David Harrington" <[email-masked]>
Date: Thu, 16 Jun 2011 15:48:10 -0400

Hi,
 
The IESG and IAB today approved a session slot for the CDNI BOF.
This reserves a session slot for us.
 
The approved slot is 190 minutes (the request on the BOF wiki is for
120 minutes, but that's leftover from the first BOF, so I upped it
just in case.)
BOF chairs, please adjust accordingly and advise.
BOF and WG agenda scheduling will actually start within a few days, so
this should be done soon.
 
IESG approval as a WG rather than a BOF is a separate process.
That process will unfold over the next few weeks.
 
David Harrington

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Harrington
Sent: Friday, June 10, 2011 12:13 PM
To: 'Francois Le Faucheur'; [email-masked]
Subject: Re: [CDNi] cdni status

Hi,
 
FYI.

 
David Harrington

  _____  

Folks, 

Hi,

 

 

Cheers

Francois & Richard

PS: 

 
David Harrington

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 16 Jun 2011 20:11:08 -0400

Ben,

  understood.  thanx.

> Sent: Tuesday, June 14, 2011 12:12 PM
> To: Kevin J Ma
> There's a difference in scope. For an upstream CDN to identify a
> downstream CDN it needs to give it a "name" but that name only has local
> significance within the upstream CDN.
> 
> For a Content Provider to be able to express policies regarding
> white/black lists of downstream CDNs requires a global naming schemes for
> all CDNs.
> 
> HTH
> Ben
>

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 16 Jun 2011 20:12:15 -0400

Ben,

  I agree it is not specific to HLS.  thanx.

> Sent: Tuesday, June 14, 2011 11:53 AM
> To: Kevin J Ma
> >>>> negatively impact the "startup time" of the content (which would
> apply
> >> to
> Hmmm I didn't know that (and I'm not in a position to test my iPhone right
> now) but I'm almost certain the iPad does use persistent connections if it
> can so I would have thought the iPhone would too. Anyway that's a side-
> issue...
> 
> Sure. So where I've been trying to go with these questions is to dig a
> little under the surface of your original comment that "For certain types
> of live content (e.g., HLS) it might be advantageous to include a time-
> based limit." to understand what are the particular properties of HLS that
> makes tuning timeouts more advantageous.
> 
> As part of this discussion I'm coming to the conclusion that there
> probably aren't any special properties in the majority of HLS use cases.
> That's not to say the requirement you suggest for time-out is not valid
> but just that HLS doesn't drive any special consideration for it - i.e. it
> is probably a more generally applicable requirement than just HLS.
> 
> Ben

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Jun 2011 17:55:34 -0400

CDNI is approved as a WG.
Rich Woundy and Francois Le Faucheur will be WG chairs.
 
I had significant difficulty choosing among multiple volunteers.
I want to thank all the volunteers.
 
David Harrington

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 23 Jun 2011 23:27:35 +0000

Thanks Dave and congrats Rich and Francois.

On Jun 23, 2011, at 17:55, "David Harrington" <[email-masked]<mailto:[email-masked]>> wrote:

David Harrington
Director, IETF Transport Area
[email-masked]<mailto:[email-masked]> (preferred for ietf)
[email-masked]<mailto:[email-masked]>
+1 603 828 1401 (cell)

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni