Subject: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 1 Feb 2011 20:00:09 +0100

Ben, Yiu,

[breaking into separate topics as this is getting hard to track]:

On 1 Feb 2011, at 19:42, Ben Niven-Jenkins wrote:

> Yiu,
> 
> See inline, I've only included the relevant parts of your message and
> snipped the rest.
> 
> On 01/02/2011 18:15, "Lee, Yiu" <[email-masked]> wrote:
> 
>> Hi Ben,
>> 
>> On 2/1/11 6:11 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:
>> 
>> 
>>> I am not sure that loop prevention is required for all APIs but it is
>>> probably more generally applicable than just Request Routing, e.g. if I
>>> issue a "content deletion" request which is subsequently cascaded we
>>> probably need to ensure it doesn't loop.
>> 
>> [YL] I agree with Ben that we loop prevention should only apply on the
>> RR-API.
> 
> Either you misunderstood me or you wrote something different to what you
> meant. I think loop prevention applies to more than the request routing
> API (e.g. The Control API or whatever API triggers content deletion) but
> it is probably not required on all APIs (e.g. Metadata API).
> 
> Looping requests on the request routing and control APIs are "dangerous".
> Looping data on the Metadata and Logging interfaces is probably not
> "dangerous" but we may still want to have loop prevention as a sanity
> check (looping data is probably a good indicator something more
> fundamental is broken somewhere, either in the network or in the CDN
> configuration).

This discussion drifted from (i) the ability to limit the number of CDN redirections (for the sake of avoiding degradation of user experience) into a discussion on (ii) preventing loops in request touting and other information exchange.

(i) is addressed in:
"
   R34  The CDNI Request-Routing API SHOULD support optional enforcement
        of a limit on the number of successive CDN redirections for a
        given request.
"

(ii) is currently addressed in :

   R32  The CDNI Request-Routing API SHOULD support request loop
        detection and prevention (e.g.  Prevent request looping in a
        situation where CDN1 redirects to CDN2 that redirects to CDN3
        that would redirect to CDN1).

   R33  The CDNI Request-Routing loop prevention mechanism SHOULD allow
        routing of the request (as opposed to the request loop being
        simply interrupted without routing the request).

(as well as R39 and R40 for longer term)

   R55  If cascaded CDNs are supported by the CDNI solution, the CDNI
        Metadata API MUST prevent looping of CDNI Metadata distribution
        across CDNs.

Do you guys still think something is missing?
Can you suggest something to cover missing bits?

Thanks

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 19:25:43 +0000

Francois,

> This discussion drifted from (i) the ability to limit the number of CDN redirections (for the sake of avoiding degradation of user experience) into a discussion on (ii) preventing loops in request…

That's my fault because I wasn't distinguishing between loop detection of CDN redirections and other types of loop detection.

> Can you suggest something to cover missing bits?

For CDNI Request Routing the above is fine. What I'm saying is I think loop detection also applies to the control API and may be useful in the other APIs.

I'd therefore suggest making loop detection a general requirement (SHOULD) and any more specific requirements (e.g. R33) under the specific API they apply to.

Thanks
Ben

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 20:22:31 +0000

Hi Ben,

>it is probably not required on all APIs (e.g. Metadata API).

[YL] Yes, I mis-read you, my bad.

>fundamental is broken somewhere, either in the network or in the CDN

[YL] It is interesting to solve the Control-API looping problem. Actually
this makes me think about the recursive nature of the control API (eg.
Delete). So we are saying even a downstream CDN peer doesn't have that
piece of content, the upstream CDN will send the Delete to it regardless.
This seems like a broadcast storm to me.

Thoughts?

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 20:24:26 +0000

Hi Francois,

>
>This discussion drifted from (i) the ability to limit the number of CDN
>redirections (for the sake of avoiding degradation of user experience)
>into a discussion on (ii) preventing loops in request touting and other
>information exchange.
>
>(i) is addressed in:
>"

[YL] From the requirement level, I am happy with them. What I discussed in
the previous email was more on the design level, not so much on the
requirement level.

Thanks,
Yiu

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 22:46:53 +0000

Yiu,

> This seems like a broadcast storm to me.

In the worst case scenario you could end up with a broadcast storm but I think we can engineer a solution that avoids that.

Firstly not all control API transactions would need to be cascaded - I haven't done an analysis (we haven't written down a complete view of what should be in the control API Vs other APIs yet) but I suspect content deletion may be an exceptional case.

Even in the case of content deletion I think a broadcast storm could be avoided. I'd expect CDNs to have to track who they received delegated requests from and who they delegated requests to so they can send logs, produce bills and troubleshoot accordingly. Therefore CDNs should only cascade deletion requests to CDNs who they think they delegated delivery to. If a CDN misbehaves and broadcasts the deletion request, downstream CDNs should be able to determine whether it's relevant to them and not cascade it if it isn't relevant thus limiting the effect caused by a misbehaving upstream CDN.

Ben

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Feb 2011 22:59:25 +0000

Hi Ben,

I agree with your analysis but what I think is will the TTL is enough
rather than proposing a Delete operation altogether. I know it is too
early to go to the solution space, but I still want to share my thoughts
to you guys.

Cheers,
Yiu

On 2/1/11 5:46 PM, "Benjamin Niven-Jenkins" <[email-masked]>
wrote:

>In the worst case scenario you could end up with a broadcast storm but I
>think we can engineer a solution that avoids that.
>
>Firstly not all control API transactions would need to be cascaded - I
>haven't done an analysis (we haven't written down a complete view of what
>should be in the control API Vs other APIs yet) but I suspect content
>deletion may be an exceptional case.
>
>Even in the case of content deletion I think a broadcast storm could be
>avoided. I'd expect CDNs to have to track who they received delegated
>requests from and who they delegated requests to so they can send logs,
>produce bills and troubleshoot accordingly. Therefore CDNs should only
>cascade deletion requests to CDNs who they think they delegated delivery
>to. If a CDN misbehaves and broadcasts the deletion request, downstream
>CDNs should be able to determine whether it's relevant to them and not
>cascade it if it isn't relevant thus limiting the effect caused by a
>misbehaving upstream CDN.
>
>Ben
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 23:32:08 +0000

> early to go to the solution space, but I still want to share my thoughts

IME the majority of the time TTL is sufficient but delete is a mandatory
requirement for certain CSPs and without it they'll take their business
elsewhere. Otherwise what happens when some CSP accidentally screws up
their Cache-Control headers and sets an expiry that is too far in the
future, or some disgruntled employee puts a virus infected file on their
origin server and the CDN caches it, or they accidentally swap out a
childrens TV programme for pornography, etc.

Those cases have been seen in the wild (OK, in the case of accidentally
serving up porn, the incident I saw in a previous life wasn't CDN related
it was an accidental splicing of an adult TV channel into a childrens TV
channel)

Ben

---

From: David R Oran <[email-masked]>
Date: Tue, 1 Feb 2011 19:53:55 -0500

> I'd therefore suggest making loop detection a general requirement (SHOULD) and any more specific requirements (e.g. R33) under the specific API they apply to.
I think the requirement is stronger: CDNs need to agree on a common mechanism for loop detection; otherwise you can get multiplicative loop diameters and effectively not have useful loop detection when the non-looping paths are long. This is routing; we know what happens when you do loop detect with thing like count-to-infinity.

Incidently, my favorite loop detection scheme was invented by Knuth all the way back in volume 2. It has the nice property of detecting loops in constant memory and with an upper bound of traversing the loop 2 times, for all loop diameters. Look it up - it's called the "even-odd iteration counting".

DaveO.

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 2 Feb 2011 11:44:37 +0100

Dave and all,

On 2 Feb 2011, at 01:53, David R Oran wrote:

> I think the requirement is stronger: CDNs need to agree on a common mechanism for loop detection;

I agree it is a MUST (as along as "cascaded CDNs" are supported).
In the Requirements I-D it was presented:
	* as a "MUST" for longer term
	* as a "SHOULD" for shorter term, because support of cascaded CDNs itself is only listed as a SHOULD for the shorter term (on the grounds that not supporting it may potentially allow definition of a simpler solution faster)

I think we could either:

*A*:
	* agree right now that the shorter term solution (ie within initial charter scope) MUST support cascaded CDNs
	* include a MUST requirement for loop prevention in the Generic Reqts section and possibly in each API specific section (Control, Request-Routing, Metadata) 

*B:
	* defer the decision about support of cascaded CDNs in shorter term (ie within initial charter scope) to further discussions
	* include a "conditional" MUST (ie "if cascaded CDNs are supported,...") in the Generic Reqts section and possibly in each API specific section (Control, Request-Routing, Metadata) 

I would vote for *A* because:
	* we wouldn't want to go for a shorter term solution that cannot be easily extended to support cascaded CDNs
	* there are short term use cases for cascaded CDNs.

other voters?

Thanks

Francois

> otherwise you can get multiplicative loop diameters and effectively not have useful loop detection when the non-looping paths are long. This is routing; we know what happens when you do loop detect with thing like count-to-infinity.
>

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Feb 2011 07:01:14 -0500

> childrens TV programme for pornography, etc.
Of course, a screwup in TTL is likely, while a malfunctioning or incorrectly applied DELETE is not :-)

I agree that there's a requirement for rapidly making an asset unavailable in the downstream CDN(s). I'm not sure I would phrase the requirement as being for a delete operation, however. Delete has arguably clean semantics, but various interesting failure modes and difficulty in protocol design for distributed operation. I hark back to my days dealing with the tricky problem of route removal in BGP.

Some thoughts on the general removal problem:

- Is there a requirement to specify what happens to sessions in progress with users? Does one CDN get to tell another CDN that they must instantly abort streaming/download to active users?
- Is there a stronger security requirement because now we have a trivial DoS vector in the protocol?
- Is there a need to distinguish between "make this assert unavailable" and "remove the bits"? For example, there may be a useful feature of temporarily "disabling" an asset without removing it so that it can be reinstated without copying the bits all over again?
- Can't the whole problem be addressed with less overhead by separating the content bits from the encryption keys such that there are separate operations on each? Then revocation of an asset can be done by invalidating keys without touching the content bits.
- From a mechanism standpoint, is there a semantic difference between "delete" and "update with zero TTL"? We likely need update anyway for pseudo-live content so conservation of mechanism argues for avoiding a separate delete operation if it doesn't have usefully different semantics.

> it was an accidental splicing of an adult TV channel into a childrens TV
Yup, but in at least one case I know of delete would not have helped as the upstream communication was malfunctioning due to the same root cause.

Cheers, DaveO.

---

From: <[email-masked]>
Date: Thu, 3 Feb 2011 10:18:03 +0000

Cascaded CDNs would be nice. 

Cascading is missing from the logging section - where it seems hard. the logging record needs to include (aggregated) info where content has been delivered to a UA by a CDN further down a cascade of CDNs. This is quite challenging, especially if one allows any flexibility over what is reported, format of reports, security methods, real-time reports, etc. 

Agree that cascading should be mentioned as a generic requirement - and we treat it at the same requirements level for all the APIs (whether that's: MUST in initial scope, SHOULD, or beyond initial scope).

Personally think there is quite a lot "within initial scope" in the requirements draft, and cascading might be deferrable if it adds significant work to standardising the APIs - as most of the value of CDN interconnect seems to come from the "one hop" case ie:
CSP -> Upstream CDN -> Downstream CDN -> UA

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: 02 February 2011 10:45
To: David R Oran
Cc: [email-masked]; Viveganandhan Mahesh; Yiu Lee
Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D

Dave and all,

I think we could either:

*A*:

*B:

other voters?

Thanks

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Feb 2011 11:28:54 +0100

Hi Phil,

On 3 Feb 2011, at 11:18, <[email-masked]> wrote:

> Cascading is missing from the logging section - where it seems hard. the logging record needs to include (aggregated) info where content has been delivered to a UA by a CDN further down a cascade of CDNs.

There are requirements in the Security section that relate to that:

"
   R71  The CDNI solution MUST be able to ensure that for any given
        request redirected to a Downstream CDN, the chain of CDN
        Delegation (leading to that request being served by that CDN)
        can be established with non-repudiation.

   R72  The CDNI solution MUST be able to ensure that the Downstream CDN
        cannot spoof a transaction log attempting to appear as if it
        corresponds to a request redirected by a given Upstream CDN when
        that request has not been redirected by this Upstream CDN.
"

This is meant to apply also to the Logging API.
Is that sufficient to capture the topic or do you want to see a specific requirement under the "Logging API" section?

> This is quite challenging, especially if one allows any flexibility over what is reported, format of reports, security methods, real-time reports, etc. 
> 

I take this as a "B" Vote.

Thanks

Francois

>> Incidently, my favorite loop detection scheme was invented by Knuth all the way back in volume 2. It has the nice property of detecting loops in constant memory and with an upper bound of traversi…

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 3 Feb 2011 20:51:13 +0000

Dave,

> I think the requirement is stronger: CDNs need to agree on a common mechanism for loop detection; otherwise you can get multiplicative loop diameters and effectively not have useful loop detection…

Agreed. Requiring a common mechanism is what I had in mind but I obviously didn't express it as clearly as you have.

Thanks.
Ben

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 3 Feb 2011 21:21:26 +0000

Dave,

> Of course, a screwup in TTL is likely, while a malfunctioning or incorrectly applied DELETE is not :-)

:-) The key of course is to provide the tools to let folks recover from their screw ups. We need to balance the ability to do so in an "automated" fashion against the engineering cost of building the additional complexity into the solution and the likely frequency of such screw ups and the expectations of CSPs.

> I agree that there's a requirement for rapidly making an asset unavailable in the downstream CDN(s). I'm not sure I would phrase the requirement as being for a delete operation, however. Delete has…

In a previous life when I was building a CDN the feedback directly from some CSPs was that delete was a requirement. TBH at the time I didn't pushback on whether an "invalidate" function would be sufficient because the vendor we were using supported delete but didn't support invalidate.

I wasn't involved at the time but I was told today that originally Velocix (my current employer) only supported invalidate but implemented delete based on direct feedback from CSPs that invalidate was useful but not sufficient.

> - Is there a requirement to specify what happens to sessions in progress with users? Does one CDN get to tell another CDN that they must instantly abort streaming/download to active users?

I think we would need to define what the semantics of delete/invalidate/whatever are including any expected impact to "in flight" sessions. I can't answer your second question right now as I need to check what the expectation from CSPs is today.

> - Is there a stronger security requirement because now we have a trivial DoS vector in the protocol?

Possibly.

> - Is there a need to distinguish between "make this assert unavailable" and "remove the bits"? For example, there may be a useful feature of temporarily "disabling" an asset without removing it so…

If we have delete then we can meet the CSPs' requirements as I understand but delete is an expensive operation and so I think there is value is also having a cheaper function (maybe "invalidate", maybe "make unavailable") that doesn't remove the bits but also would only address a subset of the CSPs' requirements. Whether we do one or both and whether we do one first and the other later is obviously something for the group as a whole to decide. 

The other thing is that this thread started from a discussion about whether control API requests need to be cascaded or not. Regardless of whether the control API ends up with functions to "delete" or "invalidate" or "make unavailable" or whatever I think it's clear that at least some control API requests do need to be cascaded.

> - Can't the whole problem be addressed with less overhead by separating the content bits from the encryption keys such that there are separate operations on each? Then revocation of an asset can be…

Two things: not all content is encrypted and not all CDN filing systems are encrypted. There are many CDN use cases where encryption is an unnecessary expense.

I believe that even for encrypted content some CSPs still have a requirement to remove the bits.

> - From a mechanism standpoint, is there a semantic difference between "delete" and "update with zero TTL"? We likely need update anyway for pseudo-live content so conservation of mechanism argues f…

With "update with zero TTL" you are not forced to remove the bits and are free to include an If-Modified-Since header field in the request to the Origin and if the Origin responds with a 304 then you're free to use the bits you already have without re-acquiring anything. With delete you are forced to remove the bits and any subsequent requests generate a fresh "vanilla" GET to the Origin. 

Ben

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 09:28:47 +0100

Hi Francois,

CDNI interfaces must support loop detection even when there is only 2 CDNs interconnected. Hence this req is tied nor to the number of CDNs of the CDNi chain nor to its nature.

So imo support for loop detection is a generic MUST that applies to each CDNi APIs. 

I suggest inserting this req directly in the header of the section 3 of the req draft. 

Regards
Emile

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Francois Le Faucheur
> Envoyé : jeudi 3 février 2011 11:29
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [CDNi] Limit nb of redirects & loop sRe: CDNI Requirements I-D
> 
> Hi Phil,
> 
> 	Cascading is missing from the logging section - where it seems hard.
> the logging record needs to include (aggregated) info where content has
> been delivered to a UA by a CDN further down a cascade of CDNs.
> 
> 
> Is that sufficient to capture the topic or do you want to see a specific
> requirement under the "Logging API" section?
> 
> 
> 
> 	This is quite challenging, especially if one allows any flexibility
> over what is reported, format of reports, security methods, real-time
> reports, etc.
> 
> 
> 
> 	Agree that cascading should be mentioned as a generic requirement -
> and we treat it at the same requirements level for all the APIs (whether
> that's: MUST in initial scope, SHOULD, or beyond initial scope).
> 
> 	Personally think there is quite a lot "within initial scope" in the
> requirements draft, and cascading might be deferrable if it adds
> significant work to standardising the APIs - as most of the value of CDN
> interconnect seems to come from the "one hop" case ie:
> 				This discussion drifted from (i) the ability to
> limit the number of CDN redirections (for the sake of avoiding degradation
> of user experience) into a discussion on (ii) preventing loops in request
> touting and other information exchange.
> 
> 
> 
> 
> 			That's my fault because I wasn't distinguishing between
> loop detection of CDN redirections and other types of loop detection.
> 
> 
> 
> 				(i) is addressed in:
> 
> 
> 				"
> 
> 
> 			For CDNI Request Routing the above is fine. What I'm
> saying is I think loop detection also applies to the control API and may
> be useful in the other APIs.
> 
> 
> 
> 			I'd therefore suggest making loop detection a general
> requirement (SHOULD) and any more specific requirements (e.g. R33) under
> the specific API they apply to.
> 
> 
> 
> 	* as a "SHOULD" for shorter term, because support of cascaded CDNs
> itself is only listed as a SHOULD for the shorter term (on the grounds
> that not supporting it may potentially allow definition of a simpler
> solution faster)
> 
> 	I think we could either:
> 
> 	*A*:
> 	* agree right now that the shorter term solution (ie within initial
> charter scope) MUST support cascaded CDNs
> 	* include a MUST requirement for loop prevention in the Generic
> Reqts section and possibly in each API specific section (Control, Request-
> Routing, Metadata)
> 
> 	*B:
> 	* defer the decision about support of cascaded CDNs in shorter term
> (ie within initial charter scope) to further discussions
> 	* include a "conditional" MUST (ie "if cascaded CDNs are
> supported,...") in the Generic Reqts section and possibly in each API
> specific section (Control, Request-Routing, Metadata)
> 
> 		otherwise you can get multiplicative loop diameters and
> effectively not have useful loop detection when the non-looping paths are
> long. This is routing; we know what happens when you do loop detect with
> thing like count-to-infinity.
> 
> 
> 
> 		Incidently, my favorite loop detection scheme was invented by
> Knuth all the way back in volume 2. It has the nice property of detecting
> loops in constant memory and with an upper bound of traversing the loop 2
> times, for all loop diameters. Look it up - it's called the "even-odd
> iteration counting".
> 
> 
> 
> 		DaveO.
> 
> 
> 
> 
> 			Thanks
> 
> 
> 			Ben
> 
> 
> 
> 
> Cisco.com <http://www.cisco.com>
> 
> 
> 
> 
> 
> 
> 
>  Think before you print.
> 
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient
> (or authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille
> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la
> publication: Jean-Luc Michel Givone.
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 7 Feb 2011 09:59:58 +0100

Hi Emile,

On 7 Feb 2011, at 09:28, <[email-masked]> <[email-masked]> wrote:

> Hi Francois,
> 
> CDNI interfaces must support loop detection even when there is only 2 CDNs interconnected.

It is true that the CDNI solution needs to support loop prevention even when there is only 2 CDNs.
The solution (and thus what is supported by CDNI APIs) could potentially be simpler with only 2 CDNs, but the requirement holds in any case.

> Hence this req is tied nor to the number of CDNs of the CDNi chain nor to its nature.
> 

That makes sense (as a requirement on the "CDNI Solution", which may be later translated into possibly more specific requirements on individual APIs).

Thanks

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 13:59:14 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 07 February 2011 08:29
To: [email-masked]; Eardley,PL,Philip,DES8 R
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CDNi] Loop detection requirement

Hi Francois,

[phil] well, in the case with only 2 CDNs interconnected, solving loop detection is trivial; if there is a chain then it is not clear to me that the issues are trivial. This is not just about loop detection - for instance, for the logging API, do you need a common agreement along the chain about logging format, security, what "real time" means, etc? Eg, if A & B agree one format and B & C agree a different format, then do you need to translate it?
If the "chain issues" are tricky to solve, then starting with the assumption of no chain would make the scope more manageable. Of course, if the "chain issues" are easy to solve then the scope is still manageable. 
Phil/

Regards
Emile

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 16:23:16 +0100

Hi Phil,

See below

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : vendredi 11 février 2011 14:59
> À : STEPHAN Emile RD-CORE-LAN; [email-masked]
> Objet : RE: [CDNi] Loop detection requirement
> 
> 
> 
> CDNI interfaces must support loop detection even when there is only 2 CDNs
> interconnected. Hence this req is tied nor to the number of CDNs of the
> CDNi chain nor to its nature.
> 
> [phil] well, in the case with only 2 CDNs interconnected, solving loop
> detection is trivial; if there is a chain then it is not clear to me that
> the issues are trivial. 

IMO the check is identical in both cases: a CDN must check that it is not trying to provide a service that it asked for.

Do we defined 'chain' ?

Regards
emile 

This is not just about loop detection - for
> instance, for the logging API, do you need a common agreement along the
> chain about logging format, security, what "real time" means, etc? Eg, if
> A & B agree one format and B & C agree a different format, then do you
> need to translate it?
> If the "chain issues" are tricky to solve, then starting with the
> assumption of no chain would make the scope more manageable. Of course, if
> the "chain issues" are easy to solve then the scope is still manageable.
> Phil/
> 
>

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 15:49:50 +0000

..

[phil] if the chain of CDNs is:
A - B - C - D - B
Detecting the loop is not (i think) as easy as is in the case:
A - B - A

Do we defined 'chain' ?
[phil] not as far as i know - probably not the best term

---

From: Saverio Mascolo <[email-masked]>
Date: Fri, 11 Feb 2011 17:05:14 +0100

i am new here...but old with graphs...what about using digraphs?

On Fri, Feb 11, 2011 at 4:49 PM, <[email-masked]> wrote:

> IMO the check is identical in both cases: a CDN must check that it is not
> trying to provide a service that it asked for.
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked]

http://c3lab.poliba.it

=================================
 This message may contain confidential and/or legally privileged
information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.

---

From: David R Oran <[email-masked]>
Date: Sat, 12 Feb 2011 09:43:13 -0500

> IMO the check is identical in both cases: a CDN must check that it is not trying to provide a service that it asked for.
I don't think it's quite that straightforward semantically - having been through the subtleties of spirals in SIP I'm not convinced it's easy to ascertain whether you are being asked to provide a service that you have outstanding. This is especially tricky if you have a distributed implementation of hat looks like a single CDN node to the outside world. On the other hand, checking for a request loop is easier than checking for a service loop, because the latter is mechanical and does not have to "back map" to the semantic level of figuring out what the service being requested is/was.

> Detecting the loop is not (i think) as easy as is in the case:
Depends on the algorithm. For most of the algorithms using only local state (as opposed to putting state in the messages, like a hop count), the complexity of what A has to do in your second example is in fact no simpler than what B has to do in your first. For hop count algorithms, the diameter of the loop is of course irrelevant.

> [phil] not as far as i know - probably not the best term
Well, the request pattern could just as easily be a tree or some other graph, no? Is there some prohibition against forking requests, or did I miss that in the draft?

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 14 Feb 2011 10:13:19 +0100

Folks,

> Well, the request pattern could just as easily be a tree or some other graph, no? Is there some prohibition against forking requests, or did I miss that in the draft?

The I-D currently states than any topology of interconnected CDNs SHOULD be supported:
"
   R9  The CDNI solution SHOULD support an arbitrary topology of
       interconnected CDNs (i.e. the CDN topology cannot be restricted
       to a tree, a loop-free topology, etc.).
"

The I-D currently refers to "cascaded CDNs" as the scenario where a CDN to which a request is redirected, in turn will redirect the request to another CDN:
"
 R8  The CDNI solution SHOULD support cascaded CDN redirection (CDN1
       redirects to CDN2 that redirects to CDN3) to an arbitrary number
       of levels.
"

The I-D currently refers to the "chain of CDNs" in the context of a given request. ie for a given request, that request has been routed over a chain of CDNs (CDN1-->CDN2-->CDN3). Again, this is only relative to a particular request:
"

Focusing on the "Requirements I-D", I propose that, for now, we:
	* move the MUST requirement for loop prevention in the generic section
	* keep the SHOULD requirements for support of cascaded CDNs (over arbitrary interconnected CDN topologies) in the generic section

As potential solutions are discussed and better understood, the group can make a decision on whether "cascaded CDNs" are supported or not in initial scope and, given that fact how to perform loop prevention (noting Dave's point above that depending on how loop prevention is performed, its complexity  may or may not depend on support of cascaded CDNs).

Additional discussions on potential solutions are welcome, but I'd like to have a base proposal for the Requirement I-D.

Francois

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 Feb 2011 18:59:07 +0000

Hi Phil, Emile and all,

I think we all agree that there is a requirement to prevent looping. It is
as important to prevent looping at 1-level deep or multiple-level deep. We
also agree that the Routing Request API should also indicate the max level
of delegation should allow. These are all captured in the REQ-ID. If they
are not clear, we are welcome to any input to improve the REQ-ID.

Perhaps it may be too early to speak of solution, but I would love to hear
people flowing ideas in the list :-)

Cheers,
Yiu

On 2/11/11 10:23 AM, "[email-masked]"
<[email-masked]> wrote:

>> >     From: [email-masked] [mailto:[email-masked]] On
>>Behalf
>> > Of Francois Le Faucheur
>> >     * we wouldn't want to go for a shorter term solution that cannot
>>be
>> > easily extended to support cascaded CDNs
>> > loops in constant memory and with an upper bound of traversing the
>>loop
>> 2
>> > (or authorized to receive for the recipient), please contact the
>>sender
>> by

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 14 Feb 2011 19:01:02 +0000

Oops. I read Francois's reply after I had sent my reply. I agree what he
said. Sorry for flooding the reflector.

/Yiu

On 2/14/11 4:13 AM, "Francois Le Faucheur" <[email-masked]> wrote:

>>> IMO the check is identical in both cases: a CDN must check that it is
>>>not trying to provide a service that it asked for.
>>> 
>> I don't think it's quite that straightforward semantically - having
>>been through the subtleties of spirals in SIP I'm not convinced it's
>>easy to ascertain whether you are being asked to provide a service that
>>you have outstanding. This is especially tricky if you have a
>>distributed implementation of hat looks like a single CDN node to the
>>outside world. On the other hand, checking for a request loop is easier
>>than checking for a service loop, because the latter is mechanical and
>>does not have to "back map" to the semantic level of figuring out what
>>the service being requested is/was.
>> 
>> Depends on the algorithm. For most of the algorithms using only local
>>state (as opposed to putting state in the messages, like a hop count),
>>the complexity of what A has to do in your second example is in fact no
>>simpler than what B has to do in your first. For hop count algorithms,
>>the diameter of the loop is of course irrelevant.
>> 
>>> Do we defined 'chain' ?
>> Well, the request pattern could just as easily be a tree or some other
>>graph, no? Is there some prohibition against forking requests, or did I
>>miss that in the draft?
>
>The I-D currently refers to "cascaded CDNs" as the scenario where a CDN
>to which a request is redirected, in turn will redirect the request to
>another CDN:
>"
>The I-D currently refers to the "chain of CDNs" in the context of a given
>request. ie for a given request, that request has been routed over a
>chain of CDNs (CDN1-->CDN2-->CDN3). Again, this is only relative to a
>particular request:
>"
>    * keep the SHOULD requirements for support of cascaded CDNs (over
>arbitrary interconnected CDN topologies) in the generic section
>
>As potential solutions are discussed and better understood, the group can
>make a decision on whether "cascaded CDNs" are supported or not in
>initial scope and, given that fact how to perform loop prevention (noting
>Dave's point above that depending on how loop prevention is performed,
>its complexity  may or may not depend on support of cascaded CDNs).
>
>Additional discussions on potential solutions are welcome, but I'd like
>to have a base proposal for the Requirement I-D.
>
>Francois
>
>
>>