Subject: [CDNi] New version of draft-ietf-cdni-redirection for London

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 13 Feb 2014 14:23:09 +0000

To authors of draft-ietf-cdni-redirection,

Could you please rev up the document for the London Meeting?

Note that the Cut-off date is Friday 14 Feb (ie tomorrow).

A number of points to be addressed were raised in Vancouver (including how to deal with errors). Also, my review comments from November 2013 (see below) still need to be addressed.

Thanks

Francois

Begin forwarded message:

From: "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>>
Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt
Date: 6 November 2013 05:02:38 CET
To: Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Ben and all,

Some comments:
=============

***
OLD:
"
If the RI is used between the uCDN
  and one or more dCDNs.  The dCDN's RI response may contain a
  Redirection Target ...
"
NEW:
"
If the RI is used between the uCDN
  and one or more dCDNs, the dCDNs' RI response will typically contain a
  Redirection Target ...
"

***
OLD:
"
where the attributes of a User
  Agent's requests are encapsulated along with any other data that can
  aid the downstream CDN in processing the requests.  The RI response
  encapsulates the attributes
"
NEW:
"
where the attributes of a User
  Agent's requests are conveyed along with any other data that can
  aid the downstream CDN in processing the requests.  The RI response
  conveys the attributes
"
[as discussed before, "encapsulates" incorrectly suggests they are conveyed by embedding their native format]

***
OLD:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
  shall convey as much information as possible to the Downstream CDN,
  for example the URI of the requested content and the User Agent's
  location information, when those are known by the uCDN Request
  Routing system.
"
NEW:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
  conveys the necessary information to the Downstream CDN,
  for example the URI of the requested content and the User Agent's
  location information, when those are known by the uCDN Request
  Routing system. Based on its policy, the Upstream CDN can decide to also convey additional information about the request (e.g. HTTP request headers) to allow the Downstream CDN to make a more informed decision.

"

*** section 4.2, table illustrating "Top-Level keys in RI requests/responses"
The table (or the text that follow it) needs to indicate more exhaustively which key is Mandatory or not (separately for request and for response).

*** section 4.2, table illustrating "Top-Level keys in RI requests/responses"
"Transit CDNs should check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path."  This wording is redundant with some text further in teh document also discussing use of cdn-path and it is not worded properly with RFC2119 keywords. I suggest removing it from the table.

***
OLD:
"
The dns dictionary of a RI request for DNS based redirection MUST
  contain the following keys: resolver-ip, qtype, qclass, qname and the
  value of each MUST be the value of the appropriate part of the User
  Agent's DNS query/request.
"
NEW:
"
The dns dictionary of a RI request for DNS based redirection MUST
  contain all the keys identified as Mandatory in the table above, and the
  value of each MUST be the value of the appropriate part of the User
  Agent's DNS query/request.
"
[In general, I think the doc needs a good clean-up to provide more exchaustive description of what is mandatory and what is not and better use of RFC2119 terminology]

*** section 4.4.2
"
  For DNS based redirection the dCDN needs to return one of the
  following to the uCDN in the RI response:
  o  The IP address of (or a CNAME to) the RT (if the dCDN is
     performing DNS based redirection); or
  o  The IP address of (or a CNAME to) a RT which is a Request Router
     (if the dCDN is performing HTTP based redirection).
"
It is a little confusing to read that "for DNS-based redirection, the dCDN needs to return … (if the dCDN is performing HTTP based redirection)". So you need to distinguish more explicitely between the redirection method used between the USer Agent & uCDN  versus the redirection method used by the dCDN. This probably affects also 4.4.1  (and 4.5) since its title refers to the redirection method used between the User Agent & uCDN.

*** section 4.4.2
OLD:
"
Response must contain at least one of a, aaaa, cname.
"
NEW:
"
RI Response for DNS based redirection MUST contain all the keys identified as Mandatory in the table above, as well as at least one of a, aaaa, cname.
"

*** section 4.4.2
why is the name in the response called "name" while it is called "name" in the query? Should it not be also called "qname" (if it is always is equal to the qname of the query) or "rename" (if it can be different in some situations)?

***
OLD:
"
The http dictionary of a RI request for HTTP based redirection MUST
  contain the following keys: c-ip, cs-method, cs-version and cs-uri
  and the value of each MUST be the value of the appropriate part of
  the User Agent's DNS query/request.
"
NEW:
"
The http dictionary of a RI request for HTTP based redirection MUST
  contain all the keys identifed as Mandatory in the previous table and the value of each MUST be the value of the appropriate part of  the User Agent's HTTP request.
"

*** section 4.6
"
Additionally, an RI response MUST NOT be reused unless the request
  from the User Agent would generate an identical RI request to the
  dCDN as the one that resulted in the cached RI response.
"
This "MUST NOT" statement is immediately contradicted by the subsequent paragraph introducing the notion of Scope. So it cannot stay as is.
Also, you need to discuss the case of a request with everything identical except with different HTTP headers. That woudl generate a different RI request, yet can you reuse a previous RI response or not?

*** section 4.6:
OLD:
"
    "http": {
      "sc-status": 302,
      "cs-uri": "http://www.example.com"
      "sc-location":
        "http://sur1.dcdn.example/ucdn/example.com",
"
NEW:
"
    "http": {
      "sc-status": 302,
      "cs-uri": "http://www.example.com/movie100.mp4"
      "sc-location":
        "http://sur1.dcdn.example/ucdn/example/movie100.mp4",
"

*** section 4.7:
"
[[Editor's note: We've tried to keep error specification light weight
  & provide the hooks needed to help with debugging without trying to
  be overly prescriptive
"
I see the intent, but I don't get what you are proposing exactly: to not define error values at all? to define a few only and allow implementations to easily define others with (or without?) registering those before?
Perhaps this could be achieved by creating a name based registry, with very easy allocation of new names.

*** section 4.8: In general, the text of that section could read better.
There is overlap between the 3rd paragraph and the first one.
OLD:
"
In order to prevent and detect RI request loops, each CDN MUST insert
  its CDN Provider ID into the cdn-path key of every RI request it
  originates or cascades.
"
NEW:
"
In order to prevent and detect RI request loops, each CDN MUST insert
  its CDN Provider ID into the cdn-path key of every RI request it
  originates, and MUST append its CDN Provider ID into the cdn-path key of every RI request it
  cascades.
"

OLD:
"
Transit CDNs
  should check the cdn-path and not cascade the RI request to
  downstream CDNs that are already listed in cdn-path.  CDNs MUST NOT
  propagate to any downstream CDNs if the number of CDN Provider IDs in
  cdn-path (including the CDN's own Provider ID) is equal to or greater
  than max-hops.
"
NEW:
"
Transit CDNs
  MUST check the cdn-path and not cascade the RI request to
  downstream CDNs that are already listed in cdn-path.  CDNs MUST NOT
  propagate to any downstream CDNs if the number of CDN Provider IDs in
  cdn-path (after appending their own CDN Provider ID) is equal to or greater
  than max-hops.
"

*** section 5:
"
Information passed over the RI could be considered personal or
  sensitive, for example RI requests contain parts of a User Agent's
  original request and RI responses reveal information about the dCDN's
  policy for which surrogates should serve which content/user
  locations.
"
You can state after that paragraph, that a mitigation approach is for uCDN RI implementation to support a policy that minimises the information conveyed in the RI requests (or even possibly performs some anonimisation of the client IP address).

*** section 5:
"

  The RI interface also provides a mechanism whereby a uCDN could probe
  a dCDN and infer the dCDN's edge topology by making repeated RI
  requests for different content and/or UA IP addresses and correlating
  the responses from the dCDN.  Additionally the ability for a dCDN to
  indicate that a RI response applies more widely that the original
  request (via the scope dictionary) may significantly reduce the
  number of RI requests required to probe and infer the dCDN's edge
  topology.
  The same information could be obtained in the absence of the RI
  interface, but it could be more difficult to gather as it would
  require a distributed set of machines with a range of different IP
  addresses each making requests directly to the dCDN.  However, the RI
  facilitates easier collection of such information as it enables a
  single client to query the dCDN for a redirection/surrogate selection
  on behalf of any UA IP address.
"
You could perhaps state that:
* by definition, use of recursive redirection assumes that dCDN is willing to provide more vsisbility to uCDN than with iterative.
* if that is a concern, dCDN could mitigate the problem by somewhat obfuscating the information returned (eg providing hostnames/CNAMEs that do not map to surrogates 1 to 1), or could return RTs that are subject to a second level resolution (eg regional Request Routers) which, pushed to the extreme, effectively degrades back to iterative redirection.

* section 5:
When discussing benefits of using TLS, please clarifies TLS comes "for free" thanks to the HTTP transport of RI.
Also, mention TLS also provides integrity protection (e.g. a RI response cannot be modified).

Editos:
=====

*** s/(RI) is one of the main building blocks/(RI) is one of the building blocks/
*** s/it is down to the uCDN to decide/it is up to the uCDN to decide/
*** s/in this draft/in this document/   [multiple occurrences]
*** s/and could be extended/and could be extended in future versions/
*** s/to help the Upstream CDN with future RI requests/to help the Upstream CDN handle future RI requests/
*** allocate a TAble number to all the tables, for easier reference in the text.
*** s/cacheable & not stale/cacheable and not stale/
*** s/It should be noted that the loop detection & prevention mechanisms described above only cover preventing and detecting loops within the RI itself./It should be noted that the loop detection and prevention mechanisms described above only prevents and detects loops within the RI itself./
*** s/As well as loops with the RI itself,/In addition to loops with the RI itself,/

On 21 Oct 2013, at 11:27, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

Colleagues,

This is an update to the redirection interface specification to add additional editorial text around data plane loop detection, media types to use, the JSON encoding and the security considerations.

There are still some things outstanding within the document but any review or suggestions for additional text would be most welcome :-)

Ben

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Date: 21 October 2013 10:30:41 GMT+01:00
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

Title           : Request Routing Redirection Interface for CDN Interconnection
Author(s)       : Wang Danhua
                       Ben Niven-Jenkins
                       He Xiaoyan
                       Ge Chen
                       Ni Wei
Filename        : draft-ietf-cdni-redirection-01.txt
Pages           : 24
Date            : 2013-10-21

Abstract:
The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream CDN that
allows a upstream CDN to decide whether to redirect particular user
requests to that downstream CDN; and (2) the synchronous operation of
an upstream CDN requesting whether a downstream CDN is prepared to
accept a user request and of a downstream CDN responding with how to
actually redirect the user request.  This document describes an
interface for the latter part, i.e. the CDNI request routing/
Redirection Interface.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-redirection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

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

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

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 14 Feb 2014 09:30:21 +0000

Francois,

> Note that the Cut-off date is Friday 14 Feb (ie tomorrow).

I don't have the cycles to up rev the document today.

In Vancouver you were going to try and find someone with some cycles to help with the editing, how is that progressing?

Although I haven't managed to do anything to the draft itself, I have managed to spend some time going over the draft and identifying a list of edits that need to be made  (including your comments below) and open items (such as errors) along with some thoughts on how to resolve them. Unfortunately, I haven't had any time to fold them into the draft as actual text.

Regards
Ben

>> From: "Francois Le Faucheur (flefauch)" <[email-masked]>
>> To: Ben Niven-Jenkins <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> 
>> Ben and all,
>> 
>> Some comments:
>> =============
>> 
>> ***
>> OLD:
>> "
>> On 21 Oct 2013, at 11:27, Ben Niven-Jenkins <[email-masked]> wrote:
>> 
>>> Colleagues,
>>> 
>>>> From: [email-masked]
>>>> To: [email-masked]
>>>> Cc: [email-masked]

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 14 Feb 2014 09:42:24 +0000

Hi Ben,

> In Vancouver you were going to try and find someone with some cycles to help with the editing, how is that progressing?

Aryl and I are looking into that.

> Although I haven't managed to do anything to the draft itself, I have managed to spend some time going over the draft and identifying a list of edits that need to be made  (including your comments below) and open items (such as errors) along with some thoughts on how to resolve them.

Good.
Let’s make sure you hook up in London with the TBD editor(s), so this information is passed on effectively.

Thanks

Francois 

> Unfortunately, I haven't had any time to fold them into the draft as actual text.
> 
> Regards
> Ben
> 
> 
>>