Just a discussion proposal
"AGOSTINI Pierre FTRD/DMI/CAE" <[email protected]> Thu, 11 Jul 2002 14:50:00 +0200
| Newsgroups | gmane.ietf.cdi |
|---|---|
| Message-ID | <C691E039D3895C44AB8DFD006B950FB411FF45@lanmhs50.rd.francetelecom.fr> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C228D9.77A3D2D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Hi all, >=20 Unfortunately, we will not be present next week to the IETF meeting = however we have to submit a potential subject of discussion. > I am responsible of the different works and studies on CDN in France = Telecom R&D. Since several years we are working with different = operational entities of France Telecom group on the subject.=20 > As France Telecom is a large group, it could be possible to find in = the future several entities with a CDN offer. > So we could have to implement a kind of internal peering. >=20 > Consequently, we have studied the previous drafts in this group. We = think that these drafts give good technical proposals but don't take = into account the financial, marketing and politic problems with the = content peering enough. >=20 > First point could be: why will an entity, having its own CDN, do = peering with another? Some answers are: > - to cover black zones (i.e. countries were entity's CDN have no POP) > - to significantly improve end-users QoS, knowing that this = improvement has a cost (shared revenues,...) > - to reduce costs (local bandwidth should be cheaper than = international bandwidth) > - to be able to share load if CDN becomes overloaded for some reasons >=20 > From our point of view, the "black box" concept implies some = limitations that will be hardly accepted. > As an example, nobody could accept to push its contents or redirect = the end-users towards another company's network with no other QoS = guarantee than confidence. > It is already the case between entities of a same group, so it is not = thinkable between two different companies. > In the same order of idea, an entity won't accept to do content = peering if end-user QoS improvement is about 5% with a revenue share of = 50%, or if time to last byte is improved by 50% but original time was = around milliseconds.=20 >=20 For a Telecom operator, an entity with a CDN could accept to direct a = surfer towards another CDN only if it is sure that the searched content = is available on a "good" surrogate in this second CDN and if it is sure = that the surfer will be satisfied with a best QoS than using its own = CDN. > Moreover, it will accept to pay this service only if it has a way to = verify that the surfer has been best satisfied than with its own CDN, or = on some cases if it has the whole control of the content routing (for = its content of course) and has decided itself on which surrogate to = redirect the surfer. This can be really necessary if two peers choose a = different routing algorithm, for example one based on DNS and the other = based on HTTP.=20 >=20 > For us, the content peering system has: > - to allow each CDN owner to see all surrogates (or POPs) of another = peer: A CDN can be interested by using only a part of the surrogates of = a peer if they increase its coverage. (In a black box system, any = surrogate can serve it without real QoS improvement regarding originated = CDN). Doing this, it allows first CDN to choose routing algorithm: = delegation or not (including some financial criteria). > - to allow each CDN owner to know the surrogates and network load of = another peer: it is required to determine if it is interesting to direct = a request towards another CDN or not. By this way, each CDN peer assumes = its responsibility if it direct a request towards another peer, > - to be able to guarantee the time to push or refresh contents on each = surrogate: It implies access rights to the distribution system and a = standardization of the associated supervision, > - to upload logs of delegated requests to determine the QoS of each = CDN peer, > - ... >=20 >=20 > For that, a first step could be to standardize load measurement = methods and metrics, scalable protocol to exchange load information, = content management information and linked protocols, .... As a = consequence, it will then be possible to share CDN Pops between = different CDNs.>=20 >=20 > Consequently, peering agreement could be limited to a part of each = CDN. A CDN peer could decide to use only a subset of the surrogates of = another CDN. Then the second CDN peer has to define a "virtual CDN" or = "subCDN", which can be used by the first CDN peer. The second peer has = to provide a real-time state of the load (network and host) of this = global subCDN or of each surrogate using standard metrics. So the first = peer can use these data to compare them with its metrics and choose if = the requests have to be direct towards the second CDN. Then, a = supervision function has to allow verifying that the requests have been = satisfied with the awaited QoS. >=20 > Another way could be to build a solution presupposing that an = independent third party exists, able to supervise and manage all the CDN = peers and to give some guarantees on the QoS of each CDN. >=20 > Sorry to only send some general idea but I hope that they will imply = some reactions. >=20 > Good meeting and best regards >=20 > Pierre >=20 >=20 ------_=_NextPart_001_01C228D9.77A3D2D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.0.5770.59"> <TITLE>Just a discussion proposal</TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <BR> <UL> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Hi = all,</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Unfortunately, = w</FONT><FONT SIZE=3D2 FACE=3D"Arial">e will not be present next week to = the IETF meeting however we have to submit a potential subject of = discussion.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">I am responsible = of the different works and studies on CDN in France Telecom R&D. = Since several years we are working with different operational entities = of France Telecom group on the subject. </FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">As France Telecom = is a large group, it could be possible to find in the future several = entities with a CDN offer.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">So we could have = to implement a kind of internal peering.</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Consequently, we = have studied the previous drafts in this group. We think that these = drafts give good technical proposals but don't take into account the = financial, marketing and politic problems with the content peering = enough.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">First point could = be: why will an entity, having its own CDN, do peering with another? = Some answers are:</FONT></SPAN> <BR><SPAN LANG=3D"en-us"> = <FONT SIZE=3D2 FACE=3D"Arial">- to cover black zones (i.e. countries = were entity's CDN have no POP)</FONT></SPAN> <BR><SPAN LANG=3D"en-us"> = <FONT SIZE=3D2 FACE=3D"Arial">- to significantly improve end-users QoS, = knowing that this improvement has a cost (shared = revenues,...)</FONT></SPAN> <BR><SPAN LANG=3D"en-us"> = <FONT SIZE=3D2 FACE=3D"Arial">- to reduce costs (local bandwidth should = be cheaper than international bandwidth)</FONT></SPAN> <BR><SPAN LANG=3D"en-us"> = <FONT SIZE=3D2 FACE=3D"Arial">- to be able to share load if CDN becomes = overloaded for some reasons</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">From our point of = view, the "black box" concept implies some limitations that = will be hardly accepted.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">As an example, = nobody could accept to push its contents or redirect the end-users = towards another company's network with no other QoS guarantee than = confidence.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">It is already the = case between entities of a same group, so it is not thinkable between = two different companies.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">In the same order = of idea, an entity won't accept to do content peering if end-user QoS = improvement is about 5% with a revenue share of 50%, or if time to last = byte is improved by 50% but original time was around milliseconds. = </FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">For a Telecom = operator</FONT><FONT SIZE=3D2 FACE=3D"Arial">, an entity with a CDN = could accept to direct a surfer towards another CDN only if it is sure = that the searched content is available on a "good" surrogate = in this second CDN and if it is sure that the surfer will be satisfied = with a best QoS than using its own CDN.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Moreover, it will = accept to pay this service only if it has a way to verify that the = surfer has been best satisfied than with its own CDN, or on some cases = if it has the whole control of the content routing (for its content of = course) and has decided itself on which surrogate to redirect the = surfer. This can be really necessary if two peers choose a different = routing algorithm, for example one based on DNS and the other based on = HTTP. </FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">For us, the = content peering system has:</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- to allow each = CDN owner to see all surrogates (or POPs) of another peer: A CDN can be = interested by using only a part of the surrogates of a peer if they = increase its coverage. (In a black box system, any surrogate can serve = it without real QoS improvement regarding originated CDN). Doing this, = it allows first CDN to choose routing algorithm: del</FONT><FONT = SIZE=3D2 FACE=3D"Arial">e</FONT><FONT SIZE=3D2 FACE=3D"Arial">gation or = not</FONT><FONT SIZE=3D2 FACE=3D"Arial"> (including some financial = criteria)</FONT><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- to allow each = CDN owner to know the surrogates and network load of another peer: it is = required to determine if it is interesting to direct a request towards = another CDN or not. By this way, each CDN peer assumes its = responsibility if it direct a request towards another = peer,</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- to be able to = guarantee the time to push or refresh contents on each surrogate: It = implies access rights to the distribution system and a standardization = of the associated supervision,</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- to upload logs = of delegated requests to determine the QoS of each CDN = peer,</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- = ...</FONT></SPAN> </P> <BR> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">For that, a first = step could be to standardize load measurement methods and metrics, = scalable protocol to exchange load information, content management = information and linked protocols, .... As a consequence, it will then be = possible to share CDN Pops between different CDNs.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Consequently, = peering agreement could be limited to a part of each CDN. A CDN peer = could decide to use only a subset of the surrogates of another CDN. Then = the second CDN peer has to define a "virtual CDN" or = "subCDN", which can be used by the first CDN peer. The second = peer has to provide a real-time state of the load (network and host) of = this global subCDN or of each surrogate using standard metrics. So the = first peer can use these data to compare them with its metrics and = choose if the requests have to be direct towards the second CDN. Then, a = supervision function has to allow verifying that the requests have been = satisfied with the awaited QoS.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Another way could = be to build a solution presupposing that an independent third party = exists, able to supervise and manage all the CDN peers and to give some = guarantees on the QoS of each CDN.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Sorry to only send = some general idea but I hope that they will imply some = reactions.</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Good meeting and = best regards</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 = FACE=3D"Arial">Pierre</FONT></SPAN> </P> <BR> </UL> </BODY> </HTML> ------_=_NextPart_001_01C228D9.77A3D2D4--