Re: [CDNi] Loop detection requirement

["Woundy, Richard" <[e-mail]>]

> I also agree with Ben that the geo-location function should not be solved in CDNi.

Agreed. FYI, geo-location has been an item of interest for the ALTO WG.

<http://datatracker.ietf.org/doc/draft-penno-alto-cdn/>
<http://www.ietf.org/proceedings/79/slides/alto-10.pdf>

-- Rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lee, Yiu
Sent: Friday, March 04, 2011 10:49 AM
To: Ben Niven-Jenkins; GUILLOU, Allan
Cc: [e-mail]; [e-mail]
Subject: Re: [CDNi] Loop detection requirement

Hi Ben and Allan,

I second Ben. We have many ways to detect loops and BGP may be too heavy
for this purpose. 

I also agree with Ben that the geo-location function should not be solved
in CDNi.  

Cheers,
Yiu


On 3/3/11 12:05 PM, "Ben Niven-Jenkins" <[e-mail]> wrote:

>
>On 3 Mar 2011, at 15:58, GUILLOU, Allan wrote:
>
>> Hi Ben,
>> 
>> The point is that the geoloc functionality is really similar than an IP
>>routing protocol. It is done to see which CDN is nearest than another
>>from the IP address of the subscriber. That is why a routing protocol
>>seems to feet well with this.
>> 
>
>I agree that routing protocols can be used to provide information useful
>for geo-location. I think that issue is largely orthogonal to CDNI.
>
>> The idea is not to use bgp for request routing, but to use it or
>>something similar to create the geoloc database. In this case, the AS
>>number can be reused in the request routing to avoid resending it to a
>>cdn which has already response.
>> 
>
>This is my confusion based on you responding to an e-mail chain talking
>about detecting loops in between Request Routers by suggesting BGP as a
>solution.
>
>We need loop detection, we can work on the specific method to use after a
>WG is formed I think.
>
>Thanks
>Ben
>
>> 
>> 
>> 
>>> -----Message d'origine-----
>>> De : Ben Niven-Jenkins [mailto:[e-mail]]
>>> Envoyé : jeudi 3 mars 2011 15:57
>>> À : GUILLOU, Allan
>>> Cc : 'Lee, Yiu'; [e-mail];
>>>[e-mail];
>>> [e-mail]; [e-mail]; [e-mail]
>>> Objet : Re: [CDNi] Loop detection requirement
>>> 
>>> Hi Allan,
>>> 
>>> On 2 Mar 2011, at 10:33, GUILLOU, Allan wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Maybe using BGP to exchange the information between the different CDN
>>> could be interesting to avoid this kind of problem.
>>>> 
>>>> The idea is that all the CDN have multiple eBGP peering with its
>>>>partner
>>> and send the IP prefixs that it can stream associated with communities
>>> that tell the capabilities of its streamers (for exemple :1 for
>>>streaming
>>> over http, :2 ..).
>>>> 
>>>> On the routing request, or on the rewrite URL, each CDN can add its AS
>>> to do the same as an AS PATH on a BGP route.
>>>> 
>>>> So when you choose your "best partner" with your criteria of
>>>>proximity,
>>> capability, cost, you can check that it AS is not present on this AS
>>>PATH
>>> and do not avoid path.
>>>> 
>>> 
>>> I think we can look to how other protocols solve loop detection and
>>>reuse
>>> an appropriate method where the way BGP uses ASPATH would be an
>>>example of
>>> how another protocol solves loop detection.
>>> 
>>> However, I do not think it is appropriate for CDNI to overload BGP to
>>>do
>>> everything we need. BGP is IMO not an appropriate protocol to encoding
>>> metadata properties or for making Request Routing requests to another
>>>CDN.
>>> 
>>> 
>>> 
>>>> Cheers,
>>>> 
>>>> Allan
>>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] [mailto:[e-mail]] De la part
>>>>de
>>> Lee, Yiu
>>>> Envoyé : lundi 14 février 2011 19:59
>>>> À : [e-mail]; [e-mail];
>>> [e-mail]
>>>> Cc : [e-mail]; [e-mail]
>>>> Objet : Re: [CDNi] Loop detection requirement
>>>> 
>>>> 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, "[e-mail]"
>>>> <[e-mail]> wrote:
>>>> 
>>>>> Hi Phil,
>>>>> 
>>>>> See below
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : [e-mail] [mailto:[e-mail]]
>>>>>> Envoyé : vendredi 11 février 2011 14:59
>>>>>> À : STEPHAN Emile RD-CORE-LAN; [e-mail]
>>>>>> Cc : [e-mail]; [e-mail]; [e-mail]
>>>>>> Objet : RE: [CDNi] Loop detection requirement
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:emile.stephan@orange-
>>>>>> ftgroup.com]
>>>>>> Sent: 07 February 2011 08:29
>>>>>> To: [e-mail]; Eardley,PL,Philip,DES8 R
>>>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>>>> Subject: RE: [CDNi] Loop detection requirement
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> [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/
>>>>>> 
>>>>>> 
>>>>>> I suggest inserting this req directly in the header of the section 3
>>> of
>>>>>> the req draft.
>>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> Emile
>>>>>> 
>>>>>> 
>>>>>>> -----Message d'origine-----
>>>>>>> De : [e-mail] [mailto:[e-mail]] De la
>>>>>>>part
>>>>>> de
>>>>>>> Francois Le Faucheur
>>>>>>> Envoyé : jeudi 3 février 2011 11:29
>>>>>>> À : [e-mail]
>>>>>>> Cc : [e-mail]; [e-mail]; [e-mail]
>>>>>>> Objet : Re: [CDNi] Limit nb of redirects & loop sRe: CDNI
>>> Requirements
>>>>>> I-D
>>>>>>> 
>>>>>>> Hi Phil,
>>>>>>> 
>>>>>>> On 3 Feb 2011, at 11:18, <[e-mail]> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>   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.
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I take this as a "B" Vote.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> Francois
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   -----Original Message-----
>>>>>>>   From: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf
>>>>>>> Of Francois Le Faucheur
>>>>>>>   Sent: 02 February 2011 10:45
>>>>>>>   To: David R Oran
>>>>>>>   Cc: [e-mail]; Viveganandhan Mahesh; Yiu Lee
>>>>>>>   Subject: Re: [CDNi] Limit nb of redirects & loop sRe: CDNI
>>>>>>> Requirements I-D
>>>>>>> 
>>>>>>>   Dave and all,
>>>>>>> 
>>>>>>>   On 2 Feb 2011, at 01:53, David R Oran wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>       On Feb 1, 2011, at 2:25 PM, Ben Niven-Jenkins wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>           Francois,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>           On 1 Feb 2011, at 19:00, Francois Le Faucheur wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>               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:
>>>>>>> 
>>>>>>> 
>>>>>>>               "
>>>>>>> 
>>>>>>> 
>>>>>>>               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?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>           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.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>       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.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>       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
>>>>>>> 
>>>>>>> 
>>>>>>>           [e-mail]
>>>>>>> 
>>>>>>> 
>>>>>>>           https://www.ietf.org/mailman/listinfo/cdni
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   _______________________________________________
>>>>>>>   CDNi mailing list
>>>>>>>   [e-mail]
>>>>>>>   https://www.ietf.org/mailman/listinfo/cdni
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Francois Le Faucheur
>>>>>>> Distinguished Engineer
>>>>>>> Corporate Development
>>>>>>> [e-mail]
>>>>>>> Phone: [phone]
>>>>>>> Mobile: [phone]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   Cisco Systems France
>>>>>>> Greenside
>>>>>>> 400 Ave de Roumanille
>>>>>>> 06410 Sophia Antipolis
>>>>>>> France
>>>>>>> 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.
>>>>>>> 
>>>>>>> For corporate legal information go to:
>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>

_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni