Subject: [CDNi] Fwd: Re: [cdni-footprint] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call"

From: Enrico Marocco <[email-masked]>
Date: Thu, 8 Nov 2012 14:47:34 -0500

Hi all,

as the chairs suggested, here's an email sent some time ago on the
footprint design team list a while ago. It has both a proposal for a
solution to the issue just discussed in the room, and a description of
the issue itself -- in the wrong order they should appear, I agree.

Enrico

-------- Original Message --------
Subject: Re: [cdni-footprint] [CDNi] Rough Agenda for today's "CDNI
Footprint/Capabilties Design Team Call"
Date: Wed, 10 Oct 2012 15:27:59 +0200
From: Enrico Marocco <[email-masked]>
To: Scott Wainner <[email-masked]>
CC: Jan Seedorf <[email-masked]>, "[email-masked]"
<[email-masked]>

At the risk of biting off more than we can chew... after giving some
thought at the use cases, here's how the footprint information may look
like (JSON-encoded with <or>, <xor> and <and> operators in brackets, to
show possible alternatives):

"footprint" : [
	{
		"zone" : {
			"from" : {
				"as" : "123" ,
				<xor> "ipv4" : "1.2.3.0/24" ,
				<xor> "geo" : "France" ,
			} ,
			<or> "include" : {
				"as" : [ "123" , "456" ] ,
				<or> "ipv4" : [ "1.2.3.0/24" ] ,
				<or> "geo" : "France"
			} ,
			<or> "exclude" : {
				"as" : [ "789" ] ,
				<or> "ipv4" : [ "1.2.3.128/25" ] ,
				<or> "geo" : "Provence"
			} ,
		} ,
		<and> "capabilities" : {
			...
		}
	} ,
	...
]

The "capabilities" are the topic of the next call, but I guess they will
include properties such as RTT, RTSP/HLS support, etc, possibly bound to
the business contract.

In "include" goes what we have so far called the "willing to serve"
area. Little doubt that for many people that's essential.

Despite being optional, the "from" attribute is necessary in at least
two cases:
  1. as additional information for the uCDN to make a decision (e.g.
     when the contractual agreement does not constitute a solid basis
     for using the advertized "capabilities" alone);
  2. when the dCDN cannot specify an explicit coverage area.

An example of point 2 is when the traffic generated by a dCDN may have
an impact on the peering (or possibly transit) agreements between the
dCDN itself (or the transit provider associated with it) and the
networks advertized in its "willing to serve" list. The fact that such
agreements are quite often resolved in court constitutes a strong
disincentive for the dCDN -- that may in fact be very willing to serve
-- to advertize that explicitly.

Finally the "exclude" attribute is the complementary of "include", for
completeness and for cases when defining what's out is easier than
defining what's in.

Forget the encoding if you don't like it, if people agree something
along this line could be used as a starting point -- and if people
actually started pointing out what they believe is missing and what's to
remove -- that I guess would be good progress.

Enrico

On 10/10/12 5:41 AM, Scott Wainner wrote:
> 
> Jan,
> 
>      I propose two use cases that may be foundational building blocks 
> for more sophisticated use cases:
> 
> Definition:
> regional coverage: The CDN has cache nodes that service a well-defined 
> geographic or topologically bounded network
> global coverage: The CDN has cache nodes that service any geographic 
> region and is topologically unbounded
> 
> 1) uCDN with regional coverage delegates to one or more dCDN for global 
> coverage
> 
> Motivations for uCDN to delegate to dCDN might include the following:
>      - DECISION:    uCDN client is outside the region
>        IMPACT:      uCDN client is better served by global dCDN
>        CRITERIA:    uCDN ascertains if the client is outside a 
> well-defined region or IP topology
>        CRITERIA:    uCDN ascertains if the requested content can be 
> delivered by dCDN(s) (short list created)
>        CRITERIA:    uCDN determines which dCDN is appropriate (chosen by 
> priority)
> In this use case, I think its quite simple for the uCDN to know the BGP 
> AS or geography covered because the uCDN is under the same 
> administrative authority as the IP network to which it is attached.  The 
> well-defined region is much more easily bounded. The global dCDN becomes 
> a CDN of last-resort.
> 
> 2) uCDN with global coverage delegates to one or more dCDN for regional 
> coverage
> 
> Motivations for uCDN to delegate to dCDN might include the following:
>      - DECISION:    uCDN client is inside a dCDN's well-defined region 
> or IP topology
>        IMPACT:      uCDN client is better served by regional dCDN
>        CRITERIA:    uCDN ascertains if the client is inside a 
> well-defined region or IP topology
>        CRITERIA:    uCDN ascertains which dCDN's associated with the 
> region can deliver the requested content (short list)
>        CRITERIA:    uCDN determines which dCDN is appropriate (chosen by 
> priority)
> In this case, the uCDN needs to know the candidate regions and have the 
> ability to associate a client to the candidate region. That means each 
> dCDN needs to advertise its candidate region to the global uCDN.  The 
> regional dCDN become CDN of preference provided the dCDN is available 
> and capable of delivering the content.
> 
> I see three fundamental requirements:
> 
> region of coverage: either AS or geography or both
> capability of delivery: services the content delivery method
> availability: active and operational for servicing delivery requests
> 
> On 10/9/12 9:48 AM, Jan Seedorf wrote:
>> Hi all,
>>
>> As rough thread for today's call, I suggest the following:
>> -- short recap of the Vancouver discussions (Jan)
>> -- continue discussions on capabilities
>> -- discuss suggestion from Francois on focusing on some key use cases
>>
>>   - Jan
>>
>>
>>> -----Original Message-----
>>> From: Jan Seedorf
>>> Sent: Tuesday, October 02, 2012 10:49 AM
>>> To: Jan Seedorf; [email-masked]
>>> Cc: [email-masked]
>>> Subject: RE: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design
>>> Team Call"
>>>
>>> Based on the doodle, I suggest having design team phone calls on the
>>> following dates (let's schedule two calls for now and then see where to go
>>> from there...):
>>>
>>> ** Tuesday, Oct. 9th, 16:00-18:00 CET **
>>> ** Tuesday, Oct. 16th, 16:00-18:00 CET **
>>>
>>> On these dates most people seem to be able to join. Can someone please
>>> set up a WebEx meeting for those dates and times?
>>>
>>>   - Jan
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:cdni-footprint-
>>>> [email-masked]] On Behalf Of Jan Seedorf
>>>> Sent: Friday, September 28, 2012 2:42 PM
>>>> To: [email-masked]
>>>> Cc: [email-masked]
>>>> Subject: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design
>>> Team
>>>> Call"
>>>>
>>>> Hi all,
>>>>
>>>> I created a doodle for a CDNI Footprint/Capabilties Design Team Call:
>>>>
>>>> http://www.doodle.com/3u7pkrfctqa6u33g
>>>>
>>>> I would be good if we could make two calls in October to make progress
>>>> before the Atlanta meeting, so please fill in the doodle if you are interested
>>>> in joining the discussion.
>>>>
>>>>   - Jan
>>>> _______________________________________________
>>>> cdni-footprint mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/cdni-footprint
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
>> .
>>
> 
> _______________________________________________
> cdni-footprint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni-footprint
>