Subject: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

From: <[email-masked]>
Date: Mon, 9 Jul 2012 17:00:52 +0000

Hi everyone,

We have just submitted the draft below. We are convinced that it will help the WG to progress on the CDNI routing issues. 

http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 

Any feedback is very welcome.

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 9 juillet 2012 18:55
À : [email-masked]
Objet : I-D Action: draft-lelouedec-cdni-request-routing-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : CDNI Request Routing
	Author(s)       : Yannick Le Louedec
                          Anne Marrec
                          Gilles Bertrand
                          Marcin Pilarski
	Filename        : draft-lelouedec-cdni-request-routing-00.txt
	Pages           : 30
	Date            : 2012-07-09

Abstract:
   The present document proposes to clarify the CDNI Request Routing
   interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-
   problem-statement], as well as related terminology.

   In particular the present document proposes to split the CDNI Request
   Routing interface into two separate interfaces with clearer roles,
   named respectively CDNI Routing interface and CDNI Downstream
   Resource Identifier Signaling interface (CDNI DRIS interface).

   This part of the CDN interconnection framework the IETF has been
   referring to so far with the term "CDNI Request Routing" is just
   another routing, signaling and forwarding problem in a long series of
   the telecommunication history.  For example, one can draw a direct
   analogy between the IP/MPLS-TE framework and the CDN interconnection
   framework.

   In addition, this document recommends that the specification of ALL
   CDN interconnection interfaces in the scope of the CDNI IETF WG
   relies on the equivalent concept to IP prefix for CDN
   interconnection, named 'contentRequestScope'.  This highly useful and
   powerful concept SHALL be used to simplify the specification of ALL
   CDN interconnection interfaces, as well as to ensure performance and
   scalability in CDN interconnection.

   All these proposals can be smoothly integrated in the WG drafts,
   especially [I-D.ietf-cdni-framework] and
   [I-D.ietf-cdni-requirements], as they essentially propose (useful)
   clarifications of the existing framework.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-routing

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 9 Jul 2012 19:41:05 +0100

Colleagues,

I started reading draft-lelouedec-cdni-request-routing-00 and this text caught my eye:

   Quoting [I-D.ietf-cdni-problem-statement
], "The CDNI Request Routing
   interface enables a Request Routing function in an upstream CDN to
   query a Request Routing function in a downstream CDN to determine if
   the downstream CDN is able (and willing) to accept the delegated
   content request".

   The "ability" and the "willingness" of the downstream CDN to accept
   the delegated content request match two fully different processes in
   CDN interconnection.  And the description of both these processes
   should be reviewed and clarified for the following reasons:

   o  Regarding the former process, i.e. related to the "ability"
      ("enables a Request Routing function in an upstream CDN to query a
      Request Routing function in a downstream CDN to determine if the
      downstream CDN is able (...) to accept the delegated content
      request"), a routing protocol is used to achieve such a process,
      called routing process, in many other technologies and networks
      (IP, ATM, etc.).  In all these technologies, it is the downstream
      entity that provides routing information to the upstream entity.
      The same approach should be applied to CDN interconnection.  The
      reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2,
      dCDN 3, and then it selects one of them based on their responses")
      would suffer from latency, signaling overhead and/or lack of
      reactivity to events that impact the ability of the downstream
      CDNs to accept delegated content requests.

   o  Regarding the latter process, i.e. related to the "willingness"
      ("enables a Request Routing function in an upstream CDN to query a
      Request Routing function in a downstream CDN to determine if the
      downstream CDN (...) is willing (...)to accept the delegated
      content request"), it is to be noted that the relationship between
      a uCDN and a dCDN is always in the frame of a contractual
      agreement between the administrative entity owning the uCDN,
      acting as the customer, and the administrative entity owning the
      dCDN, acting as the service provider.  Therefore, consider a case
      where

      *  the uCDN has a content request to redirect which is in full
         conformance with the terms of this contractual agreement, and

      *  the uCDN has selected this dCDN.

      As the uCDN knows, thanks to the routing information exchanged via
      the aforementioned routing process, that the dCDN is able to
      accept this content request, the uCDN MAY redirect the content
      request to the dCDN and the dCDN MUST accept the content request.
      Exchanging over the CDNI Request Routing interface information
      about the "willingness" of the dCDN to accept the content request
      is not relevant.

I think you might be over thinking what we wrote in the problem statement.

What was in the problem statement was meant to convey that an upstream CDN could make a request to a downstream CDN to say "how do I redirect this request to you" and the downstream CDN could reply with either "her is how to redirect it", or "no I can't/won't take that content delivery right now", reasons may include the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error) or the dCDN has no capacity right now etc.

Ben

On 9 Jul 2012, at 18:00, <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Mon, 9 Jul 2012 19:05:05 +0000

Hi Ben, all,

Ben, quoting you mail below, "... the downstream CDN could reply with either "here is how to redirect it"", 

=> This is the role of the CDNI DRIS interface to provide the uCDN with this information, and we target to make its specification public before Vancouver meeting so that everyone may read it before the meeting and get full knowledge of our proposal about this part of CDNI request routing.

Ben, quoting you mail below, "... or "no I can't/won't take that content delivery right now", reasons may include the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error).

=> This is the role of the CDNI logging interface to provide the uCDN with this information.

Ben, quoting you mail below, "... or "no I can't/won't take that content delivery right now", reasons may include ... the dCDN has no capacity right now etc."

=> This is the role of the CDNI routing interface to provide the uCDN with this information.

So we may conclude we are in line basically, which is a good point.
We just aimed at checking there was a common understanding on this point.

The key point for us here is that we don't want this sentence extracted from draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MUST accept the content request except when it has not the "ability" to do so."

The fact that the dCDN is temporary unable to handle content request correctly is not a valid reason for the dCDN to be discharged of its obligations to the uCDN.
The contract set between the uCDN and the dCDN remains valid anyway, and the obligations of the dCDN as well.
The dCDN must announce to the uCDN that it is temporary unable, as soon as possible, via the CDNI routing interface.
And the uCDN must take this information into account in its CDN selection process as soon as possible.
Then if the uCDN decides to continue to redirect content requests to the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content requests will be lost.
We could even imagine the situation where the uCDN continues to do it intentionally, because it has no better option and the content request will be lost anyway. For example in the case where neither the uCDN nor the other downstream CDNs of the uCDN cannot manage correctly the content request, the uCDN could do it intentionally so as to be able to clearly prove (with CDNI logging information) that it is the dCDN, not the uCDN, who is at fault.
But, of course, if there are alternative backup options, the normal reaction of the uCDN is to stop as soon as possible to redirect content requests to the dCDN when the uCDN knows that the dCDN is unable to handle them correctly.

So, to be clear, we would prefer the sentence to be understood as:
". and the dCDN MUST accept the content request. 
And if it cannot handle correctly the redirected content request it receives, the content request is lost. For example the dCDN generates a response to the content request with an error message, or no response at all. And in parallel the CDNI logging interface may be used to exchange logs corresponding to this problem. Anyway the dCDN MAY NOT redirect that content request back towards the uCDN." 

Exactly as in IP networks: IP packets are not sent back towards the origin by a downstream router under failure or congestion.

In both networks (IP and CDN), the reason is the same.
If the dCDN redirects back a content request to the uCDN, this generates a loop. 
To manage this would introduce a very high complexity.
And this would be just to try to save the content requests redirected by the uCDN to the dCDN in the timeslot between the time the dCDN gets down and the time the uCDN takes this failure into account in its CDN selection process.
It is much better to try to reduce this timeslot as much as possible, with routing optimizations (we will propose as soon as possible).
Rather than introducing additional complexities (to manage redirection to the uCDN) in the framework.

By the way, as you know, the IESG has just approved today the 'Content Distribution Network Interconnection (CDNI) Problem Statement' draft as informational RFC. This is a good point.
And, as you may see in the draft "CDNI request routing", we do not propose to modify this problem statement draft.
We want know to focus now on getting the specifications of all CDNI interfaces ready as soon as possible.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Niven-Jenkins
Envoyé : lundi 9 juillet 2012 20:41
À : BERTRAND Gilles RD-CORE
Cc : [email-masked]; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE
Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Colleagues,

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 10 Jul 2012 06:38:14 +0100

Yannick,

Please see inline.

> => This is the role of the CDNI logging interface to provide the uCDN with this information.

I agree this information should be logged but the Request Routing interface (what you call the DRIS) also needs to be able to indicate a failure.

Otherwise the uCDN will 'blindly' redirect the the dCDN and the delivery will fail leading to poor end user experience.

> => This is the role of the CDNI routing interface to provide the uCDN with this information.

It is the role of the CDN capability/routing interface to advertise broad capabilities etc not to give extremely fine grained real-time information on exactly the state of the dCDN.

Even if the capability/routing interface is real-time there are likely to still be race conditions where we need the dCDN to be about to indicate a failure to accept a redirect through the request routing/DRIS interface

> The key point for us here is that we don't want this sentence extracted from draft-ietf-cdni-problem-statement be interpreted as: ". and the dCDN MUST accept the content request except when it has…

Why not? IMO that is a valid scenario for some use cases.

> The contract set between the uCDN and the dCDN remains valid anyway, and the obligations of the dCDN as well.

Correct, but that contract may not be the same for all uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN can handle everything it is requested to handle but the contract may only be that the dCDN guarantees to handle up to a certain volume of traffic.

> Then if the uCDN decides to continue to redirect content requests to the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content requests will be lost.

What happens in the period between the dCDN being unable to handle requests and the time it takes to advertise that to the uCDN and for the uCDN to process & incorporate that new knowledge? Are requests blindly forwarded to the dCDN which is unable to handle them leading to poor user experience?

> And if it cannot handle correctly the redirected content request it receives, the content request is lost.

What about scenarios where the uCDN has a choice of dCDNs (e.g. two national-wide CDNs offering services at different costs), the uCDN may elect to query both dCDNs and decide based on their responses which one to choose. If the dCDN is unable to satisfy the request the uCDN needs to know that so that it can fallback to the (more expensive in this example) dCDN.

> For example the dCDN generates a response to the content request with an error message, or no response at all. And in parallel the CDNI logging interface may be used to exchange logs corresponding to this problem. Anyway the dCDN MAY NOT redirect that content request back towards the uCDN." 
> 

In a routed IP network, there is often a small packet loss while the network re-converges, by enabling the dCDN to refuse a redirection at CDNI Request Routing/DRIS query time we can reduce that window by giving the uCDN the option to take an alternative action (e.g. try another dCDN) while the routing/capability information re-converges.

> If the dCDN redirects back a content request to the uCDN, this generates a loop. 

Loop avoidance is a separate issue IMO to whether we should allow a dCDN to be able to communicate "I am unable/unwilling to take that content delivery at this time".

Regards
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 10 Jul 2012 07:19:42 +0000

Hi Yannick, Ben,

I tend to agree with Ben here. When reading the draft, I got the feeling that the draft seems to assume a lot about the relationship between the uCDN and dCDN. For example, I don't see why the CDNI Request Routing interface should state that a dCDN MUST deliver the content if it has indicated its ability to do so earlier in either a contractual agreement or in the capability interface. I understand that in most cases, the contractual agreement might indeed impose this behavior on the dCDN, but I don't think this type of behavior should be imposed by the protocol we're developing here. 

It was always my assumption that the Request Routing Interface would at least include the option of allowing the uCDN to query the dCDN for every content request whether the dCDN is willing to deliver that particular request. 

I will send my full review of the draft later. 

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: dinsdag 10 juli 2012 7:38
To: [email-masked]
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Yannick,

Please see inline.

Regards
Ben

> De : [email-masked] [mailto:[email-masked]] De la part 
> de Ben Niven-Jenkins Envoyé : lundi 9 juillet 2012 20:41 À : BERTRAND 
> Gilles RD-CORE Cc : [email-masked]; Pilarski Marcin - Korpo TP; MARREC 
> Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action: 
> draft-lelouedec-cdni-request-routing-00.txt
> 
> Colleagues,
> 
>   Quoting [I-D.ietf-cdni-problem-statement ], "The CDNI Request 
> Routing
>> De : [email-masked] 
>> [mailto:[email-masked]] De la part de 
>> [email-masked] Envoyé : lundi 9 juillet 2012 18:55 À : 
>> [email-masked] Objet : I-D Action: 
>> draft-lelouedec-cdni-request-routing-00.txt
>> 
>> 
>>  In particular the present document proposes to split the CDNI 
>> Request  Routing interface into two separate interfaces with clearer 
>> roles,  named respectively CDNI Routing interface and CDNI Downstream  
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>> exploites ou copies sans autorisation. Si vous avez recu ce message 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 09:15:26 +0000

Hi Ben, All,

Good. These are exactly the comments we expected to receive.
This gives us the opportunity to share additional comments, and thus to ease an efficient meeting in Vancouver.

1)	In the case where "the uCDN has requested a delivery of a protocol the dCDN does not support (possibly in error)", quoting your mail: "the Request Routing interface. also needs to be able to indicate a failure".

We do not agree with that, and this does not solve the problem you mention anyway.

First example, please consider the case where: 
*** the uCDN receives a content request from an end user agent
*** for this content request, the uCDN has requested over the CDNI request routing interface a delivery of a protocol that the dCDN does support (and that is in full conformance with the terms of the contractual agreement between the uCDN and the dCDN); let us consider this protocol is HTTP, 
*** the dCDN sends a response to the uCDN over the CDNI request routing interface that validates the CDNI request routing request.
*** the uCDN then erroneously generates a response to the content request (to redirect this content request to the dCDN) with the RTSP protocol.
   
As you can see, your proposal does not solve anyway the problem you mention. This content request will be lost.

Second example, please consider the case where: 
*** the uCDN receives a content request from an end user agent
*** for this content request the uCDN has requested over the CDNI request routing interface a delivery of a protocol that the dCDN does support (and that is in full conformance with the terms of the contractual agreement between the uCDN and the dCDN); let us consider this protocol is HTTP, 
*** the dCDN sends a response to the uCDN over the CDNI request routing interface that validates the CDNI request routing request.
*** the uCDN then generates a response to the content request (to redirect this content request to the dCDN) with the HTTP protocol.
*** a failure happens in the dCDN before the redirected content request arrives to the dCDN and this failure makes the dCDN unable to handle correctly the content request.

The content request will be lost also in this second example.

This second example is to stress out that, whatever the specifications of the CDNI interfaces, if the redirection of the content request relies on the end user (case of applicative content request redirection: HTTP redirection, RTSP redirection) or its local DNS server (case of DNS based content request redirection), the uCDN ALWAYS 'blindly' redirects the content request to the dCDN and the delivery may fail if a failure happens at the same time in the dCDN (leading indeed to poor end user experience).

This is, we would say, the so-called debate between the PUSH and PULL CDNI routing approaches:
*** The PUSH approach consists in the dCDN to take the initiative to announce to the uCDN that it is temporary unable, as soon as possible, via the CDNI routing interface.
*** The PULL approach consists in the uCDN to query its downstream CDNs (dCDN 1, dCDN 2, dCDN 3, etc.), via the CDNI request routing interface, and then to select one of them based on their responses received over the CDNI request routing interface. 

In both these approaches there is indeed ALWAYS a 'blind' window, between the time the dCDN sends its latest message over the CDNI request routing interface to the uCDN and the time the redirected content request reaches the selected dCDN, where there is anyway no guarantee the redirected content request will be correctly handled by the dCDN and no possibility to save this redirected content request if the dCDN has got down.

The PULL approach imposes the uCDN to send a request over the CDNI request routing interfaces set up with some or all of its dCDNs EVERYTIME it receives a content request he may wish to redirect towards one of these dCDNs.
This would suffer from latency, signaling overhead and/or lack of reactivity to events that impact the ability of the downstream CDNs to accept delegated content requests. Moreover these issues are exacerbated in the recursive mode in the case of cascaded CDNs topology (when each dCDN of the uCDN has its own dCDNs which have their own dCDNs.). 
And anyway this does not provide full guarantee that the content request will be correctly handled by the dCDN.

The PUSH does not provide full guarantee either (as full guarantee is anyway impossible to ensure). But it addresses much better all the scalability and performance issues faced by the PULL approach.    
As mentioned below, the objective is then to reduce as much as possible this 'blind' window.

So, to sum up, the IETF CDNI WG has the following options and it should make a choice as soon as possible.
*** Adopt the PUSH routing approach and work on routing optimization to reduce the "blind" window (as IETF did for IP routing).
*** Adopt the PULL routing approach, knowing there will be anyway a "bind" window too, and knowing the impacts in terms of scalability, latency, signaling overhead of this option.
*** or Adopt both approaches, knowing this option will be the longest to specify (while market players need standards urgently).

2)	Quoting your mail: "It is the role of the CDN capability/routing interface to advertise broad capabilities etc not to give extremely fine grained real-time information on exactly the state of the dCDN."

We do not agree.

Both cases/approaches could be possibly envisioned.
Otherwise please explain and justify what is the difference and/or limit between "broad capabilities" and "extremely fine grained real-time information".

Let us consider the situation where the dCDN is temporarily overloaded, i.e. it is temporary not able to handle requests correctly.

In this situation, one can distinguish 2 possible cases/approaches. This depends basically on whether the corresponding content delivery service has strong quality requirements or not.

*** Case 1 (typically for high quality content delivery services)
This is the case where the uCDN MUST absolutely avoid to redirect content requests, even temporary, to this dCDN that cannot manage them, even temporary. 
The uCDN MUST take this information "This dCDN is temporary unable to handle requests" into account in its CDN selection process.
This information is obtained via the CDNI routing process (CDNI routing interface).
Either the dCDN sends a routing update with this information.
Or the dCDN is so overloaded that it cannot send any message, even keepalive messages; therefore the uCDN detects it does not receive keep-alive messages anymore and thus it infers that the dCDN is unavailable.
Anyway it stops to select this dCDN for the next content request redirections.
Once the overload situation is over, the dCDN sends routing updates and/or routing keep-alive messages to inform the uCDN that it is back to a nominal situation.
The uCDN may then select it again.

*** Case 2 ("best effort" service)
This is the case where the uCDN and dCDN consider they may tolerate temporary overload situations without taking this into account in the CDN selection process, and thus in the CDNI routing process.
No CDNI routing update is exchanged on overload situation.
The content requests redirected during the overload period are lost.
Just as for the "best effort" IP transport over Internet; Basically IP routing protocols do not exchange such overload information.
Quality and overload/congestion situation are managed by over-dimensioning networks, by monitoring carefully congestion levels in networks, and by "traffic engineering" traffic (fine-tuning of BGP parameters, etc.) in case of severe congestion situations.

So both these cases/approaches could be possibly envisioned.

Then it is up to the IETF members to decide on if both these cases (or only case 2) should be captured in the specification of the CDNI routing interface.

We recommend to capture both cases. 
Otherwise, as mentioned above, please explain and justify what is the difference and/or limit between "broad capabilities" and "extremely fine grained real-time information", between an overload situation and a failure.

If both cases are captured, the question, when setting CDN interconnection in the real world, is then the compromise to set between scalability/stability in the control plane and quality of service in the transport plane.
This will be up to the players who manage the interconnected CDNs to agree on that, depending of the capability of their CDNs and the services to be supported, and to configure their interfaces adequately.

3)	Quoting your mail : "Even if the capability/routing interface is real-time there are likely to still be race conditions where we need the dCDN to be about to indicate a failure to accept a redirect through the request routing/DRIS interface"

See above, you are referring again to this 'blind' window that it is anyway impossible to delete.

4)	Quoting your mail: "Why not? IMO that is a valid scenario for some use cases."

Because, as mentioned in my previous mail, the fact that the dCDN is temporary unable to handle content request correctly is not a valid reason for the dCDN to be discharged of its obligations to the uCDN. The contract set between the uCDN and the dCDN remains valid anyway, and the obligations of the dCDN as well.

5)	Quoting your mail: "Correct, but that contract may not be the same for all uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN can handle everything it is requested to handle but the contract may only be that the dCDN guarantees to handle up to a certain volume of traffic."

We do not claim that the contracts have to be the same for all uCDNs and dCDNS.

A given contract set between a given uCDN and a given dCDN MUST indicate either some limitations (e.g. Max number of requests per second, or Max volume of delivery traffic generated inside the dCDN, etc.) or even "no limitation".
As long as the terms of this contract (these limitations or absence of limitations) are abided by the uCDN, the uCDN may redirect content requests to the dCDN.
And the dCDN must accept them. Because this is the deal!!
And in the case the dCDN cannot, for example because of overload situation (for example because the dCDN was not correctly dimensioned), we have the two possible cases described above (see item 2 above).

6)	Quoting your mail: "What happens in the period between the dCDN being unable to handle requests and the time it takes to advertise that to the uCDN and for the uCDN to process & incorporate that new knowledge? Are requests blindly forwarded to the dCDN which is unable to handle them leading to poor user experience?"

See above, you are referring again to this 'blind' window that it is anyway impossible to delete whatever the approach.

7)	Quoting your mail "What about scenarios where the uCDN has a choice of dCDNs (e.g. two national-wide CDNs offering services at different costs), the uCDN may elect to query both dCDNs and decide based on their responses which one to choose. If the dCDN is unable to satisfy the request the uCDN needs to know that so that it can fallback to the (more expensive in this example) dCDN."

See above, you are referring again to this 'blind' window that it is anyway impossible to delete.

And we would like to say "What about scenarios with recursive request routing mode where the uCDN has a choice of 4 dCDNs and each of these dCDNs has the choice of 4 dCDNs? Please provide the description of the call flows corresponding to the worst situation in this scenario, where one has to fallback to each dCDN of each dCDN, one after the other, for EVERY content request. Then add a third level in the topology and do the same description.". 

We just want to stress out the scalability and performance issues of these fallback operations.

8)	Quoting your mail "In a routed IP network, there is often a small packet loss while the network re-converges, by enabling the dCDN to refuse a redirection at CDNI Request Routing/DRIS query time we can reduce that window by giving the uCDN the option to take an alternative action (e.g. try another dCDN) while the routing/capability information re-converges."

We agree on that point: this fallback possibility could maybe help to reduce that window, but it cannot delete it anyway.

We just claim this is not worth, knowing the drawbacks of this fallback possibility.

But again, the IETF CDNI WG has the following options and it shall make a choice as soon as possible:
*** Adopt the PUSH routing approach only
*** Adopt the PULL routing approach only
*** or Adopt both approaches.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : Ben Niven-Jenkins [mailto:[email-masked]] 
Envoyé : mardi 10 juillet 2012 07:38
À : LE LOUEDEC Yannick RD-CORE
Cc : BERTRAND Gilles RD-CORE; [email-masked]; Pilarski Marcin - Korpo TP; MARREC Anne RD-CORE
Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Yannick,

Please see inline.

Regards
Ben

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 10:00:33 +0000

Hi Ray, all,

1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing interface should state that a dCDN MUST deliver the content if it has indicated its ability to do so earlier in either a contractual agreement or in the capability interface."

This is not what we have written.
Let me try to rephrase simply.

A contractual agreement is a contractual agreement. 
It put in writings the respective obligations of the uCDN and of the dCDN. 
The uCDN may redirect any content request to the dCDN as long as it is in full conformance with the terms of this contractual agreement (the type of the content request is in full conformance, the maximum number of content requests per second is respected, etc.). 
In this case the dCDN may not say "Sorry, but I decide unilaterally to refuse this content request".  
Why? Because this is the deal, a contractual agreement is a contractual agreement!
Yet the dCDN may say "I do apologize, but at this time I cannot handle correctly a certain class of content requests specified in our contractual agreement" (for example the class of the HTTP content requests with token from French end users, because of overload situation, failure, etc.)
This is the role of the CDNI routing interface to provide the uCDN with such information.

(And the dCDN may be given a penalty for example if this was agreed in the terms of the contractual agreement.)

2) Ray, Quoting your mail: "I understand that in most cases, the contractual agreement might indeed impose this behavior on the dCDN"

Please provide the description of an example where this is not the case.
Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS the case. 
And this is an important point to be able to progress in the CDNI interfaces' specification works.

If the contractual agreement does not define clearly the obligations of the uCDN, it is impossible to dimension adequately the dCDN, neither to define correctly the CDNI contractual agreements between the dCDN and the dCDNs of this dCDN.
If the contractual agreement does not define clearly the obligations of the dCDN, the dCDN may do what it wants... even to put in the trash can any content request it accepted to handle.
In both situations it is impossible to ensure any quality of experience to the end user.

3) Ray, Quoting your mail: "I don't think this type of behavior should be imposed by the protocol we're developing here."

I do not sure I understand this sentence. 
Every routing protocol has been defined (or at least configured) so far by considering the expected behavior of the interconnected elements/networks.  
But maybe I will understand if you provide an example on the point 2 above.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Envoyé : mardi 10 juillet 2012 09:20
À : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE
Cc : Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Yannick, Ben,

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: dinsdag 10 juli 2012 7:38
To: [email-masked]
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Yannick,

Please see inline.

Regards
Ben

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 10:41:38 +0000

Hi Ben, all,

This mail is just to complement item 5 in my mail below, as Ray made a very close comment in the meantime.

Ben, Quoting your mail: "Correct, but that contract may not be the same for all uCDNs & dCDNs, for example a uCDN may not have a guarantee that a dCDN can handle everything it is requested to handle but the contract may only be that the dCDN guarantees to handle up to a certain volume of traffic."

In the situation where we are up to this certain volume of traffic, this is a typical illustration of situations where the contractual agreement does not define clearly the obligations of the dCDN.
In such a situation, if nothing more is written in the contractual agreement, the dCDN may really do what it wants... even put in the trash can any redirected content request for which the dCDN sent a message over the CDNI request routing saying that it accepted to handle correctly that content request.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 10 juillet 2012 11:15
À : Ben Niven-Jenkins
Cc : Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Ben, All,

   

We do not agree.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----

Yannick,

Please see inline.

Regards
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 10 Jul 2012 13:13:28 +0000

Hi Yannick,

See comments inline.

In general: IMO the CDNI interfaces should be abstracted from any kind of contractual/business agreement that might or might not exist between a dCDN and uCDN. The current drafts seems to assume some particular type of contractual agreement between CDNs that might not always be the case.

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 10 juli 2012 12:01
To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Ray, all,

[RvB]: This is where we disagree. IMHO, the type of behavior you describe (the dCDN not living up to its obligation) should not be enforced by the CDNI Interfaces. If a dCDN does not live up to its contractual agreement, this should be something that is handled on a business level, not on a protocol level.

Why? Because this is the deal, a contractual agreement is a contractual agreement!
Yet the dCDN may say "I do apologize, but at this time I cannot handle correctly a certain class of content requests specified in our contractual agreement" (for example the class of the HTTP content requests with token from French end users, because of overload situation, failure, etc.) This is the role of the CDNI routing interface to provide the uCDN with such information.

[RvB]: I can't remember ever seeing such a discussion on the WG list. Anyway: one example of a contractual agreement between two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will deliver some content on behalf of a uCDN, but decide on a per-request basis whether it wants to do so (and is for example paid per request). In these cases, the dCDN needs to have the ability to deny delivery on a per-request basis. 

[RvB]: Exactly, this is something that needs to be discussed on a business/contractual level and not on a technical level. That is way IMHO the CDNI Interfaces should not make ANY assumptions on what was agreed on a contractual level. 

[RvB]: Every routing protocol defines the expected behavior of interconnected elements/networks on a technical level, not on a business level. Having a dCDN say  'I'm not willing to deliver this content' is perfectly fine from a technical perspective, although it could be problematic from a contractual perspective. 

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : Brandenburg, R. (Ray) van [mailto:[email-masked]]
Envoyé : mardi 10 juillet 2012 09:20
À : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Yannick, Ben,

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: dinsdag 10 juli 2012 7:38
To: [email-masked]
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Yannick,

Please see inline.

Regards
Ben

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 14:33:02 +0000

Hi Ray,

1) Ray, quoting your mail: "The current drafts seems to assume some particular type of contractual agreement between CDNs that might not always be the case."

Please quote the draft.
Please let us know exactly to which sentence(s) of the draft you are referring to.
Otherwise it is hard to discuss and comment on your email. 

2) Ray, Quoting your mail: "If a dCDN does not live up to its contractual agreement, this should be something that is handled on a business level, not on a protocol level."

Maybe there is a deep misunderstanding. 
So I will try to be clear again.
We do not propose the CDNI routing interface to be used by the dCDN to send a message saying "Sorry, but I decide unilaterally to refuse this content request". 
We do not propose the CDNI routing interface to be used to handle any aspect relating to a dCDN deciding unilaterally to stop living up to its contractual agreement.

Please let us know where you saw such an idea in this IETF draft "CDNI request routing". 

The only role of the CDNI routing interface is to be used to advertise CDNI routing information from the downstream CDN to the upstream CDN.
And this is the description given in this IETF draft.

3) Ray, quoting your mail: "one example of a contractual agreement between two CDNs is one in which the uCDN and dCDN have agreed that the dCDN will deliver some content on behalf of a uCDN, but decide on a per-request basis whether it wants to do so (and is for example paid per request). In these cases, the dCDN needs to have the ability to deny delivery on a per-request basis."

Let me try to fully understand your point:
Are you really meaning that in this case the dCDN has in reality absolutely no obligation with regards to the uCDN?
Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery?
Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery, and this even if the dCDN has the capability to deliver the content?
Are you really meaning that in this case the dCDN may possibly response negatively to all requests for content request redirection submitted by the uCDN over the CDNI request routing interface? (i.e. that possibly the uCDN will never be allowed/invited to redirect a content request to the dCDN?)

4) Ray, quoting your mail: "Every routing protocol defines the expected behavior of interconnected elements/networks on a technical level, not on a business level." 

Again, this is not what I have written, and this is not the idea we want to share.
I wrote "Every routing protocol has been defined (or at least configured) so far by considering the expected behavior of the interconnected elements/networks."  
That's all.
I can rephrase this sentence the following way: "we must know what we expect to do with a protocol to design it correctly."
And IHMO this is an evidence; I don't know any other way to proceed.

Besides, let us consider BGP (which is by the way an option proposed by some IETF members to implement this CDNI routing interface).
In IP networks, BGP configurations in IP routers are defined as per the business relationships (valley free policy, etc.).
Of course the business relationships determine the BGP configurations.
And of course BGP has been designed so as to allow to configure IP interconnections adequately depending on the corresponding Customer/provider, sibling and peering contractual agreements.
But this does not mean that BGP "defines the expected behavior of interconnected elements/networks... on a business level."
Even if we can indeed infer quite accurately the business relationships between ISP from the BGP configuration of their IP routers (see CAIDA project), but this is another story.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Envoyé : mardi 10 juillet 2012 15:13
À : LE LOUEDEC Yannick RD-CORE; Ben Niven-Jenkins
Cc : Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Objet : RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Yannick,

See comments inline.

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 10 juli 2012 12:01
To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: RE: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi Ray, all,

Best regards,

Yannick Le Louédec.

-----Message d'origine-----

Hi Yannick, Ben,

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: dinsdag 10 juli 2012 7:38
To: [email-masked]
Cc: Pilarski Marcin - Korpo TP; [email-masked]; MARREC Anne RD-CORE
Subject: Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Yannick,

Please see inline.

Regards
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 10 Jul 2012 15:39:17 +0000

Hi Yannick,

> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery?

What I mean is that I would like to have a RR Interface at least support a model where for every content request the uCDN asks the dCDN whether it wants to deliver that particular content item (I believe you call this a PULL approach). And I would like to allow the dCDN to be able to say 'No' on this request (whether it is for purposes or failure, overload, or any other reason).

> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery, and this even if the dCDN has the capab…

Yes. 

> Are you really meaning that in this case the dCDN may possibly response negatively to all requests for content request redirection submitted by the uCDN over the CDNI request routing interface? (i.…

Yes. Any  negative effect this may have on the business relationship between uCDN and dCDN should be handled on the business level.

Ray

---

From: Scott Wainner <[email-masked]>
Date: Mon, 16 Jul 2012 07:36:45 -0400

I'm inclined to interpret the "able (and willing)" in two context as well.

We have the general willingness of the dCDN to accept a certain class of 
redirects which is presumably advertised by the footprint and 
capabilities.  This information would allow the uCDN to know a prior to 
the client routing request that the dCDN is a candidate for consideration.

Given the dCDN is a candidate (along with many others), the uCDN may 
choose this particular dCDN and elect to route the request to the dCDN.  
The dCDN may be unable to fulfill this particular request for any number 
of reasons (momentary overload condition, configuration error, loss of 
connectivity).  Of course the logging interface will record this fact; 
however, the uCDN needs an immediate response in the routing request 
such that an alternate candidate can be considered.

I presume that the successful routing request of the dCDN will provide 
the appropriate information on how to redirect the client.

Scott

On 7/9/12 2:41 PM, Ben Niven-Jenkins wrote:
> .

---

From: Scott Wainner <[email-masked]>
Date: Mon, 16 Jul 2012 08:22:53 -0400

>> Are you really meaning that in this case the dCDN decides alone, in real time, and for each content request, whether it denies or accepts to ensure delivery, and this even if the dCDN has the capa…
I think we have to delineate between the iterative and recursive model.

The recursive model assumes that the client request to the uCDN will be 
recursive and the CDN-I RR interface will be used to provide an answer 
for each client request.  The choice to initiate the recursion would be 
determined by the footprint / capabilities.  The ability of the dCDN to 
execute the specific request would provide immediate feedback to the 
uCDN.  A dCDN that continues to advertise the footprint / capability, 
but frequently or continually rejects the request via CDN-I RR would be 
a poor candidate.  The opportunity now arises where the uCDN may elect 
to choose an alternate dCDN because its preferred dCDN (according to 
footprint / capabilities) is 'under-performing'.

The iterative model, the uCDN blindly redirects the client to the dCDN 
based on the footprint / capabilities.  What the dCDN does with the 
request is somewhat transparent to the uCDN.  With the exception of the 
CDN-I logging, the uCDN assumes the dCDN is properly handling the 
requests that were delegated to the dCDN.  If you are trying to 
'tighten' up the case of blind rejections, then the frequency of the 
footprint / capabilities advertisements would have to be accelerated.  
For the case where the dCDN repeatedly sees requests from the uCDN that 
the dCDN can't handle, it should retract its footprint / capabilities 
advertisement.  Failing to do so would continually black-hole routing 
requests which would be indicated in the logging information.

Either way, you need a feedback loop to avoid dumping routing requests.

With any feedback loop (recursive routing request or footprint / 
capabilities advertisement), you have to be careful about rapid 
oscillations and dampening the responses.

Scott

---

From: <[email-masked]>
Date: Mon, 16 Jul 2012 14:35:05 +0000

Dear all,

We propose to arrange a side meeting on Sunday evening during IETF #84 (i.e. on July 29th) on the CDNI request routing interface.
The objective is to clear the discussion we had these last days via the IETF CDNI mailing list, and to ease an efficient meeting on Tuesday 31.
If everybody agrees that this is a good idea, we will set up a doodle.

Best regards,

Yannick Le Louédec,
Orange OLNC.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 16 Jul 2012 14:42:59 +0000

I think that is a very good idea, and I would like to attend. 

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 16 juli 2012 16:35
To: Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked]
Cc: BERTRAND Gilles RD-CORE; STEPHAN Emile RD-CORE
Subject: IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Dear all,

Best regards,

Yannick Le Louédec,
Orange OLNC.

---

From: <[email-masked]>
Date: Fri, 20 Jul 2012 12:28:05 +0000

Dear all,

The doodle for the side meeting in Vancouver on CDNI request routing is here:  http://www.doodle.com/n552qchpurfcpckn 
Please fill it in as soon as possible if you intend to attend.

Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on Monday evening, after the welcoming session.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 16 juillet 2012 16:35
À : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked]
Objet : [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Dear all,

Best regards,

Yannick Le Louédec,
Orange OLNC.

---

From: <[email-masked]>
Date: Mon, 23 Jul 2012 07:53:22 +0000

Yannick, 

You probably mean on "Sunday" evening after the welcoming session? 

Best regards,
--
Gilles

-----Message d'origine-----
De : LE LOUEDEC Yannick RD-CORE 
Envoyé : vendredi 20 juillet 2012 14:28
À : Woundy, Richard; Francois Le Faucheur ([email-masked]); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked]
Cc : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE
Objet : RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Dear all,

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked] Envoyé : lundi 16 juillet 2012 16:35 À : Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked] Objet : [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Dear all,

Best regards,

Yannick Le Louédec,
Orange OLNC.

---

From: <[email-masked]>
Date: Mon, 23 Jul 2012 08:07:32 +0000

Dear Gilles, All,

I mean on Monday,
After the welcome session in case the representatives from the CDNIW G must attend it (Extract from Monday's agenda : "1730 - 1800 Welcome, 1. Welcome - Bernard Aboba...").
Otherwise (if the representatives must not attend this welcome session), we could even possibly arrange it at the same time if it appears that most people are available at that time.

Our initial plan was indeed to arrange it rather on Sunday, but some people will be available from Monday on only.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : BERTRAND Gilles RD-CORE 
Envoyé : lundi 23 juillet 2012 09:53
À : LE LOUEDEC Yannick RD-CORE; Woundy, Richard; Francois Le Faucheur ([email-masked]); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked]
Cc : STEPHAN Emile RD-CORE
Objet : RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Yannick, 

Best regards,
--
Gilles

-----Message d'origine-----
De : LE LOUEDEC Yannick RD-CORE
Envoyé : vendredi 20 juillet 2012 14:28
À : Woundy, Richard; Francois Le Faucheur ([email-masked]); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked] Cc : STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet : RE: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI request routing interface

Dear all,

Best regards,

Yannick Le Louédec.

-----Message d'origine-----

Dear all,

Best regards,

Yannick Le Louédec,
Orange OLNC.

---

From: Jan Seedorf <[email-masked]>
Date: Wed, 25 Jul 2012 09:05:38 +0000

Hi Yannick,

I just entered the doodle; also for me Monday evening after the technical plenary is the best time.

 - Jan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, July 23, 2012 10:08 AM
> To: BERTRAND Gilles RD-CORE; Woundy, Richard; Francois Le Faucheur
> ([email-masked]); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R.
> (Ray) van; [email-masked]
> Subject: Re: [CDNi] IETF #84 - Proposal for a side meeting on the CDNI
> request routing interface
> 
> Dear Gilles, All,
> 
> I mean on Monday,
> After the welcome session in case the representatives from the CDNIW G
> must attend it (Extract from Monday's agenda : "1730 - 1800 Welcome, 1.
> Welcome - Bernard Aboba...").
> Otherwise (if the representatives must not attend this welcome session), we
> could even possibly arrange it at the same time if it appears that most people
> are available at that time.
> 
> À : LE LOUEDEC Yannick RD-CORE; Woundy, Richard; Francois Le Faucheur
> ([email-masked]); Scott Wainner; Ben Niven-Jenkins; Brandenburg, R.
> (Ray) van; [email-masked]
> À : Woundy, Richard; Francois Le Faucheur ([email-masked]); Scott
> Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked] Cc :
> STEPHAN Emile RD-CORE; BERTRAND Gilles RD-CORE Objet : RE: [CDNi] IETF
> #84 - Proposal for a side meeting on the CDNI request routing interface
> 
> Dear all,
> 
> The doodle for the side meeting in Vancouver on CDNI request routing is
> here:  http://www.doodle.com/n552qchpurfcpckn
> Ideally we would like to arrange this meeting at Hyatt Regency Hotel, on
> Monday evening, after the welcoming session.
> 
> Best regards,
> 
> Yannick Le Louédec.
> 
> De : [email-masked] [mailto:[email-masked]] De la part de
> [email-masked] Envoyé : lundi 16 juillet 2012 16:35 À : Scott
> Wainner; Ben Niven-Jenkins; Brandenburg, R. (Ray) van; [email-masked]
> We propose to arrange a side meeting on Sunday evening during IETF #84
> (i.e. on July 29th) on the CDNI request routing interface.
> The objective is to clear the discussion we had these last days via the IETF
> CDNI mailing list, and to ease an efficient meeting on Tuesday 31.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, France Telecom -
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
> Thank you.
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
> Thank you.
>

---

From: "GUILLOU, Allan" <[email-masked]>
Date: Wed, 25 Jul 2012 10:22:38 +0000

Hi,

With a "recusive model" as you ask if I understand, you expect the dCDN to send like an "ack" for each request, and if not the uCDN will try to find the second best dCDN and do the same thing.

I think that this model may add complexity and may cause some scalability problem. You will have to implement timers between request and ack, retransmission mechanism to make sure that request has not been lost, loop free mechanism, And all this may add latency on all requests and performances problems.

In the iterative model, if the dCDN is not able to handle the request, this request will be lost. It is the same thing in IP network today we do not ask the routing protocol to change when there is saturation somewhere. It is the responsibility of each ISP to choose another route to join this destination if he want to keep a good quality of service. If a dCDN is overloaded, it will stop announcing part of its footprint or uCDN may apply some policy to force choosing another dCDN.

It is right that this second model may not in case of dCDN saturation have the best reactivity, but it is exactly the same thing on the internet today. We can imagine that a poor dCDN which have saturation will be "black listed" by all the uCDN and the regulation will be done like this.
I think recursive model will add complexity all the time for a gain witch is not in my opinion so important and that will not be seen so often.

Allan

> Scott Wainner
> Envoyé : lundi 16 juillet 2012 14:23
> À : [email-masked]
> >> Are you really meaning that in this case the dCDN has in reality
> absolutely no obligation with regards to the uCDN?
> >> Are you really meaning that in this case the dCDN decides alone, in
> real time, and for each content request, whether it denies or accepts to
> ensure delivery?
> > What I mean is that I would like to have a RR Interface at least support
> a model where for every content request the uCDN asks the dCDN whether it
> wants to deliver that particular content item (I believe you call this a
> PULL approach). And I would like to allow the dCDN to be able to say 'No'
> on this request (whether it is for purposes or failure, overload, or any
> other reason).
> >
> >> Are you really meaning that in this case the dCDN decides alone, in
> real time, and for each content request, whether it denies or accepts to
> ensure delivery, and this even if the dCDN has the capability to deliver
> the content?
> > Yes.
> >> Are you really meaning that in this case the dCDN may possibly response
> negatively to all requests for content request redirection submitted by
> the uCDN over the CDNI request routing interface? (i.e. that possibly the
> uCDN will never be allowed/invited to redirect a content request to the
> dCDN?)
> >
> > Yes. Any  negative effect this may have on the business relationship
> between uCDN and dCDN should be handled on the business level.
> >
> > Ray
> >
> >
> >> 1) Ray, quoting your mail: "The current drafts seems to assume some
> particular type of contractual agreement between CDNs that might not
> always be the case."
> >>
> >> Please quote the draft.
> >> 2) Ray, Quoting your mail: "If a dCDN does not live up to its
> contractual agreement, this should be something that is handled on a
> business level, not on a protocol level."
> >>
> >> We do not propose the CDNI routing interface to be used by the dCDN to
> send a message saying "Sorry, but I decide unilaterally to refuse this
> content request".
> >> We do not propose the CDNI routing interface to be used to handle any
> aspect relating to a dCDN deciding unilaterally to stop living up to its
> contractual agreement.
> >>
> >> The only role of the CDNI routing interface is to be used to advertise
> CDNI routing information from the downstream CDN to the upstream CDN.
> >> 3) Ray, quoting your mail: "one example of a contractual agreement
> between two CDNs is one in which the uCDN and dCDN have agreed that the
> dCDN will deliver some content on behalf of a uCDN, but decide on a per-
> request basis whether it wants to do so (and is for example paid per
> request). In these cases, the dCDN needs to have the ability to deny
> delivery on a per-request basis."
> >>
> >> Are you really meaning that in this case the dCDN has in reality
> absolutely no obligation with regards to the uCDN?
> >> Are you really meaning that in this case the dCDN decides alone, in
> real time, and for each content request, whether it denies or accepts to
> ensure delivery?
> >> Are you really meaning that in this case the dCDN decides alone, in
> real time, and for each content request, whether it denies or accepts to
> ensure delivery, and this even if the dCDN has the capability to deliver
> the content?
> >> Are you really meaning that in this case the dCDN may possibly response
> negatively to all requests for content request redirection submitted by
> the uCDN over the CDNI request routing interface? (i.e. that possibly the
> uCDN will never be allowed/invited to redirect a content request to the
> dCDN?)
> >>
> >>
> >> 4) Ray, quoting your mail: "Every routing protocol defines the expected
> behavior of interconnected elements/networks on a technical level, not on
> a business level."
> >>
> >> I wrote "Every routing protocol has been defined (or at least
> configured) so far by considering the expected behavior of the
> interconnected elements/networks."
> >> That's all.
> >> I can rephrase this sentence the following way: "we must know what we
> expect to do with a protocol to design it correctly."
> >> Besides, let us consider BGP (which is by the way an option proposed by
> some IETF members to implement this CDNI routing interface).
> >> In IP networks, BGP configurations in IP routers are defined as per the
> business relationships (valley free policy, etc.).
> >> And of course BGP has been designed so as to allow to configure IP
> interconnections adequately depending on the corresponding
> Customer/provider, sibling and peering contractual agreements.
> >> But this does not mean that BGP "defines the expected behavior of
> interconnected elements/networks... on a business level."
> >> Even if we can indeed infer quite accurately the business relationships
> between ISP from the BGP configuration of their IP routers (see CAIDA
> project), but this is another story.
> >>
> >>
> >> Best regards,
> >>
> >> Yannick Le Louédec.
> >>
> >>
> >>
> >> In general: IMO the CDNI interfaces should be abstracted from any kind
> of contractual/business agreement that might or might not exist between a
> dCDN and uCDN. The current drafts seems to assume some particular type of
> contractual agreement between CDNs that might not always be the case.
> >>
> >> Ray
> >>
> >> 1) Ray, Quoting your mail: "I don't see why the CDNI Request Routing
> interface should state that a dCDN MUST deliver the content if it has
> indicated its ability to do so earlier in either a contractual agreement
> or in the capability interface."
> >>
> >> The uCDN may redirect any content request to the dCDN as long as it is
> in full conformance with the terms of this contractual agreement (the type
> of the content request is in full conformance, the maximum number of
> content requests per second is respected, etc.).
> >> [RvB]: This is where we disagree. IMHO, the type of behavior you
> describe (the dCDN not living up to its obligation) should not be enforced
> by the CDNI Interfaces. If a dCDN does not live up to its contractual
> agreement, this should be something that is handled on a business level,
> not on a protocol level.
> >>
> >> Yet the dCDN may say "I do apologize, but at this time I cannot handle
> correctly a certain class of content requests specified in our contractual
> agreement" (for example the class of the HTTP content requests with token
> from French end users, because of overload situation, failure, etc.) This
> is the role of the CDNI routing interface to provide the uCDN with such
> information.
> >>
> >> 2) Ray, Quoting your mail: "I understand that in most cases, the
> contractual agreement might indeed impose this behavior on the dCDN"
> >>
> >> [RvB]: I can't remember ever seeing such a discussion on the WG list.
> Anyway: one example of a contractual agreement between two CDNs is one in
> which the uCDN and dCDN have agreed that the dCDN will deliver some
> content on behalf of a uCDN, but decide on a per-request basis whether it
> wants to do so (and is for example paid per request). In these cases, the
> dCDN needs to have the ability to deny delivery on a per-request basis.
> >>
> >> If the contractual agreement does not define clearly the obligations of
> the uCDN, it is impossible to dimension adequately the dCDN, neither to
> define correctly the CDNI contractual agreements between the dCDN and the
> dCDNs of this dCDN.
> >> If the contractual agreement does not define clearly the obligations of
> the dCDN, the dCDN may do what it wants... even to put in the trash can
> any content request it accepted to handle.
> >>
> >> [RvB]: Exactly, this is something that needs to be discussed on a
> business/contractual level and not on a technical level. That is way IMHO
> the CDNI Interfaces should not make ANY assumptions on what was agreed on
> a contractual level.
> >>
> >> 3) Ray, Quoting your mail: "I don't think this type of behavior should
> be imposed by the protocol we're developing here."
> >>
> >> Every routing protocol has been defined (or at least configured) so far
> by considering the expected behavior of the interconnected
> elements/networks.
> >>
> >> [RvB]: Every routing protocol defines the expected behavior of
> interconnected elements/networks on a technical level, not on a business
> level. Having a dCDN say  'I'm not willing to deliver this content' is
> perfectly fine from a technical perspective, although it could be
> problematic from a contractual perspective.
> >>
> >> À : Ben Niven-Jenkins; LE LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin
> - Korpo TP; [email-masked]; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D
> Action: draft-lelouedec-cdni-request-routing-00.txt
> >>
> >> Hi Yannick, Ben,
> >>
> >> I tend to agree with Ben here. When reading the draft, I got the
> feeling that the draft seems to assume a lot about the relationship
> between the uCDN and dCDN. For example, I don't see why the CDNI Request
> Routing interface should state that a dCDN MUST deliver the content if it
> has indicated its ability to do so earlier in either a contractual
> agreement or in the capability interface. I understand that in most cases,
> the contractual agreement might indeed impose this behavior on the dCDN,
> but I don't think this type of behavior should be imposed by the protocol
> we're developing here.
> >>
> >> It was always my assumption that the Request Routing Interface would at
> least include the option of allowing the uCDN to query the dCDN for every
> content request whether the dCDN is willing to deliver that particular
> request.
> >>
> Ben Niven-Jenkins
> >>> => This is the role of the CDNI DRIS interface to provide the uCDN
> with this information, and we target to make its specification public
> before Vancouver meeting so that everyone may read it before the meeting
> and get full knowledge of our proposal about this part of CDNI request
> routing.
> >>>
> >>> Ben, quoting you mail below, "... or "no I can't/won't take that
> content delivery right now", reasons may include the uCDN has requested a
> delivery of a protocol the dCDN does not support (possibly in error).
> >>>
> >> I agree this information should be logged but the Request Routing
> interface (what you call the DRIS) also needs to be able to indicate a
> failure.
> >>
> >> Otherwise the uCDN will 'blindly' redirect the the dCDN and the
> delivery will fail leading to poor end user experience.
> >>
> >>> Ben, quoting you mail below, "... or "no I can't/won't take that
> content delivery right now", reasons may include ... the dCDN has no
> capacity right now etc."
> >>>
> >> It is the role of the CDN capability/routing interface to advertise
> broad capabilities etc not to give extremely fine grained real-time
> information on exactly the state of the dCDN.
> >>
> >> Even if the capability/routing interface is real-time there are likely
> to still be race conditions where we need the dCDN to be about to indicate
> a failure to accept a redirect through the request routing/DRIS interface
> >>
> >>> The key point for us here is that we don't want this sentence
> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". and
> the dCDN MUST accept the content request except when it has not the
> "ability" to do so."
> >>> The fact that the dCDN is temporary unable to handle content request
> correctly is not a valid reason for the dCDN to be discharged of its
> obligations to the uCDN.
> >> Correct, but that contract may not be the same for all uCDNs & dCDNs,
> for example a uCDN may not have a guarantee that a dCDN can handle
> everything it is requested to handle but the contract may only be that the
> dCDN guarantees to handle up to a certain volume of traffic.
> >>
> >>> The dCDN must announce to the uCDN that it is temporary unable, as
> soon as possible, via the CDNI routing interface.
> >>> Then if the uCDN decides to continue to redirect content requests to
> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these content
> requests will be lost.
> >> What happens in the period between the dCDN being unable to handle
> requests and the time it takes to advertise that to the uCDN and for the
> uCDN to process & incorporate that new knowledge? Are requests blindly
> forwarded to the dCDN which is unable to handle them leading to poor user
> experience?
> >>
> >>> We could even imagine the situation where the uCDN continues to do it
> intentionally, because it has no better option and the content request
> will be lost anyway. For example in the case where neither the uCDN nor
> the other downstream CDNs of the uCDN cannot manage correctly the content
> request, the uCDN could do it intentionally so as to be able to clearly
> prove (with CDNI logging information) that it is the dCDN, not the uCDN,
> who is at fault.
> >>> But, of course, if there are alternative backup options, the normal
> reaction of the uCDN is to stop as soon as possible to redirect content
> requests to the dCDN when the uCDN knows that the dCDN is unable to handle
> them correctly.
> >>>
> >> What about scenarios where the uCDN has a choice of dCDNs (e.g. two
> national-wide CDNs offering services at different costs), the uCDN may
> elect to query both dCDNs and decide based on their responses which one to
> choose. If the dCDN is unable to satisfy the request the uCDN needs to
> know that so that it can fallback to the (more expensive in this example)
> dCDN.
> >>
> >>> For example the dCDN generates a response to the content request with
> an error message, or no response at all. And in parallel the CDNI logging
> interface may be used to exchange logs corresponding to this problem.
> Anyway the dCDN MAY NOT redirect that content request back towards the
> uCDN."
> >>>
> >>> Exactly as in IP networks: IP packets are not sent back towards the
> origin by a downstream router under failure or congestion.
> >> In a routed IP network, there is often a small packet loss while the
> network re-converges, by enabling the dCDN to refuse a redirection at CDNI
> Request Routing/DRIS query time we can reduce that window by giving the
> uCDN the option to take an alternative action (e.g. try another dCDN)
> while the routing/capability information re-converges.
> >>
> >> Loop avoidance is a separate issue IMO to whether we should allow a
> dCDN to be able to communicate "I am unable/unwilling to take that content
> delivery at this time".
> >>
> >> Regards
> >> Ben
> >>
> >>> And this would be just to try to save the content requests redirected
> by the uCDN to the dCDN in the timeslot between the time the dCDN gets
> down and the time the uCDN takes this failure into account in its CDN
> selection process.
> >>> It is much better to try to reduce this timeslot as much as possible,
> with routing optimizations (we will propose as soon as possible).
> >>> By the way, as you know, the IESG has just approved today the 'Content
> Distribution Network Interconnection (CDNI) Problem Statement' draft as
> informational RFC. This is a good point.
> >>> And, as you may see in the draft "CDNI request routing", we do not
> propose to modify this problem statement draft.
> >>> What was in the problem statement was meant to convey that an upstream
> CDN could make a request to a downstream CDN to say "how do I redirect
> this request to you" and the downstream CDN could reply with either "her
> is how to redirect it", or "no I can't/won't take that content delivery
> right now", reasons may include the uCDN has requested a delivery of a
> protocol the dCDN does not support (possibly in error) or the dCDN has no
> capacity right now etc.
> >>>
> >>> Ben
> >>>
> >>>> We have just submitted the draft below. We are convinced that it will
> help the WG to progress on the CDNI routing issues.
> >>>>
> >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >>>>
> >>>> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> >>>> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> >>>> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> >>>> Thank you.
> >>>>
> >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> >>> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> >>> Thank you.
> >>>
> __________________________________________________________________________
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >>
> >> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> >> Thank you.
> >>
> >>
> >>
> __________________________________________________________________________
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> >> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> >> Thank you.
> >>

---

From: <[email-masked]>
Date: Wed, 25 Jul 2012 11:39:12 +0000

Hi everyone,

I fully agree with Allan's comments. Putting aside the vocabulary ('recursive model' etc), Allan's comment are consistent with the messages that http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 tries to convey.

"   o  Regarding the former process, i.e. related to the "ability"
      CDNs to accept delegated content requests."

Best regards,
--
Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de GUILLOU, Allan
Envoyé : mercredi 25 juillet 2012 12:23
À : Scott Wainner; [email-masked]
Objet : Re: [CDNi] TR: I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Hi,

Allan

> de Scott Wainner Envoyé : lundi 16 juillet 2012 14:23 À : 
> [email-masked] Objet : Re: [CDNi] TR: I-D Action: 
> > We seem to be misunderstanding each other. Maybe this will help 
> > clarify
> my point:
> >
> real time, and for each content request, whether it denies or accepts 
> to ensure delivery?
> a model where for every content request the uCDN asks the dCDN whether 
> it wants to deliver that particular content item (I believe you call 
> this a PULL approach). And I would like to allow the dCDN to be able to say 'No'
> on this request (whether it is for purposes or failure, overload, or 
> any other reason).
> >
> real time, and for each content request, whether it denies or accepts 
> to ensure delivery, and this even if the dCDN has the capability to 
> deliver the content?
> > Yes.
> The recursive model assumes that the client request to the uCDN will 
> be recursive and the CDN-I RR interface will be used to provide an 
> answer for each client request.  The choice to initiate the recursion 
> would be determined by the footprint / capabilities.  The ability of 
> the dCDN to execute the specific request would provide immediate 
> feedback to the uCDN.  A dCDN that continues to advertise the 
> footprint / capability, but frequently or continually rejects the 
> request via CDN-I RR would be a poor candidate.  The opportunity now 
> arises where the uCDN may elect to choose an alternate dCDN because 
> its preferred dCDN (according to footprint / capabilities) is 'under-performing'.
>
> request is somewhat transparent to the uCDN.  With the exception of 
> the CDN-I logging, the uCDN assumes the dCDN is properly handling the 
> For the case where the dCDN repeatedly sees requests from the uCDN 
> that the dCDN can't handle, it should retract its footprint / 
> capabilities advertisement.  Failing to do so would continually 
> black-hole routing requests which would be indicated in the logging information.
>
> negatively to all requests for content request redirection submitted 
> by the uCDN over the CDNI request routing interface? (i.e. that 
> possibly the uCDN will never be allowed/invited to redirect a content 
> request to the
> dCDN?)
> >
> >> Please let us know exactly to which sentence(s) of the draft you 
> >> are
> referring to.
> aspect relating to a dCDN deciding unilaterally to stop living up to 
> its contractual agreement.
> >>
> >> Please let us know where you saw such an idea in this IETF draft 
> >> "CDNI
> request routing".
> >>
> between two CDNs is one in which the uCDN and dCDN have agreed that 
> the dCDN will deliver some content on behalf of a uCDN, but decide on 
> a per- request basis whether it wants to do so (and is for example 
> paid per request). In these cases, the dCDN needs to have the ability 
> to deny delivery on a per-request basis."
> >>
> real time, and for each content request, whether it denies or accepts 
> to ensure delivery?
> real time, and for each content request, whether it denies or accepts 
> to ensure delivery, and this even if the dCDN has the capability to 
> deliver the content?
> negatively to all requests for content request redirection submitted 
> by the uCDN over the CDNI request routing interface? (i.e. that 
> possibly the uCDN will never be allowed/invited to redirect a content 
> request to the
> dCDN?)
> >>
> >>
> behavior of interconnected elements/networks on a technical level, not 
> on a business level."
> >>
> >> Envoyé : mardi 10 juillet 2012 15:13 À : LE LOUEDEC Yannick 
> >> RD-CORE; Ben Niven-Jenkins Cc : Pilarski Marcin - Korpo TP; 
> >> [email-masked]; MARREC Anne RD-CORE Objet : RE: [CDNi] TR: I-D 
> of contractual/business agreement that might or might not exist 
> between a dCDN and uCDN. The current drafts seems to assume some 
> particular type of contractual agreement between CDNs that might not always be the case.
> >>
> >> Ray
> >>
> indicated its ability to do so earlier in either a contractual 
> agreement or in the capability interface."
> >>
> >> It put in writings the respective obligations of the uCDN and of 
> >> the
> dCDN.
> in full conformance with the terms of this contractual agreement (the 
> type of the content request is in full conformance, the maximum number 
> of content requests per second is respected, etc.).
> >> In this case the dCDN may not say "Sorry, but I decide unilaterally 
> >> to
> refuse this content request".
> >>
> describe (the dCDN not living up to its obligation) should not be 
> enforced by the CDNI Interfaces. If a dCDN does not live up to its 
> business level, not on a protocol level.
> >>
> >> Why? Because this is the deal, a contractual agreement is a 
> >> contractual
> agreement!
> correctly a certain class of content requests specified in our 
> contractual agreement" (for example the class of the HTTP content 
> requests with token from French end users, because of overload 
> situation, failure, etc.) This is the role of the CDNI routing 
> interface to provide the uCDN with such information.
> >>
> >> (And the dCDN may be given a penalty for example if this was agreed 
> >> in
> the terms of the contractual agreement.)
> >>
> >>
> Anyway: one example of a contractual agreement between two CDNs is one 
> in which the uCDN and dCDN have agreed that the dCDN will deliver some 
> content on behalf of a uCDN, but decide on a per-request basis whether 
> it wants to do so (and is for example paid per request). In these 
> cases, the dCDN needs to have the ability to deny delivery on a per-request basis.
> >>
> the uCDN, it is impossible to dimension adequately the dCDN, neither 
> to define correctly the CDNI contractual agreements between the dCDN 
> and the dCDNs of this dCDN.
> the dCDN, the dCDN may do what it wants... even to put in the trash 
> can any content request it accepted to handle.
> >>
> business/contractual level and not on a technical level. That is way 
> IMHO the CDNI Interfaces should not make ANY assumptions on what was 
> agreed on a contractual level.
> >>
> >> In both situations it is impossible to ensure any quality of 
> >> experience
> to the end user.
> >>
> >>
> interconnected elements/networks on a technical level, not on a 
> business level. Having a dCDN say  'I'm not willing to deliver this 
> content' is perfectly fine from a technical perspective, although it 
> could be problematic from a contractual perspective.
> >>
> >> But maybe I will understand if you provide an example on the point 
> >> 2
> above.
> >>
> >>
> >> Best regards,
> >>
> >> Yannick Le Louédec.
> >>
> >>
> >>
> >> Envoyé : mardi 10 juillet 2012 09:20 À : Ben Niven-Jenkins; LE 
> >> LOUEDEC Yannick RD-CORE Cc : Pilarski Marcin
> between the uCDN and dCDN. For example, I don't see why the CDNI 
> Request Routing interface should state that a dCDN MUST deliver the 
> content if it has indicated its ability to do so earlier in either a 
> contractual agreement or in the capability interface. I understand 
> that in most cases, the contractual agreement might indeed impose this 
> behavior on the dCDN, but I don't think this type of behavior should 
> be imposed by the protocol we're developing here.
> >>
> least include the option of allowing the uCDN to query the dCDN for 
> every content request whether the dCDN is willing to deliver that 
> particular request.
> >>
> >>> Ben, quoting you mail below, "... the downstream CDN could reply 
> >>> with either "here is how to redirect it"",
> >>>
> before Vancouver meeting so that everyone may read it before the 
> meeting and get full knowledge of our proposal about this part of CDNI 
> request routing.
> >>>
> content delivery right now", reasons may include the uCDN has 
> requested a delivery of a protocol the dCDN does not support (possibly in error).
> >>>
> >>> => This is the role of the CDNI logging interface to provide the 
> >>> uCDN
> with this information.
> >>> => This is the role of the CDNI routing interface to provide the 
> >>> uCDN
> with this information.
> to still be race conditions where we need the dCDN to be about to 
> indicate a failure to accept a redirect through the request 
> routing/DRIS interface
> >>
> extracted from draft-ietf-cdni-problem-statement be interpreted as: ". 
> and the dCDN MUST accept the content request except when it has not 
> the "ability" to do so."
> >>> The contract set between the uCDN and the dCDN remains valid 
> >>> anyway,
> and the obligations of the dCDN as well.
> everything it is requested to handle but the contract may only be that 
> the dCDN guarantees to handle up to a certain volume of traffic.
> >>
> the dCDN, the uCDN MAY perfectly do it, but the uCDN knows these 
> content requests will be lost.
> requests and the time it takes to advertise that to the uCDN and for 
> the uCDN to process & incorporate that new knowledge? Are requests 
> blindly forwarded to the dCDN which is unable to handle them leading 
> to poor user experience?
> >>
> will be lost anyway. For example in the case where neither the uCDN 
> nor the other downstream CDNs of the uCDN cannot manage correctly the 
> content request, the uCDN could do it intentionally so as to be able 
> to clearly prove (with CDNI logging information) that it is the dCDN, 
> not the uCDN, who is at fault.
> reaction of the uCDN is to stop as soon as possible to redirect 
> content requests to the dCDN when the uCDN knows that the dCDN is 
> unable to handle them correctly.
> >>>
> >>> And if it cannot handle correctly the redirected content request 
> >>> it
> receives, the content request is lost.
> elect to query both dCDNs and decide based on their responses which 
> one to choose. If the dCDN is unable to satisfy the request the uCDN 
> needs to know that so that it can fallback to the (more expensive in 
> this example) dCDN.
> >>
> an error message, or no response at all. And in parallel the CDNI 
> logging interface may be used to exchange logs corresponding to this problem.
> network re-converges, by enabling the dCDN to refuse a redirection at 
> CDNI Request Routing/DRIS query time we can reduce that window by 
> giving the uCDN the option to take an alternative action (e.g. try 
> another dCDN) while the routing/capability information re-converges.
> >>
> dCDN to be able to communicate "I am unable/unwilling to take that 
> content delivery at this time".
> >>
> >> Regards
> >> Ben
> >>
> >>> Rather than introducing additional complexities (to manage 
> >>> redirection
> to the uCDN) in the framework.
> >>>
> >>>
> Distribution Network Interconnection (CDNI) Problem Statement' draft 
> as informational RFC. This is a good point.
> >>> We want know to focus now on getting the specifications of all 
> >>> CDNI
> interfaces ready as soon as possible.
> >>>
> >>> Best regards,
> >>>
> >>> Yannick Le Louédec.
> >>>
> >>>
> >>> De : [email-masked] [mailto:[email-masked]] De la 
> >>> part de Ben Niven-Jenkins Envoyé : lundi 9 juillet 2012 20:41 À : 
> >>> BERTRAND Gilles RD-CORE Cc : [email-masked]; Pilarski Marcin - 
> >>> Korpo TP; MARREC Anne RD-CORE Objet : Re: [CDNi] TR: I-D Action:
> >>>      ("enables a Request Routing function in an upstream CDN to 
> >>> query
> a
> >>>      reverse approach ("uCDN queries it downstream CDNs dCDN 1, 
> >>> dCDN
> 2,
> >>>      ("enables a Request Routing function in an upstream CDN to 
> >>> query
> a
> >>>      As the uCDN knows, thanks to the routing information 
> >>> exchanged
> via
> this request to you" and the downstream CDN could reply with either 
> "her is how to redirect it", or "no I can't/won't take that content 
> delivery right now", reasons may include the uCDN has requested a 
> delivery of a protocol the dCDN does not support (possibly in error) 
> or the dCDN has no capacity right now etc.
> >>>
> >>> Ben
> >>>
> >>>> A New Internet-Draft is available from the on-line 
> >>>> Internet-Drafts
> directories.
> >>>>
> >>>>
> >>>> interface introduced in [I-D.ietf-cdni-framework] and 
> >>>> [I-D.ietf-cdni- problem-statement], as well as related terminology.
> >>>>
> >>>> Request  Routing interface into two separate interfaces with 
> >>>> clearer roles,  named respectively CDNI Routing interface and 
> >>>> CDNI Downstream Resource Identifier Signaling interface (CDNI DRIS interface).
> >>>>
> >>>> another routing, signaling and forwarding problem in a long 
> >>>> series of the telecommunication history.  For example, one can 
> >>>> draw a direct analogy between the IP/MPLS-TE framework and the 
> >>>> CDN interconnection framework.
> >>>>
> >>>> In addition, this document recommends that the specification of 
> >>>> ALL CDN interconnection interfaces in the scope of the CDNI IETF 
> >>>> WG relies on the equivalent concept to IP prefix for CDN 
> >>>> interconnection, named 'contentRequestScope'.  This highly useful 
> >>>> and powerful concept SHALL be used to simplify the specification 
> >>>> of ALL CDN interconnection interfaces, as well as to ensure 
> >>>> performance and scalability in CDN interconnection.
> >>>>
> >>>> [I-D.ietf-cdni-requirements], as they essentially propose 
> >>>> (useful) clarifications of the existing framework.
> >>>>
> >>>>
> >>>> _________________________________________________________________
> >>>> ____ ____________________________________________________
> >>>>
> >>>> Ce message et ses pieces jointes peuvent contenir des 
> >>>> informations confidentielles ou privilegiees et ne doivent donc 
> >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> >>>> avez recu ce message par erreur, veuillez le signaler a 
> >>>> l'expediteur et le detruire ainsi
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
> >>>>
> >>> __________________________________________________________________
> >>> ____ ___________________________________________________
> >>>
> >>> confidentielles ou privilegiees et ne doivent donc pas etre 
> >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> >>> ce message par erreur, veuillez le signaler a l'expediteur et le 
> >>> detruire ainsi
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> ____ _______________________________________________
> >>
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> privileged
> information that may be protected by law; they should not be 
> distributed, used or copied without authorisation.
> ____ _______________________________________________
> >>
> >> France Telecom - Orange decline toute responsabilite si ce message 
> >> a
> ete altere, deforme ou falsifie. Merci.
> >>
> >> privileged

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 25 Jul 2012 12:35:45 +0000

All,

To help the discussion, we may need to distinguish three (main) modes:

*A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN. The uCDN redirects to the selected dCDN and considers that he is done with request routing.

*B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN candidate. The uCDN queries the dCDN before redirecting. 
Querying dCDN optionally allows the dCDN to provide to uCDN the final redirection information so the the enduser experiences a single redirect.
Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the initially selected dCDN cannot handle the request.

*C* the uCDN queries multiple dCDNs on a per-request basis and selects dCDN based on their responses. In other words, the Footprint&Cap advertisement is performed via on-demand per-request queries. 

I think:
	* Scott pointed out that fundamentatly both *A* and *B* have to deal with (typically transient) situations where uCDN thinks dCDN can take a request and dCDN actually cannot handle it. And pointed out that with *A* the transient period is dictated by the Footprint&Cap advertisement "update speed" while with *B* it is not.
	* Allan was saying *A* is all he needs and *B* is extra complexity that he doesn't need.
	* Gilles and lelouedec-cdni-request-routing were saying *C* is bad. 

My impression is that there is violent agreement that *A* is to be supported. I think Allan and Gilles message indicate so. I personally support that. I think many people have been discussing that approach. If someone feels this is NOT to be supported by CDNI, do let us know. 

I think Gilles message below is primarily arguing against *C*. I personally agree that this need not be supported in our initial deliverables. Are there people arguing this approach is to be supported in the initial deliverables? 

Regarding *B*, I personally see it as quite useful and worth supporting in Phase 1 (possibly as an option). 
Regarding Allan's points:
	* I agree there is some "scalability" argument (i.e. state+wait-for-dCDN-response) but it amounts to a web-services call out per request and buys you reliability of request routing, so I see that as a trade-off that some CDNs should be able to exercise. 
	* I don't buy the latency argument because you end up with 2 RTTs in both *A* and *B* (in normal situations where dCDN can handle the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN cannot handle the request *B* can do as well as *A* (drop the request) or has the option to differently i.e. re-redirect at the cost of an extra RTT. 
	* I don't buy the "loop free mechanism" argument. In *B*, it is easy to implement a loop detection and even loop prevention (if you want). In *A*, you have no loop prevention (other than the inherent HTTP/DNS max redirect/max CNAMEs)
Other opinions on *B* are sought.

Cheers

Francois

On 25 Jul 2012, at 13:39, <[email-masked]>
 <[email-masked]> wrote:

>>>> avez

---

From: "GUILLOU, Allan" <[email-masked]>
Date: Wed, 25 Jul 2012 13:04:29 +0000

In *B* you still have a per session request to the dCDN. If it is just to handle a problem in the dCDN, and that you consider that you realy need this kind of information, another method can be to add an "back pressure mechanism".

It could be done by a message sent from dCDN to uCDN when ie is overload, or by adding in the Footprint&Cap information a "max value" which can give the number of stream that the dCDN can accept from this specific uCDN. In case of overload, the dCDN can just send an update with a lower value to ask the uCDN to select another dCDN.

> De : Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Envoyé : mercredi 25 juillet 2012 14:36
> À : <[email-masked]> <[email-masked]>
> Cc : Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner
> (swainner); [email-masked]
> Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt
>
> All,
>
> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) to
> select a dCDN. The uCDN redirects to the selected dCDN and considers that
> he is done with request routing.
>
> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to
> select a dCDN candidate. The uCDN queries the dCDN before redirecting.
> Querying dCDN optionally allows the dCDN to provide to uCDN the final
> redirection information so the the enduser experiences a single redirect.
> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the
> initially selected dCDN cannot handle the request.
>
> *C* the uCDN queries multiple dCDNs on a per-request basis and selects
> dCDN based on their responses. In other words, the Footprint&Cap
> advertisement is performed via on-demand per-request queries.
>
>
> I think:
>       * Scott pointed out that fundamentatly both *A* and *B* have to deal
> with (typically transient) situations where uCDN thinks dCDN can take a
> request and dCDN actually cannot handle it. And pointed out that with *A*
> the transient period is dictated by the Footprint&Cap advertisement
> "update speed" while with *B* it is not.
> My impression is that there is violent agreement that *A* is to be
> supported. I think Allan and Gilles message indicate so. I personally
> support that. I think many people have been discussing that approach. If
> someone feels this is NOT to be supported by CDNI, do let us know.
>
> I think Gilles message below is primarily arguing against *C*. I
> personally agree that this need not be supported in our initial
> deliverables. Are there people arguing this approach is to be supported in
> the initial deliverables?
>
>       * I agree there is some "scalability" argument (i.e. state+wait-for-
> dCDN-response) but it amounts to a web-services call out per request and
> buys you reliability of request routing, so I see that as a trade-off that
> some CDNs should be able to exercise.
>
>       * I don't buy the latency argument because you end up with 2 RTTs in
> both *A* and *B* (in normal situations where dCDN can handle the request)
> (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user--
> >uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases
> where dCDN cannot handle the request *B* can do as well as *A* (drop the
> request) or has the option to differently i.e. re-redirect at the cost of
> an extra RTT.
>       * I don't buy the "loop free mechanism" argument. In *B*, it is easy
> to implement a loop detection and even loop prevention (if you want). In
> *A*, you have no loop prevention (other than the inherent HTTP/DNS max
> redirect/max CNAMEs)
> > I fully agree with Allan's comments. Putting aside the vocabulary
> ('recursive model' etc), Allan's comment are consistent with the messages
> that http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00
> tries to convey.
> >
> GUILLOU, Allan
> > With a "recusive model" as you ask if I understand, you expect the dCDN
> to send like an "ack" for each request, and if not the uCDN will try to
> find the second best dCDN and do the same thing.
> >
> > I think that this model may add complexity and may cause some
> scalability problem. You will have to implement timers between request and
> ack, retransmission mechanism to make sure that request has not been lost,
> loop free mechanism, And all this may add latency on all requests and
> performances problems.
> >
> > In the iterative model, if the dCDN is not able to handle the request,
> this request will be lost. It is the same thing in IP network today we do
> not ask the routing protocol to change when there is saturation somewhere.
> It is the responsibility of each ISP to choose another route to join this
> destination if he want to keep a good quality of service. If a dCDN is
> overloaded, it will stop announcing part of its footprint or uCDN may
> apply some policy to force choosing another dCDN.
> >
> > It is right that this second model may not in case of dCDN saturation
> have the best reactivity, but it is exactly the same thing on the internet
> today. We can imagine that a poor dCDN which have saturation will be
> "black listed" by all the uCDN and the regulation will be done like this.
> > I think recursive model will add complexity all the time for a gain
> witch is not in my opinion so important and that will not be seen so
> often.
> >
> > Allan
> >
> always be the case.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 25 Jul 2012 13:07:29 +0000

Hi all,

Francois, thanks for clarifying this discussion, very helpful.

I tend to agree with your assessment of the various options. Personally, I would be opposed to a CDNI specification that does not include *B* at least as an option, since to me *A* is not suited for 'premium'-content cases where you want to minimize the chances of content not being delivered. In these cases, scalability might be less of a concern, especially for CDNs that do internal request routing for each request anyway. In addition, I think the CDNI interfaces should at least support a scenario where the dCDN, whatever it advertises, should always have the option of turning down a content delivery request by a uCDN, whether it is for reasons of overload, technical difficulty or simply business reasons. If a dCDN does this too often for a uCDNs liking, than that uCDN can simply decide to no longer do business with that dCDN by not choosing it again for future redirects. 

Finally, I think it should be up to the uCDN to decide how it chooses a dCDN, whether it is based on capability and footprint information or simply by polling different dCDNs. If that polling is performed by the same mechanism that is used by *B*, I don't see any reason not to support that. 

Best regards,

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: woensdag 25 juli 2012 14:36
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt

All,

I think:

	* I don't buy the latency argument because you end up with 2 RTTs in both *A* and *B* (in normal situations where dCDN can handle the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user versus user-->uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user) and in the transient cases where dCDN cannot handle the request *B* can do as well as *A* (drop the request) or has the option to differently i.e. re-redirect at the cost of an extra RTT. 
	* I don't buy the "loop free mechanism" argument. In *B*, it is easy to implement a loop detection and even loop prevention (if you want). In *A*, you have no loop prevention (other than the inherent HTTP/DNS max redirect/max CNAMEs) Other opinions on *B* are sought.

Cheers

Francois

On 25 Jul 2012, at 13:39, <[email-masked]>  <[email-masked]> wrote:

> de GUILLOU, Allan Envoyé : mercredi 25 juillet 2012 12:23 À : Scott 
> Wainner; [email-masked] Objet : Re: [CDNi] TR: I-D Action: 
>> a model where for every content request the uCDN asks the dCDN 
>> whether it wants to deliver that particular content item (I believe 
>> you call this a PULL approach). And I would like to allow the dCDN to be able to say 'No'
>> The iterative model, the uCDN blindly redirects the client to the 
>> dCDN based on the footprint / capabilities.  What the dCDN does with 
>> the request is somewhat transparent to the uCDN.  With the exception 
>> of the CDN-I logging, the uCDN assumes the dCDN is properly handling 
>> the requests that were delegated to the dCDN.  If you are trying to 
>> send a message saying "Sorry, but I decide unilaterally to refuse 
>> this content request".
>> behavior of interconnected elements/networks on a technical level, 
>> not on a business level."
>>>> 
>> type of the content request is in full conformance, the maximum 
>> number of content requests per second is respected, etc.).
>> Anyway: one example of a contractual agreement between two CDNs is 
>> one in which the uCDN and dCDN have agreed that the dCDN will deliver 
>> some content on behalf of a uCDN, but decide on a per-request basis 
>> whether it wants to do so (and is for example paid per request). In 
>> these cases, the dCDN needs to have the ability to deny delivery on a per-request basis.
>>>> 
>> that in most cases, the contractual agreement might indeed impose 
>> this behavior on the dCDN, but I don't think this type of behavior 
>> should be imposed by the protocol we're developing here.
>>>> 
>> meeting and get full knowledge of our proposal about this part of 
>> CDNI request routing.
>>>>> 
>> interface (what you call the DRIS) also needs to be able to indicate 
>> a failure.
>>>> 
>> everything it is requested to handle but the contract may only be 
>> that the dCDN guarantees to handle up to a certain volume of traffic.
>>>> 
>> intentionally, because it has no better option and the content 
>> request will be lost anyway. For example in the case where neither 
>> the uCDN nor the other downstream CDNs of the uCDN cannot manage 
>> correctly the content request, the uCDN could do it intentionally so 
>> as to be able to clearly prove (with CDNI logging information) that 
>> it is the dCDN, not the uCDN, who is at fault.
>> national-wide CDNs offering services at different costs), the uCDN 
>> may elect to query both dCDNs and decide based on their responses 
>> which one to choose. If the dCDN is unable to satisfy the request the 
>> uCDN needs to know that so that it can fallback to the (more 
>> expensive in this example) dCDN.
>>>> 
>> Anyway the dCDN MAY NOT redirect that content request back towards 
>> the uCDN."
>>>>> 
>> by the uCDN to the dCDN in the timeslot between the time the dCDN 
>> gets down and the time the uCDN takes this failure into account in 
>> its CDN selection process.
>>>>> Routing  interface enables a Request Routing function in an 
>>>>> upstream CDN to  query a Request Routing function in a downstream 
>>>>> CDN to determine if  the downstream CDN is able (and willing) to 
>>>>> accept the delegated  content request".
>>>>> 
>>>>>  The "ability" and the "willingness" of the downstream CDN to 
>>>>> accept  the delegated content request match two fully different 
>>>>> processes in  CDN interconnection.  And the description of both 
>>>>> these processes  should be reviewed and clarified for the following reasons:
>>>>> 
>> CDN could make a request to a downstream CDN to say "how do I 
>> redirect this request to you" and the downstream CDN could reply with 
>> either "her is how to redirect it", or "no I can't/won't take that 
>> requested a delivery of a protocol the dCDN does not support 
>> (possibly in error) or the dCDN has no capacity right now etc.
>>>>> 
>>>>> Ben
>>>>> 
>> _ ____ _______________________________________________
>>>> 
>> _ ____ _______________________________________________
>>>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 25 Jul 2012 13:20:42 +0000

Hi Ray,

Good input. Thanks. 
One point below:

> Finally, I think it should be up to the uCDN to decide how it chooses a dCDN, whether it is based on capability and footprint information or simply by polling different dCDNs. If that polling is pe…

You bring up a very good point here. I would probably also agree that "If that polling is performed by the same mechanism that is used by *B*, I don't see any reason not to support that". The thing is that we don't have much time/cycles to spend to make sure the "polling" provides all the needed info & knobs, and that all the error cases and scenario combinations are fully addressed. But I take your point that, a polling interface developed for *B* could be used by uCDN to achieve *C*.

Thanks

Francois

---

From: Scott Wainner <[email-masked]>
Date: Wed, 25 Jul 2012 11:04:49 -0400

I agree with Ray that we should support *A* and *B* modes.

The *C* mode is a special case of *B* where the uCDN has elected to use 
*B* in parallel with multiple dCDN.  This is an internal implementation 
of the uCDN.

I think we already agreed to support Iterative and Recursive modes.

My point about the differences in *A* and *B* is that you need 
information exchange between dCDN and uCDN.

You can choose to make that information exchange fast in the 
capabilities and footprint announcement which mitigates the value of *B* 
mode (the uCDN queries the dCDN before referring the client).  The dCDN 
will need to quickly propagate information to the uCDN to avoid losing 
content requests when random things don't work (overload, cache node 
failure, routing request error, whatever, ...).  The disadvantage is the 
uCDN must be responsive to ALL the dCDN updates coming in based on 
events in each dCDN. The operator will end up dampening these inputs to 
avoid thrashing.

You can choose to make that information exchange slow in the 
capabilities and footprint advertisements and fast in the routing 
request process (per content request referral).  This negates the value 
of *A* mode (the uCDN blindly refers the client the dCDN). The dCDN will 
need to quickly respond to inquiries of the uCDN.

A key trade-off will be particularly noticeable where the uCDN/dCDN is 
supporting HAS a per-chunk request.  It simply doesn't scale unless the 
uCDN rewrites the manifest such that the remainder of the "session 
requests" are referred to the dCDN and all subsequent chunks are 
retrieved directly from the dCDN without having to refer back to the uCDN.

If the retrieval is a large-object retrieval, then *B* would be sufficient.

Scott

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 07:41:58 +0000

Dear all,

Many thanks for this discussion!
These are some of the questions I wished to be addressed at the Vancouver meeting.

Here are some comments on the draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 using the three (main) modes (A, B and C) listed by François Le Faucheur in its mail below.

****** First comment:

Quoting the description from François of the mode B:

"*B* the uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN candidate. The uCDN queries the dCDN before redirecting. 
Querying dCDN optionally allows the dCDN to provide to uCDN the final redirection information so the the enduser experiences a single redirect.
Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the initially selected dCDN cannot handle the request."

This description from François shows clearly that there is a first step that consists in the uCDN using the Footprint&Cap information (advertised by dCDN) to select a dCDN candidate.
This is the role of what we call the CDNI routing interface in the draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00. 

****** Second comment:

After this dCDN candidate is selected,
we mentioned in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 that the next step is managed by another process that exploits information provided by the interface we call "CDNI Downstream Resource Identifier (DRIS) interface".

As mentioned earlier in a mail, our intent is to come in Vancouver with a description of that CDNI DRIS interface, even if we will be probably a bit short of time to publish an IETF draft with this specification before the end of the week.
But basically this interface allows to support the modes A and B (and also the mode C, as mentioned in my fourth comment below).

In mode A, and to quote François' descriptions, this CDNI DRIS allows to proceed as follows: "The uCDN redirects to the selected dCDN and considers that he is done with request routing."

In mode B, and to quote François' descriptions, this CDNI DRIS allows to proceed as follows: " The uCDN queries the dCDN before redirecting. 
Querying dCDN optionally allows the dCDN to provide to uCDN the final redirection information so the the enduser experiences a single redirect.
Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the initially selected dCDN cannot handle the request."

Our intent (the co-authors of the draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00) is indeed to make proposals that support modes A and B.

******* Third comment

The way François described the mode B tends again to confirm the interest to split the CDNI request routing interface into two sub-interfaces, at least very clearly for mode B.
But I do not comment this further as there is a priori a clear consensus on that point within the CDNI WG.

****** Fourth comment:

I have a common comment about :
** this following sentence from François in its description of mode B: "Querying dCDN optionally allows the uCDN to pick an alternate dCDN if the initially selected dCDN cannot handle the request."
** the following comment from Scott in its mail below: "The *C* mode is a special case of *B* where the uCDN has elected to use *B* in parallel with multiple dCDN.  This is an internal implementation of the uCDN."

Indeed fully agree that all this relates to the internal implementation of the uCDN.
Another way to say this is "Provided its CDNI interfaces allow to support mode B, an uCDN can support the mode C (on condition the uCDN has the adequate internal implementation for mode C)".

We (Orange) have published the draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 having in mind that the mode C is not our priority (which is per se something we wanted to share).
But our proposals about the CDNI request routing interface (with these CDNI routing interface and CDNI DRIS interface) allow therefore also to support the mode C, on condition indeed that the uCDN has the adequate internal implementation for mode C.
We did not detail this point in the IETF draft (as, again, mode C was not our priority).
But these comments from François and Scott are very much helpful to clarify and underline this point.

****** Fourth comment:

In the same vein, and to come back to the mail exchanges we had right after the publication of the draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 about capability and "willingness",
if the standard specifications from the CDNI WG MUST indeed allow the dCDN to refuse that a given content request be redirected to it even if it has enough capabilities to handle that content request (the dCDN can but does not want to handle that content request), the specification of the CDNI DRIS interface we were about to share allows also to support this.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Scott Wainner
Envoyé : mercredi 25 juillet 2012 17:05
À : [email-masked]
Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt

The *C* mode is a special case of *B* where the uCDN has elected to use
*B* in parallel with multiple dCDN.  This is an internal implementation of the uCDN.

My point about the differences in *A* and *B* is that you need information exchange between dCDN and uCDN.

You can choose to make that information exchange fast in the capabilities and footprint announcement which mitigates the value of *B* mode (the uCDN queries the dCDN before referring the client).  The dCDN will need to quickly propagate information to the uCDN to avoid losing content requests when random things don't work (overload, cache node failure, routing request error, whatever, ...).  The disadvantage is the uCDN must be responsive to ALL the dCDN updates coming in based on events in each dCDN. The operator will end up dampening these inputs to avoid thrashing.

You can choose to make that information exchange slow in the capabilities and footprint advertisements and fast in the routing request process (per content request referral).  This negates the value of *A* mode (the uCDN blindly refers the client the dCDN). The dCDN will need to quickly respond to inquiries of the uCDN.

A key trade-off will be particularly noticeable where the uCDN/dCDN is supporting HAS a per-chunk request.  It simply doesn't scale unless the uCDN rewrites the manifest such that the remainder of the "session requests" are referred to the dCDN and all subsequent chunks are retrieved directly from the dCDN without having to refer back to the uCDN.

Scott

On 7/25/12 9:20 AM, Francois Le Faucheur (flefauch) wrote:
>> Subject: Re: [CDNi] I-D Action: 
>>>> part de Scott Wainner Envoyé : lundi 16 juillet 2012 14:23 À :
>>>> real time, and for each content request, whether it denies or 
>>>> accepts to ensure delivery?
>>>> on this request (whether it is for purposes or failure, overload, 
>>>> or any other reason).
>>>> real time, and for each content request, whether it denies or 
>>>> accepts to ensure delivery, and this even if the dCDN has the 
>>>> capability to deliver the content?
>>>>> Yes.
>>>> The recursive model assumes that the client request to the uCDN 
>>>> will be recursive and the CDN-I RR interface will be used to 
>>>> provide an answer for each client request.  The choice to initiate 
>>>> the recursion would be determined by the footprint / capabilities.  
>>>> The ability of the dCDN to execute the specific request would 
>>>> provide immediate feedback to the uCDN.  A dCDN that continues to 
>>>> advertise the footprint / capability, but frequently or continually 
>>>> rejects the request via CDN-I RR would be a poor candidate.  The 
>>>> opportunity now arises where the uCDN may elect to choose an 
>>>> alternate dCDN because its preferred dCDN (according to footprint / capabilities) is 'under-performing'.
>>>>
>>>> dCDN based on the footprint / capabilities.  What the dCDN does 
>>>> with the request is somewhat transparent to the uCDN.  With the 
>>>> exception of the CDN-I logging, the uCDN assumes the dCDN is 
>>>> properly handling the requests that were delegated to the dCDN.  If 
>>>> you are trying to 'tighten' up the case of blind rejections, then 
>>>> the frequency of the footprint / capabilities advertisements would have to be accelerated.
>>>> negatively to all requests for content request redirection 
>>>> submitted by the uCDN over the CDNI request routing interface? 
>>>> (i.e. that possibly the uCDN will never be allowed/invited to 
>>>> redirect a content request to the
>>>> dCDN?)
>>>> particular type of contractual agreement between CDNs that might 
>>>> not always be the case."
>>>>>> Please quote the draft.
>>>> contractual agreement, this should be something that is handled on 
>>>> a business level, not on a protocol level."
>>>> aspect relating to a dCDN deciding unilaterally to stop living up 
>>>> to its contractual agreement.
>>>> the dCDN will deliver some content on behalf of a uCDN, but decide 
>>>> on a per- request basis whether it wants to do so (and is for 
>>>> example paid per request). In these cases, the dCDN needs to have 
>>>> the ability to deny delivery on a per-request basis."
>>>> real time, and for each content request, whether it denies or 
>>>> accepts to ensure delivery?
>>>> real time, and for each content request, whether it denies or 
>>>> accepts to ensure delivery, and this even if the dCDN has the 
>>>> capability to deliver the content?
>>>> negatively to all requests for content request redirection 
>>>> submitted by the uCDN over the CDNI request routing interface? 
>>>> (i.e. that possibly the uCDN will never be allowed/invited to 
>>>> redirect a content request to the
>>>> dCDN?)
>>>>>>
>>>>>> Again, this is not what I have written, and this is not the idea 
>>>>>> we
>>>> want to share.
>>>> between ISP from the BGP configuration of their IP routers (see 
>>>> CAIDA project), but this is another story.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Yannick Le Louédec.
>>>>>>
>>>>>>
>>>>>>
>>>> interface should state that a dCDN MUST deliver the content if it 
>>>> in full conformance with the terms of this contractual agreement 
>>>> (the type of the content request is in full conformance, the 
>>>> maximum number of content requests per second is respected, etc.).
>>>>>> In this case the dCDN may not say "Sorry, but I decide 
>>>>>> unilaterally to
>>>> contractual agreement, this should be something that is handled on 
>>>> a business level, not on a protocol level.
>>>>>> (And the dCDN may be given a penalty for example if this was 
>>>>>> agreed in
>>>>>> Please provide the description of an example where this is not 
>>>>>> the
>>>> case.
>>>>>> Otherwise the IETF CDNI WG shall indeed consider this is ALWAYS 
>>>>>> the
>>>> case.
>>>> one in which the uCDN and dCDN have agreed that the dCDN will 
>>>> deliver some content on behalf of a uCDN, but decide on a 
>>>> per-request basis whether it wants to do so (and is for example 
>>>> paid per request). In these cases, the dCDN needs to have the ability to deny delivery on a per-request basis.
>>>> the uCDN, it is impossible to dimension adequately the dCDN, 
>>>> neither to define correctly the CDNI contractual agreements between 
>>>> the dCDN and the dCDNs of this dCDN.
>>>> business/contractual level and not on a technical level. That is 
>>>> way IMHO the CDNI Interfaces should not make ANY assumptions on 
>>>> what was agreed on a contractual level.
>>>> content' is perfectly fine from a technical perspective, although 
>>>> it could be problematic from a contractual perspective.
>>>> content if it has indicated its ability to do so earlier in either 
>>>> a contractual agreement or in the capability interface. I 
>>>> understand that in most cases, the contractual agreement might 
>>>> indeed impose this behavior on the dCDN, but I don't think this 
>>>> type of behavior should be imposed by the protocol we're developing here.
>>>> with this information, and we target to make its specification 
>>>> public before Vancouver meeting so that everyone may read it before 
>>>> the meeting and get full knowledge of our proposal about this part 
>>>> of CDNI request routing.
>>>> interface (what you call the DRIS) also needs to be able to 
>>>> indicate a failure.
>>>> content delivery right now", reasons may include ... the dCDN has 
>>>> no capacity right now etc."
>>>>>>> We just aimed at checking there was a common understanding on 
>>>>>>> this
>>>> point.
>>>> correctly is not a valid reason for the dCDN to be discharged of 
>>>> its obligations to the uCDN.
>>>> requests and the time it takes to advertise that to the uCDN and 
>>>> for the uCDN to process & incorporate that new knowledge? Are 
>>>> requests blindly forwarded to the dCDN which is unable to handle 
>>>> them leading to poor user experience?
>>>> correctly the content request, the uCDN could do it intentionally 
>>>> so as to be able to clearly prove (with CDNI logging information) 
>>>> that it is the dCDN, not the uCDN, who is at fault.
>>>> which one to choose. If the dCDN is unable to satisfy the request 
>>>> the uCDN needs to know that so that it can fallback to the (more 
>>>> network re-converges, by enabling the dCDN to refuse a redirection 
>>>> at CDNI Request Routing/DRIS query time we can reduce that window 
>>>> by giving the uCDN the option to take an alternative action (e.g. 
>>>> try another dCDN) while the routing/capability information re-converges.
>>>> Distribution Network Interconnection (CDNI) Problem Statement' 
>>>> draft as informational RFC. This is a good point.
>>>>>>> I started reading draft-lelouedec-cdni-request-routing-00 and 
>>>>>>> this
>>>> text caught my eye:
>>>>>>> upstream CDN to  query a Request Routing function in a 
>>>>>>> downstream CDN to determine if  the downstream CDN is able (and 
>>>>>>> willing) to accept the delegated  content request".
>>>>>>>
>>>> redirect this request to you" and the downstream CDN could reply 
>>>> with either "her is how to redirect it", or "no I can't/won't take 
>>>> that content delivery right now", reasons may include the uCDN has 
>>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing
>>>>>>>> -0
>>>>>>>> 0
>>>>>>>>
>>>>>>>> The present document proposes to clarify the CDNI Request 
>>>>>>>> Routing interface introduced in [I-D.ietf-cdni-framework] and
>>>>>>>> This part of the CDN interconnection framework the IETF has 
>>>>>>>> been referring to so far with the term "CDNI Request Routing" 
>>>>>>>> is just another routing, signaling and forwarding problem in a 
>>>>>>>> long series of the telecommunication history.  For example, one 
>>>>>>>> can draw a direct analogy between the IP/MPLS-TE framework and 
>>>>>>>> the CDN interconnection framework.
>>>>>>>>
>>>>>>>> ALL CDN interconnection interfaces in the scope of the CDNI 
>>>>>>>> IETF WG relies on the equivalent concept to IP prefix for CDN 
>>>>>>>> interconnection, named 'contentRequestScope'.  This highly 
>>>>>>>> useful and powerful concept SHALL be used to simplify the 
>>>>>>>> specification of ALL CDN interconnection interfaces, as well as 
>>>>>>>> to ensure performance and scalability in CDN interconnection.
>>>>>>>>
>>>>>>>> All these proposals can be smoothly integrated in the WG 
>>>>>>>> drafts, especially [I-D.ietf-cdni-framework] and 
>>>>>>>> https://datatracker.ietf.org/doc/draft-lelouedec-cdni-request-r
>>>>>>>> ou
>>>>>>>> ting
>>>>>>>>
>>>>>>>> http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing
>>>>>>>> -0
>>>>>>>> 0
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________________________
>>>>>>>> __ ____ ____________________________________________________
>>>>>>>>
>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si 
>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a 
>>>> que les pieces jointes. Les messages electroniques etant 
>>>> susceptibles d'alteration, France Telecom - Orange decline toute 
>>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>> ________________________________________________________________
>>>>>>> __ ____ ___________________________________________________
>>>>>>>
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si 
>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a 
>>>> que les pieces jointes. Les messages electroniques etant 
>>>> susceptibles d'alteration, France Telecom - Orange decline toute 
>>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>> If you have received this email in error, please notify the 
>>>>>>> sender and
>>>> delete this message and its attachments.
>>>> ___________________________________________________________________
>>>> __ _ ____ _______________________________________________
>>>>>> informations
>>>> detruire ainsi que les pieces jointes. Les messages electroniques 
>>>> etant susceptibles d'alteration, France Telecom - Orange decline 
>>>> toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>> If you have received this email in error, please notify the 
>>>>>> sender and
>>>> delete this message and its attachments.
>>>> ___________________________________________________________________
>>>> __ _ ____ _______________________________________________
>>>>>> informations
>>>>>> France Telecom - Orange decline toute responsabilite si ce 
>>>>>> message a
>>>>>> If you have received this email in error, please notify the 
>>>>>> sender and
>>>> delete this message and its attachments.
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>>
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Jul 2012 12:02:03 +0100

Allan,

On 25 Jul 2012, at 14:04, GUILLOU, Allan wrote:

> In *B* you still have a per session request to the dCDN.

Not necessarily. How I would like to see this work is that the protocol allows the dCDN's response to be scoped wider than the uCDN's request.

For example, a uCDN could request a redirection for a specific IP address and the dCDN could return a response scoped to an entire (set of) IP subnet(s) that is cacheable & reusable by the uCDN for a period of time to avoid the uCDN having to make a request to the dCDN for each redirection while leaving control with the dCDN to determine how widely to scope its requests (based on its knowledge of its footprint, load, etc) & how long it wants its responses to be cached for.

Ben

> If it is just to handle a problem in the dCDN, and that you consider that you realy need this kind of information, another method can be to add an "back pressure mechanism".
> 
>>>>>>>> sender

---

From: "Deventer, M.O. (Oskar) van" <[email-masked]>
Date: Thu, 26 Jul 2012 11:34:28 +0000

> Not necessarily. How I would like to see this work is that the protocol allows
> the dCDN's response to be scoped wider than the uCDN's request.
Also, the uCDN could bundle a set of associated requests. E.g. in de case of HAS, the contents of a complete manifest file could be resolved in a single request from the uCDN to the dCDN. 

Oskar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Thursday, 26 July, 2012 13:02
To: GUILLOU, Allan
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Allan,

Ben

>> Envoyé : mercredi 25 juillet 2012 14:36 À : 
>> <[email-masked]> <[email-masked]> Cc : 
>> Francois Le Faucheur (flefauch); GUILLOU, Allan; Scott Wainner 
>> (swainner); [email-masked] Objet : Re: [CDNi] I-D Action: 
>> *A* the uCDN uses the Footprint&Cap information (advertised by dCDN) 
>> to select a dCDN. The uCDN redirects to the selected dCDN and 
>> considers that he is done with request routing.
>> 
>> *B* the uCDN uses the Footprint&Cap information (advertised by dCDN) 
>> to select a dCDN candidate. The uCDN queries the dCDN before redirecting.
>> Querying dCDN optionally allows the uCDN to pick an alternate dCDN if 
>> the initially selected dCDN cannot handle the request.
>> 
>> *C* the uCDN queries multiple dCDNs on a per-request basis and 
>> selects dCDN based on their responses. In other words, the 
>> Footprint&Cap advertisement is performed via on-demand per-request queries.
>> 
>> 
>> I think:
>>      * Scott pointed out that fundamentatly both *A* and *B* have to 
>> deal with (typically transient) situations where uCDN thinks dCDN can 
>> take a request and dCDN actually cannot handle it. And pointed out 
>> that with *A* the transient period is dictated by the Footprint&Cap 
>> advertisement "update speed" while with *B* it is not.
>> support that. I think many people have been discussing that approach. 
>> If someone feels this is NOT to be supported by CDNI, do let us know.
>> 
>> deliverables. Are there people arguing this approach is to be 
>> supported in the initial deliverables?
>> 
>> Regarding *B*, I personally see it as quite useful and worth 
>> supporting in Phase 1 (possibly as an option).
>> dCDN-response) but it amounts to a web-services call out per request 
>> and buys you reliability of request routing, so I see that as a 
>> trade-off that some CDNs should be able to exercise.
>> 
>>      * I don't buy the latency argument because you end up with 2 
>> RTTs in both *A* and *B* (in normal situations where dCDN can handle 
>> the request) (i.e. user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user 
>> versus user--
>> request) or has the option to differently i.e. re-redirect at the 
>> cost of an extra RTT.
>>      * I don't buy the "loop free mechanism" argument. In *B*, it is 
>> easy to implement a loop detection and even loop prevention (if you 
>> want). In *A*, you have no loop prevention (other than the inherent 
>> HTTP/DNS max redirect/max CNAMEs) Other opinions on *B* are sought.
>> 
>> 
>> Cheers
>> 
>> Francois
>> 
>> 
>> ('recursive model' etc), Allan's comment are consistent with the 
>> messages that 
>>> de
>>> Envoyé : mercredi 25 juillet 2012 12:23 À : Scott Wainner; 
>> to send like an "ack" for each request, and if not the uCDN will try 
>> to find the second best dCDN and do the same thing.
>>> 
>> scalability problem. You will have to implement timers between 
>> request and ack, retransmission mechanism to make sure that request 
>> has not been lost, loop free mechanism, And all this may add latency 
>> on all requests and performances problems.
>>> 
>> this request will be lost. It is the same thing in IP network today 
>> we do not ask the routing protocol to change when there is saturation somewhere.
>> It is the responsibility of each ISP to choose another route to join 
>> this destination if he want to keep a good quality of service. If a 
>> dCDN is overloaded, it will stop announcing part of its footprint or 
>> uCDN may apply some policy to force choosing another dCDN.
>>> 
>> have the best reactivity, but it is exactly the same thing on the 
>> internet today. We can imagine that a poor dCDN which have saturation 
>> will be "black listed" by all the uCDN and the regulation will be done like this.
>>>> you call this a PULL approach). And I would like to allow the dCDN 
>>>> to be able to
>> say 'No'
>>>> alternate dCDN because its preferred dCDN (according to footprint / 
>>>> capabilities) is 'under-
>> performing'.
>>>> 
>>>> not
>>>> paid per request). In these cases, the dCDN needs to have the 
>>>> ability to deny delivery on a per-
>> request basis.
>>>>>> 
>>>> (possibly
>> in error).
>>>> logging interface may be used to exchange logs corresponding to 
>>>> this
>> problem.
>>>>>>> CDN to determine
>> if
>>>>>>> processes
>>>>>>> CDN interconnection.  And the description of both these 
>>>>>>> processes should be reviewed and clarified for the following reasons:
>>>>>>> 
>>>>>>>> CDNI Downstream Resource Identifier Signaling interface (CDNI 
>>>>>>>> DRIS
>> interface).
>>>>>>>> 
>>>> ___ ____ _______________________________________________
>>>>>> 
>>>> ___ ____ _______________________________________________
>>>>>> 
>> _____ _______________________________________________
>>> 
>>> messages
>>> France Telecom - Orange decline toute responsabilite si ce message a 
>>> ete

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 12:01:00 +0000

Hi Ben, All,

The specifications we have been producing for what we called the CDNI DRIS interface in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00, and that we are eager to share as soon as possible (again we are sorry but we are doing our best...), allows 
** to support for synchronous operations (i.e. triggered by the reception of a content request by the uCDN) as well as asynchronous operations
** to support for operations initiated by the uCDN (a.k.a. PULL operations) and by the dCDN (a.k.a. PUSH operations).

Ben, what you describe in your mail below corresponds exactly to the "synchronous PULL" operations in these specifications.
The idea is indeed to proceed that way to ensure maximal cacheability of information exchanged over that interface.

There is one key difference in our proposal as compared to your mail.
It is the fact that we use this "contentRequestScope" concept mentioned in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00.
This allows to generalize and to exploit fully the idea you mention, not only for "an entire (set of) IP subnet(s)", but for any class of content requests whatever the way it is structured.
Such a class of content requests could be indeed the set of content requests sent by end user agent whose IP addressed belong to the same "entire (set of) IP subnet(s)".
But such a class of content requests could also be the set of content requests having HTTP as protocol.
Or the class of contents having RTSP.
Or the class of contents having RTSP as protocol and a token.
Etc.
Etc.
As mentioned in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00, this full flexibility is what makes this "contentRequestScope" concept "highly useful and powerful concept to simplify the specification of ALL CDN interconnection interfaces, as well as to ensure performance and scalability in CDN interconnection".

There are also some other differences, but of lesser importance.
For example, about "how long it wants its responses to be cached for" (I quote your mail, Ben). 
We propose instead to associate a Boolean called "alwaysValid" that indicates whether the response is valid for any upcoming content request or just only once, typically for the content request for which the uCDN requested this response to the dCDN.
And it is up to the dCDN to send a message to invalidate any "alwaysValid" information provided earlier and stored by the uCDN (because these information are now outdated or just because the dCDN prefers to stop to be obliged to update them when needed).
The dCDN may also send exactly the same type of message at query time, when it cannot handle a content request the uCDN intends to redirect to him.
In any case this may be useful when some events impact the ability of the downstream CDNs to accept delegated content requests. 
This is to reduce the "bind window" due to routing convergence we discussed earlier by mail (really useful only when the routing/capability information re-convergence is too long).

But I stop here, 
Otherwise I should rather just make a copy paste of our proposed specifications in a mail...
We look forward to discuss this next week.

Best regards,

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Niven-Jenkins
Envoyé : jeudi 26 juillet 2012 13:02
À : GUILLOU, Allan
Cc : [email-masked]
Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt

Allan,

Ben

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 11:44:27 +0000

Dear François, all,

I have another comment about the mail from François below.
About the modes A and B and about latency.

I don't see why the CDNI iterative and (semi- and full-) recursive request redirection modes should not be compatible a priori with both the modes A and B described below.
(I mean everything is possible, even if some combinations do not necessarily match all the requirements of every real deployment one may envision).

For example, 
Mode A can be compatible with the CDNI iterative request redirection mode (as well as with what we call the semi-recursive mode in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00) :
In normal situations where dCDN can handle the request,
The uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN
The uCDN uses the information provided by this dCDN via the CDNI Request Routing/Redirection interface (especially the distinguished CDN-domain to use) to redirect the client request to the dCDN.
Then the client request (which has been redirected to the request routing system of the dCDN) has to redirect afterwards to one delivery node of the dCDN.
In this sub-mode, there are indeed 2 RTTs (user-->uCDN, uCDN-->user, user-->dCDN, dCDN-->user).

But Mode B can also be compatible with what we call the CDNI full-recursive request redirection mode in draft http://tools.ietf.org/html/draft-lelouedec-cdni-request-routing-00 :
In normal situations where dCDN can handle the request,
The uCDN uses the Footprint&Cap information (advertised by dCDN) to select a dCDN
The uCDN uses the information provided by this dCDN via the CDNI Request Routing/Redirection interface to redirect the client request to the dCDN. 
And in this case the information provided by the dCDN via this CDNI Request Routing/Redirection interface points in fact directly to a delivery node within the dCDN.
(Or one could maybe also even imagine specific cases where all the delivery nodes of the dCDN have the same IP anycast address, etc. (?))
Anyway the client request is redirected here directly to a delivery node of the dCDN.
In this case, there is only 1 RTT with Mode A (user-->uCDN, uCDN-->user).

Yannick Le Louédec.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francois Le Faucheur (flefauch)
Envoyé : mercredi 25 juillet 2012 14:36
À : BERTRAND Gilles RD-CORE
Cc : [email-masked]
Objet : Re: [CDNi] I-D Action: draft-lelouedec-cdni-request-routing-00.txt

All,

I think:

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 27 Jul 2012 12:38:19 +0000

Yannick and all,

Regarding the latency point:
"
> In this case, there is only 1 RTT with Mode A (user-->uCDN, uCDN-->user).
"
I think you meant to say "In this case, there is only 1 RTT with Mode B (user-->uCDN, uCDN-->user)."
In any case, with mode B I still see 2 RTTs involved in the overall request routing redirection process: (user-->uCDN, uCDN-->dCDN, dCDN-->uCDN, uCDN-->user). Only one of those is a slightly different RTT.

Regarding your other points:
 "
I don't see why the CDNI iterative and (semi- and full-) recursive request redirection modes should not be compatible a priori with both the modes A and B described below":
"
I don't quite understand what you mean. But I don't think there is any issue here. So let's recap:

As per the current CDNI documents (in particular cdni-framework) we have defined :
	* recursive CDNI request routing redirection for the case where the uCDN queries the dCDN (using the RRI/Redirection interface) before redirecting
	* iterative CDNI request routing redirection for the case where the uCDN does not query the dCDN (using the RRI/Redirection interface) before redirecting.
(in cdni-framework it currently says "recursive/iterative request routing" instead of "recursive/iterative request routing redirection" because it has not yet been fully brought in line with the latest vocabulary, but that does not matter)
Bottom line is:
	* The uCDN can select a dCDN (possibly using the RRI/Footprint&Cap interface) and then decide to not use the RRI/Redirection interface. This is a case of iterative CDNI request routing redirection. This is mode A below.
	* The uCDN can select a dCDN (possibly using the RRI/Footprint&Cap interface) and then query that dCDN using the RRI/Redirection interface. This is a case of recursive CDN request routing redirection. This is mode B below.
	* The uCDN can query multiple dCDNs using the RRI/Redirection interface and then select a dCDN (possibly also using some of the RRI/Footprint&Cap interface). This is a case of recursive CDN request routing redirection. This is mode C below. As pointed by Ray and Scott, the same RRI/Redirection interface should be usable for both B and C.

Do you still have any issue or concerns with the above statements?

As per the current CDNI documents (in particular cdni-framework) we have defined that, in the case of recursive request routing redirection, there are multiple variations in how the dCDN may answer the query (e.g. it may point to the final Surrogate, it may point to the dCDN Request Router, it may point to a regional/specialised Request Router, it may point to a set of Surrogates identifies by an Anycast address, it may point to a 3rd CDN request router…). Because there is such a continuum in how recursive request routing redirection can be used by the dCDN, I am not sure it is worth trying to further define finer-grain terminology such as "full/partial" recursive redirection. I am not opposed to it as long as (i) there is value in doing it and (ii) it can be done unambiguously. I am still wondering about (i). What is the value of defining a specific term for "full" vs "partial" (as opposed to explicitly sating the continuum of options in case of recursive).

Cheers

Francois