Subject: [CDNi] New Text for Framework on URI Rewriting

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Thu, 1 Aug 2013 20:41:05 +0000

Hi everyone,

Based on comments this week regarding the URI Rewriting section of the CDNI Framework document I have put together a revised section which aims to touch on the key points more clearly. Please share your feedback on the text below. If it is suitable, we can incorporate into the next revision of draft-ietf-cdni-framework.

Thanks,
Matt

Metadata & URI Rewriting

When using HTTP redirection, content URIs will be rewritten between uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten multiple times between uCDN and dCDN. URI rewriting poses a special challenge for the implementation of some CDNI interfaces.

Consider the simple case: a single uCDN and dCDN. This section refers to the URI requested of the uCDN as the "uCDN URI" and the URI requested of the dCDN as the "dCDN URI". 

Any CDNI interface which relies on content URIs must state explicitly which URI is to be used - the dCDN URI or the uCDN URI. For example, in the case of the Logging Interface, each log message may reference a content URI. In the case of the Metadata Interface, the dCDN must query for the uCDN for metadata based on a content URI.

For all CDNI interfaces, the dCDN should translate any dCDN URIs to uCDN URIs before interacting with the uCDN. For logging, this approach requires the dCDN to translate any dCDN URIs in its log messages into uCDN URIs. For metadata, this approach requires the dCDN to translate any dCDN URIs into uCDN URIs before querying the uCDN for metadata. 

In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and therefore is capable of translating from uCDN URI to dCDN URI and vice versa. In iterative mode, an out-of-band agreement instructs the uCDN and dCDN how to translate from uCDN URI to dCDN URI and vice versa. In either mode, the dCDN is capable of translating dCDN URIs into uCDN URIs before interacting with the uCDN.

Note that even in the DNS redirection case, some URI rewriting is still necessary. For example, any metadata which references the immediately upstream CDN (such as content acquisition metadata) should be rewritten as the metadata is passed between CDNs. However, given that DNS redirection does not change the content URI, many of the concerns addressed above with HTTP redirection do not apply.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 2 Aug 2013 13:27:05 +0000

Matt and all,

I am not comfortable with a few of the statements in the draft text below. I think some ambiguity lingered in there because we need to be more precise in the modelling of the "URI plans" and recognise that there are actually 3 URI plans, and not just 2. Specifically I think there is:
	* a "u-URI" used between user-agent and uCDN. A u-URI is understood by uCDN
	* a "ud-URI" understood by both uCDN and dCDN
	* a "d-URI" used between user-agent and dCDN Surrogate. A d-URI  is understood by dCDN.
Once we define the three schemes the whole discussion becomes quite simple and very un-ambiguous I think: all CDNI interfaces have to operate using ud-URIs (for this particular pair of uCDN and dCDN) in all situations. I believe this statement holds for any request routing method (HTTP and DNS) and for any redirection method (iterative and recursive) and for handling of transitive situation.

Obviously, the 3 URI schemes are not always different, but they may be different.
Here are a few examples scenarios:

1) say we use DNS redirection.
u-URI=ud-URI=d-URI  (eg =csp1.ucdn.com)

2) say we use HTTP redirection in iterative mode, and dCDN sticks to the ud-URI scheme
 u-URI!=ud-URI=d-URI
(eg u-URI=csp1.ucdn.com)
(eg ud-URI=d-URI=ucdn.dcdn.com/csp1)

3) say we use HTTP redirection in recursive mode, and dCDN wants to use his own scheme
 u-URI!=ud-URI!=d-URI
(eg u-URI=csp1.ucdn.com used between user-agent and uCDN)
(eg ud-URI=ucdn.dcdn.com/csp1  used in Redirection request message)
(eg d-URI=dcdn.com/ucdn1/csp1 used in Redirection response message,  between user-agent and dCDN, and in the raw logs generated by the dCDN Surrogate)

Note that I used different combinations of URI plans between recursive and iterative in the examples above, but there is no correlation between URI scheme combination and redirection mode. Any URI scheme combination is possible with any redirection mode.

In any situation, the CDNI interfaces always need to use the ud-URI scheme (for that particular pair of uCDN and dCDN). 

Does this sound right?

Assuming this is right, the framework text could look something like this (feel free to improve):

"
Metadata & URI Rewriting

When using HTTP redirection, content URIs will be rewritten between uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop between uCDN and dCDN. URI rewriting needs to be taken into account for the implementation of some CDNI interfaces.

Consider the simple case: a single uCDN and dCDN. This section refers:
	* to a URI requested of the uCDN as a "u-URI"
	* to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-URI"
	* to a URI requested of the dCDN as a "dCDN URI"

In a given deployment situation, the ud-URI plan may be different or the same as the u-URI plan, and the d-URI plan may be different or the same as the ud-URI plan. Any combination is possible. For example, where DNS redirection is used the u-URI, ud-URI and d-URI plans will all be the same. As another example, where HTTP request routing in iterative mode is used, the uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request routing system may redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan.

Most CDNI interfaces involve content URIs. For example, in the case of the CDNI Logging interface, each log record may reference a content URI. In the case of the CDNI Metadata interface, the dCDN must query the uCDN for metadata based on a content URI. 

Any CDNI interface between an uCDN and a dCDN which relies on content URIs needs to convey URIs in that interface in the ud-URI plan for the given pair of CDNs. 

When the dCDN is transfering CDNI information to the uCDN including a content URI, it is the responsibility of the dCDN to use the ud-URI plan and, if required, to map back a d-URI into a ud-URI. For example, if the dCDN uses a d-URI plan that is different to the ud-URI plan, the dCDN needs to map back the d-URIs into ud-URIs for inclusion in the CDNI Logging interface.

When the uCDN is transfering CDNI information to the dCDN including a content URI, it is the responsibility of the dCDN to use the ud-URI plan when conveying content URIs. For example, if the uCDN uses a d-URI plan that is different from the ud-URI plan, it is the responsibility of the uCDN to ensure content URIs used in the CDNI Metadata interface are expressed in the ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from the ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in content requests with metadata obtained from the uCDN expressed in the ud-URI plan. 

Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 acting as the transit CDN and CDN3 acting as the dCDN. This section refers:
	* to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a ud-URI-ut
	* to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a ud-URI-td

In a given deployment situation the ud-URI-td plan may be different or the same as the ud-URI-ut plan. For example, when DNS request routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same. When HTTP request routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be different.

When, in his role of transit CDN, CDN2 turns information obtained on a CDNI interface from the dCDN (respectively uCDN) into information transmitted to the uCDN (respectively dCDN) on the corresponding CDNI interface, it is the responsibility of the transit CDN to convert content URIs from the ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan to the ud-URI-td plan).

For example, when the transit CDN receives CDNI logging records from the dCDN with content URIs expressed in the ud-URI-td plan, and when the transit CDN includes the corresponding CDNI logging records for transmission to the uCDN over the CDNI Logging interface, the transit CDN needs to map the content URIs expressed in the ud-URI-td plan into URIs expressed into the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata information from the uCDN with content URIs expressed in the ud-URI-ut plan, and when the transit CDN includes the corresponfing CDNI metadata information for transmission to the dCDN over the CDNI Metadata interface, the transit CDN needs to map the content URIs expressed in the ud-URI-ut plan into content URIs expressed in the ud-URI-td plan. Regarding metadata information, note that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN is also likely to have to perform rewriting on some other metadata information. For example, any metadata which references the immediately upstream CDN (such as content acquisition metadata) should be rewritten as the metadata is passed between CDNs.
"

Francois

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 3 Aug 2013 16:12:45 +0100

Francois, Matt, Colleagues,

I think there is an important distinction between a CDN being told a particular transformation to apply and applying it and a CDN actually 'understanding' a particular URI.

For example, in the case of iterative request routing a dCDN may 'say' to a uCDN "here is the transformation I want you to apply to URIs in order to redirect them to me". There is no requirement for the uCDN to actually understand what it is doing and without other knowledge it is not safe IMO for the uCDN to attempt to infer meaning from the transformation, it should just blindly apply it.

I think this is an important distinction/point because looseness here will lead IMO to people making incorrect assumptions about what a uCDN or dCDN may "know"  and incorrect design decision that couple uCDNs and dCDNs more than is necessary.

Ben

On 2 Aug 2013, at 14:27, Francois Le Faucheur (flefauch) wrote:

> For example, when the transit CDN receives CDNI logging records from the dCDN with content URIs expressed in the ud-URI-td plan, and when the transit CDN includes the corresponding CDNI logging records for transmission to the uCDN over the CDNI Logging interface, the transit CDN needs to map the content URIs expressed in the ud-URI-td plan into URIs expressed into the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata information from the uCDN with content URIs expressed in the ud-URI-ut plan, and when the transit CDN includes the corresponfing CDNI metadata information for transmission to the dCDN over the CDNI Metadata interface, the transit CDN needs to map the content URIs expressed in the ud-URI-ut plan into content URIs expressed in the ud-URI-td plan. Regarding metadata information, note that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN is also likely to have to perform rewriting on some other metadata information. 
> For example, any metadata which references the immediately upstream CDN (such as content acquisition metadata) should be rewritten as the metadata is passed between CDNs.
> "
> 
> Francois
>

---

From: Scott Wainner <[email-masked]>
Date: Sun, 04 Aug 2013 23:31:41 -0400

Ben

     I think I agree with you, but using a different logical point of 
view.  I suspect the uCDN is the entity that 'knows' the URL that is 
created by the CSP.  There are likely to be proprietary attributes that 
only the uCDN and CSP understand.  With that said, the uCDN will need to 
re-write the URL attributes into a CDNI form that any dCDN could 
understand provided it supports the attributes.

     For example, the CSP might use a query parameter "algorithm=sha256" 
which is understood by the uCDN.  Of course, there are likely no dCDNs 
that would understand this query parameter.  It is incumbent upon the 
uCDN to map the "algorithm=" parameter to the CDNI "HF=" parameter.  It 
is the uCDN that knows this mapping.  All we need from the dCDN is to 
know that it supports "HF=sha256" which is a option from the URL Signing 
capabilities.

     The same can be said for any other query parameters.  It would be 
the uCDN that knows if the CSP's "algorithm" parameter is mandatory or 
optional.  The uCDN just needs to know if there is a dCDN that supports 
the mandatory attributes using the CDNI methods for conveying the 
parameters.

Scott

On 8/3/13 11:12 AM, Ben Niven-Jenkins wrote:
> .

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 5 Aug 2013 08:14:58 +0000

Ben,

> I think there is an important distinction between a CDN being told a particular transformation to apply and applying it and a CDN actually 'understanding' a particular URI.

Agreed.

> For example, in the case of iterative request routing a dCDN may 'say' to a uCDN "here is the transformation I want you to apply to URIs in order to redirect them to me". There is no requirement fo…

Right. I chose the wrong words in the informal descriptive text I used at the top of the message (i.e when I said " a ud-URI understood by both uCDN and dCDN"). 
But I think the proposed draft text was more carefully chosen and addresses your point. It says:
"
This section refers:
...
	* to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-URI"
…
"
So in your example, the "ud-URI" is the one applied by the uCDN in accordance with "the transformation I want you to apply to URIs in order to redirect them to me" and this does not have to be "understood" by the uCDN.

If you ignore the casual informal descriptive text at the beginning of my earlier message, are you comfortable with the draft text?

Thanks

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 5 Aug 2013 08:39:33 +0000

Folks,

Someone suggested privately that perhaps we are trying to provide too much details here, and that we may be finally blurring the point that is not that complicated. So I'd like to offer an alternative text that aims at capturing the point accurately but succinctly. So you'll find below:
	* a Concise Option (new)
	* a Verbose Option (same as in my earlier message with minor editorial enhancements)
Let us know which you favor (or if you have alternative proposals to offer).

Francois

Concise Option
===========
"
Metadata & URI Rewriting

When using HTTP redirection, content URIs will be rewritten when redirection takes place within an uCDN, when redirection takes place from an uCDN to a dCDN and when redirection takes place within a dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop between the uCDN and the dCDN serving the request. URI rewriting needs to be taken into account for the implementation of some CDNI interfaces.

Consider the simple case: a single uCDN and dCDN. This section refers:
	* to a URI requested of the uCDN as a "u-URI"
	* to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-URI"
	* to a URI requested of the dCDN as a "d-URI"

It is the responsibility of the uCDN (respectively dCDN) to ensure that a content URI communicated to the dCDN (respectively uCDN) are always expressed in the ud-URI plan for the particular dCDN (respectively uCDN). When the content URI has been derived from information expressing content URIs in a different plan, the uCDN (respectively dCDN) needs to map the content URI into the ud-URI plan (for the given pair of uCDN and dCDN) for conveying it as a content URI in a CDNI interface.
"

Verbose Option:
============

"
Metadata & URI Rewriting

When using HTTP redirection, content URIs will be rewritten when redirection takes place within an uCDN, when redirection takes place from an uCDN to a dCDN and when redirection takes place within a dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop between the uCDN and the dCDN serving the request. URI rewriting needs to be taken into account for the implementation of some CDNI interfaces.

Consider the simple case: a single uCDN and dCDN. This section refers:
	* to a URI requested of the uCDN as a "u-URI"
	* to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-URI"
	* to a URI requested of the dCDN as a "d-URI"

---

From: Scott Wainner <[email-masked]>
Date: Mon, 05 Aug 2013 06:43:34 -0400

I was following along the "Concise Option" until the last paragraph.

Alternative suggested in line ...

> Let us know which you favor (or if you have alternative proposals to offer).
It is the responsibility of the uCDN to ensure that a content URI 
communicated to the dCDN is always expressed in the ud-URI plan. When a 
uCDN receives a content URI request conveying information that uses a 
different plan, the uCDN must map the content URI into the ud-URI plan 
in accordance with the capabilities of a chosen dCDN.  The CDNI 
interfaces RI, MI, and LI must reference the ud-URI for purposes of 
request routing, metadata, and logging, respectively.

---

From: Scott Wainner <[email-masked]>
Date: Mon, 05 Aug 2013 16:55:46 -0400

Francois,

     May I suggest we re-write the paragraphs as follows:

Metadata & URI Rewriting
------------------------

When using HTTP redirection, content URIs may be rewritten when redirection takes place within an uCDN, from an uCDN to a dCDN, and within the dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop e.g between the uCDN and the dCDN acting as the transit CDN, and between the transit CDN and the dCDN serving the request. The content URI used between a specific pair of uCDN and dCDN becomes a common handle that can be referred to without ambiguity by both CDNs of the specific pair of uCDN and dCDN in all their inter-CDN communications. The handle allows the uCDN and dCDN to correlate information exchanged in CDNI interfaces in both the downstream direction (e.g. when using the MI) and the upstream direction (e.g. when using the LI).

Consider the simple case: a single uCDN and dCDN pair using HTTP redirection.  This section defines the content URIs as follows:

    "u-URI" represents a content URI in a request presented to the uCDN
    "ud-URI" is a content URI acting as the common handle across uCDN and dCDN for requests redirected by the uCDN to a specific dCDN
    "d-URI" represents a content URI in a request made within the delegate dCDN

The "ud-URI" effectively becomes the handle which the uCDN and dCDN pair correlate all CDNI information. In particular, for a given pair of CDNs executing the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI handle for all MI message exchanges, while the dCDN needs to map the d-URI to the ud-URI handle for all LI message exchanges.

In the case of a cascaded CDNs, the transit CDN will re-write the content URI when redirecting to the dCDN, thereby establishing a new handle between the transit CDN and the dCDN, that is different from the handle between the uCDN and transit CDN. It is the responsibility of the transit CDN to manage its mapping across handles so the right handle for the specific pair of CDNs is always used in its CDNI communication.

In summary, all CDNI interfaces between a given pair of CDNs need to always use the "ud-URI" handle for that specific CDN pair, as their content URI reference.

Scott Wainner

On 8/5/13 6:43 AM, Scott Wainner wrote:
>> Someone suggested privately that perhaps we are trying to provide too 
>> much details here, and that we may be finally blurring the point that 
>> is not that complicated. So I'd like to offer an alternative text 
>> that aims at capturing the point accurately but succinctly. So you'll 
>> find below:
>>     * a Concise Option (new)
>> When using HTTP redirection, content URIs will be rewritten when 
>> redirection takes place within an uCDN, when redirection takes place 
>> from an uCDN to a dCDN and when redirection takes place within a 
>> dCDN. In the case of cascaded CDNs, content URIs may be rewritten at 
>> every CDN hop between the uCDN and the dCDN serving the request. URI 
>> rewriting needs to be taken into account for the implementation of 
>> some CDNI interfaces.
>>
>> In a given deployment situation, the ud-URI plan may be different or 
>> the same as the u-URI plan, and the d-URI plan may be different or 
>> the same as the ud-URI plan. Any combination is possible. For 
>> example, where DNS redirection is used the u-URI, ud-URI and d-URI 
>> plans will all be the same. As another example, where HTTP request 
>> routing in iterative mode is used, the uCDN will redirect the 
>> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in 
>> a plan that will be different to the u-URI plan (e.g. 
>> csp.ucdn.com/xyz), and in turn the dCDN request routing system may 
>> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. 
>> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan.
>>
>> Most CDNI interfaces involve content URIs. For example, in the case 
>> of the CDNI Logging interface, each log record may reference a 
>> content URI. In the case of the CDNI Metadata interface, the dCDN 
>> must query the uCDN for metadata based on a content URI.
>>
>> It is the responsibility of the uCDN (respectively dCDN) to ensure 
>> that a content URI communicated to the dCDN (respectively uCDN) are 
>> always expressed in the ud-URI plan for the particular dCDN 
>> (respectively uCDN). When the content URI has been derived from 
>> information expressing content URIs in a different plan, the uCDN 
>> (respectively dCDN) needs to map the content URI into the ud-URI plan 
>> (for the given pair of uCDN and dCDN) for conveying it as a content 
>> URI in a CDNI interface.
>> "
> communicated to the dCDN is always expressed in the ud-URI plan. When 
> a uCDN receives a content URI request conveying information that uses 
> a different plan, the uCDN must map the content URI into the ud-URI 
> plan in accordance with the capabilities of a chosen dCDN.  The CDNI 
>> When using HTTP redirection, content URIs will be rewritten when 
>> redirection takes place within an uCDN, when redirection takes place 
>> from an uCDN to a dCDN and when redirection takes place within a 
>> dCDN. In the case of cascaded CDNs, content URIs may be rewritten at 
>> every CDN hop between the uCDN and the dCDN serving the request. URI 
>> rewriting needs to be taken into account for the implementation of 
>> some CDNI interfaces.
>>
>> In a given deployment situation, the ud-URI plan may be different or 
>> the same as the u-URI plan, and the d-URI plan may be different or 
>> the same as the ud-URI plan. Any combination is possible. For 
>> example, where DNS redirection is used the u-URI, ud-URI and d-URI 
>> plans will all be the same. As another example, where HTTP request 
>> routing in iterative mode is used, the uCDN will redirect the 
>> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in 
>> a plan that will be different to the u-URI plan (e.g. 
>> csp.ucdn.com/xyz), and in turn the dCDN request routing system may 
>> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. 
>> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan.
>>
>> Most CDNI interfaces involve content URIs. For example, in the case 
>> of the CDNI Logging interface, each log record may reference a 
>> content URI. In the case of the CDNI Metadata interface, the dCDN 
>> must query the uCDN for metadata based on a content URI.
>>
>> Any CDNI interface between an uCDN and a dCDN which relies on content 
>> URIs needs to convey URIs in that interface in the ud-URI plan for 
>> the given pair of CDNs.
>>
>> When the dCDN is transfering CDNI information to the uCDN including a 
>> content URI, it is the responsibility of the dCDN to use the ud-URI 
>> plan and, if required, to map back a d-URI into a ud-URI. For 
>> example, if the dCDN uses a d-URI plan that is different to the 
>> ud-URI plan, the dCDN needs to map back the d-URIs into ud-URIs for 
>> inclusion in the CDNI Logging interface.
>>
>> When the uCDN is transfering CDNI information to the dCDN including a 
>> content URI, it is the responsibility of the dCDN to use the ud-URI 
>> plan when conveying content URIs. For example, if the uCDN uses a 
>> d-URI plan that is different from the ud-URI plan, it is the 
>> responsibility of the uCDN to ensure content URIs used in the CDNI 
>> Metadata interface are expressed in the ud-URI plan. Also, if the 
>> dCDN uses a d-URI plan that is different from the ud-URI plan, it is 
>> the responsibility of the dCDN to correlate d-URIs in content 
>> requests with metadata obtained from the uCDN expressed in the ud-URI 
>> plan.
>>
>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 
>> acting as the transit CDN and CDN3 acting as the dCDN. This section 
>> refers:
>> In a given deployment situation the ud-URI-td plan may be different 
>> or the same as the ud-URI-ut plan. For example, when DNS request 
>> routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut 
>> plan will be the same. When HTTP request routing is used at every CDN 
>> hop, the ud-URI-td plan and ud-URI-ut plan will be different.
>>
>> When, in his role of transit CDN, CDN2 turns information obtained on 
>> a CDNI interface from the dCDN (respectively uCDN) into information 
>> transmitted to the uCDN (respectively dCDN) on the corresponding CDNI 
>> interface, it is the responsibility of the transit CDN to convert 
>> content URIs from the ud-URI-td plan to the ud-URI-ut plan 
>> (respectively from the ud-URI-ut plan to the ud-URI-td plan).
>>
>> For example, when the transit CDN receives CDNI logging records from 
>> the dCDN with content URIs expressed in the ud-URI-td plan, and when 
>> the transit CDN includes the corresponding CDNI logging records for 
>> transmission to the uCDN over the CDNI Logging interface, the transit 
>> CDN needs to map the content URIs expressed in the ud-URI-td plan 
>> into URIs expressed into the ud-URI-ut plan. Similarly, when the 
>> transit CDN receives CDNI metadata information from the uCDN with 
>> content URIs expressed in the ud-URI-ut plan, and when the transit 
>> CDN includes the corresponfing CDNI metadata information for 
>> transmission to the dCDN over the CDNI Metadata interface, the 
>> transit CDN needs to map the content URIs expressed in the ud-URI-ut 
>> plan into content URIs expressed in the ud-URI-td plan. Regarding 
>> metadata information, note that (even when the ud-URI-ut plan and 
>> ud-URI-td plan are the same) the transit CDN is also likely to have 
>> to perform rewriting on some other metadata information
> .
>> For example, any metadata which references the immediately upstream 
>> CDN (such as content acquisition metadata) should be rewritten as the 
>> metadata is passed between CDNs.
>> "
>>
>>
>>
>>> "
>>> Metadata & URI Rewriting
>>>
>>> When using HTTP redirection, content URIs will be rewritten between 
>>> uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be 
>>> rewritten at every CDN hop between uCDN and dCDN. URI rewriting 
>>> needs to be taken into account for the implementation of some CDNI 
>>> interfaces.
>>>
>>> In a given deployment situation, the ud-URI plan may be different or 
>>> the same as the u-URI plan, and the d-URI plan may be different or 
>>> the same as the ud-URI plan. Any combination is possible. For 
>>> example, where DNS redirection is used the u-URI, ud-URI and d-URI 
>>> plans will all be the same. As another example, where HTTP request 
>>> routing in iterative mode is used, the uCDN will redirect the 
>>> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) 
>>> in a plan that will be different to the u-URI plan (e.g. 
>>> csp.ucdn.com/xyz), and in turn the dCDN request routing system may 
>>> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. 
>>> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan.
>>>
>>> Most CDNI interfaces involve content URIs. For example, in the case 
>>> of the CDNI Logging interface, each log record may reference a 
>>> content URI. In the case of the CDNI Metadata interface, the dCDN 
>>> must query the uCDN for metadata based on a content URI.
>>>
>>> Any CDNI interface between an uCDN and a dCDN which relies on 
>>> content URIs needs to convey URIs in that interface in the ud-URI 
>>> plan for the given pair of CDNs.
>>>
>>> When the dCDN is transfering CDNI information to the uCDN including 
>>> a content URI, it is the responsibility of the dCDN to use the 
>>> ud-URI plan and, if required, to map back a d-URI into a ud-URI. For 
>>> example, if the dCDN uses a d-URI plan that is different to the 
>>> ud-URI plan, the dCDN needs to map back the d-URIs into ud-URIs for 
>>> inclusion in the CDNI Logging interface.
>>>
>>> When the uCDN is transfering CDNI information to the dCDN including 
>>> a content URI, it is the responsibility of the dCDN to use the 
>>> ud-URI plan when conveying content URIs. For example, if the uCDN 
>>> uses a d-URI plan that is different from the ud-URI plan, it is the 
>>> responsibility of the uCDN to ensure content URIs used in the CDNI 
>>> Metadata interface are expressed in the ud-URI plan. Also, if the 
>>> dCDN uses a d-URI plan that is different from the ud-URI plan, it is 
>>> the responsibility of the dCDN to correlate d-URIs in content 
>>> requests with metadata obtained from the uCDN expressed in the 
>>> ud-URI plan.
>>>
>>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, 
>>> CDN2 acting as the transit CDN and CDN3 acting as the dCDN. This 
>>> section refers:
>>> In a given deployment situation the ud-URI-td plan may be different 
>>> or the same as the ud-URI-ut plan. For example, when DNS request 
>>> routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut 
>>> plan will be the same. When HTTP request routing is used at every 
>>> CDN hop, the ud-URI-td plan and ud-URI-ut plan will be different.
>>>
>>> When, in his role of transit CDN, CDN2 turns information obtained on 
>>> a CDNI interface from the dCDN (respectively uCDN) into information 
>>> transmitted to the uCDN (respectively dCDN) on the corresponding 
>>> CDNI interface, it is the responsibility of the transit CDN to 
>>> convert content URIs from the ud-URI-td plan to the ud-URI-ut plan 
>>> (respectively from the ud-URI-ut plan to the ud-URI-td plan).
>>>
>>> For example, when the transit CDN receives CDNI logging records from 
>>> the dCDN with content URIs expressed in the ud-URI-td plan, and when 
>>> the transit CDN includes the corresponding CDNI logging records for 
>>> transmission to the uCDN over the CDNI Logging interface, the 
>>> transit CDN needs to map the content URIs expressed in the ud-URI-td 
>>> plan into URIs expressed into the ud-URI-ut plan. Similarly, when 
>>> the transit CDN receives CDNI metadata information from the uCDN 
>>> with content URIs expressed in the ud-URI-ut plan, and when the 
>>> transit CDN includes the corresponfing CDNI metadata information for 
>>> transmission to the dCDN over the CDNI Metadata interface, the 
>>> transit CDN needs to map the content URIs expressed in the ud-URI-ut 
>>> plan into content URIs expressed in the ud-URI-td plan. Regarding 
>>> metadata information, note that (even when the ud-URI-ut plan and 
>>> ud-URI-td plan are the same) the transit CDN is also likely to have 
>>> to perform rewriting on some other metadata informatio
> n
>>   .
>>> For example, any metadata which references the immediately upstream 
>>> CDN (such as content acquisition metadata) should be rewritten as 
>>> the metadata is passed between CDNs.
>>> "
>>>
>>> Francois
>>>
>>>> Based on comments this week regarding the URI Rewriting section of 
>>>> the CDNI Framework document I have put together a revised section 
>>>> which aims to touch on the key points more clearly. Please share 
>>>> your feedback on the text below. If it is suitable, we can 
>>>> incorporate into the next revision of draft-ietf-cdni-framework.
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> Metadata & URI Rewriting
>>>>
>>>> When using HTTP redirection, content URIs will be rewritten between 
>>>> uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be 
>>>> rewritten multiple times between uCDN and dCDN. URI rewriting poses 
>>>> a special challenge for the implementation of some CDNI interfaces.
>>>
>>>
>>>> Consider the simple case: a single uCDN and dCDN. This section 
>>>> refers to the URI requested of the uCDN as the "uCDN URI" and the 
>>>> URI requested of the dCDN as the "dCDN URI".
>>>>
>>>> Any CDNI interface which relies on content URIs must state 
>>>> explicitly which URI is to be used - the dCDN URI or the uCDN URI. 
>>>> For example, in the case of the Logging Interface, each log message 
>>>> may reference a content URI. In the case of the Metadata Interface, 
>>>> the dCDN must query for the uCDN for metadata based on a content URI.
>>>>
>>>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to 
>>>> uCDN URIs before interacting with the uCDN. For logging, this 
>>>> approach requires the dCDN to translate any dCDN URIs in its log 
>>>> messages into uCDN URIs. For metadata, this approach requires the 
>>>> dCDN to translate any dCDN URIs into uCDN URIs before querying the 
>>>> uCDN for metadata.
>>>>
>>>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI 
>>>> and therefore is capable of translating from uCDN URI to dCDN URI 
>>>> and vice versa. In iterative mode, an out-of-band agreement 
>>>> instructs the uCDN and dCDN how to translate from uCDN URI to dCDN 
>>>> URI and vice versa. In either mode, the dCDN is capable of 
>>>> translating dCDN URIs into uCDN URIs before interacting with the uCDN.
>>>>
>>>> Note that even in the DNS redirection case, some URI rewriting is 
>>>> still necessary. For example, any metadata which references the 
>>>> immediately upstream CDN (such as content acquisition metadata) 
>>>> should be rewritten as the metadata is passed between CDNs. 
>>>> However, given that DNS redirection does not change the content 
>>>> URI, many of the concerns addressed above with HTTP redirection do 
>>>> not apply.
>>>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 6 Aug 2013 12:20:26 +0000

Hi Scott,
That can work for me.
Opnion anyone?
Francois

On 5 Aug 2013, at 22:55, Scott Wainner <[email-masked]> wrote:

>> It is the responsibility of the uCDN to ensure that a content URI communicated to the dCDN is always expressed in the ud-URI plan. When a uCDN receives a content URI request conveying information that uses a different plan, the uCDN must map the content URI into the ud-URI plan in accordance with the capabilities of a chosen dCDN.  The CDNI interfaces RI, MI, and LI must reference the ud-URI for purposes of request routing, metadata, and logging, respectively.
>>> 
>>> 
>>> Verbose Option:
>>> ============
>>> 
>>> "
>>> Metadata & URI Rewriting
>>> 
>>>> For example, when the transit CDN receives CDNI logging records from the dCDN with content URIs expressed in the ud-URI-td plan, and when the transit CDN includes the corresponding CDNI logging records for transmission to the uCDN over the CDNI Logging interface, the transit CDN needs to map the content URIs expressed in the ud-URI-td plan into URIs expressed into the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata information from the uCDN with content URIs expressed in the ud-URI-ut plan, and when the transit CDN includes the corresponfing CDNI metadata information for transmission to the dCDN over the CDNI Metadata interface, the transit CDN needs to map the content URIs expressed in the ud-URI-ut plan into content URIs expressed in the ud-URI-td plan. Regarding metadata information, note that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN is also likely to have to perform rewriting on some other metadata informatio
>> n
>>>  .

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Tue, 6 Aug 2013 17:12:17 +0000

I think the text below captures the idea nicely.

However, is there general consensus that using the ud-URI as a handle is a good idea? In practice, this solution complicates the metadata interface implementation by requiring the uCDN to expose different metadata to each dCDN (tailored for the specific ud-URI shared between them). It also creates coupling between request routing and metadata. Is that something we can live with?

An alternate solution is to use a common handle for content throughout all cascaded CDNs. This happens automatically in the DNS case - all CDNs use the original URI. Logging and metadata both reference the original URI. We could try to bringing HTTP case in line with the DNS case by guaranteeing that any URI (u-URI, ud-URI, or d-URI) can always be translated back to the original URI.

Thanks,
Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Tuesday, August 06, 2013 8:20 AM
To: Scott Wainner (swainner)
Cc: [email-masked]
Subject: Re: [CDNi] New Text for Framework on URI Rewriting

Hi Scott,
That can work for me.
Opnion anyone?
Francois

On 5 Aug 2013, at 22:55, Scott Wainner <[email-masked]> wrote:

>>>    * a Verbose Option (same as in my earlier message with minor 
>>> editorial enhancements) Let us know which you favor (or if you have alternative proposals to offer).
>>> 
>>> Francois
>>> 
>>> 
>>> Concise Option
>>> ===========
>>> "
>>> Metadata & URI Rewriting
>>> 
>>>> For example, when the transit CDN receives CDNI logging records 
>>>> from the dCDN with content URIs expressed in the ud-URI-td plan, 
>>>> and when the transit CDN includes the corresponding CDNI logging 
>>>> records for transmission to the uCDN over the CDNI Logging 
>>>> interface, the transit CDN needs to map the content URIs expressed 
>>>> in the ud-URI-td plan into URIs expressed into the ud-URI-ut plan. 
>>>> Similarly, when the transit CDN receives CDNI metadata information 
>>>> from the uCDN with content URIs expressed in the ud-URI-ut plan, 
>>>> and when the transit CDN includes the corresponfing CDNI metadata 
>>>> information for transmission to the dCDN over the CDNI Metadata 
>>>> interface, the transit CDN needs to map the content URIs expressed 
>>>> in the ud-URI-ut plan into content URIs expressed in the ud-URI-td 
>>>> plan. Regarding metadata information, note that (even when the 
>>>> ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN is 
>>>> also likely to have to perform rewriting on some other metadata 
>>>> informat
 io