Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-05.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Dec 2014 12:08:17 +0000

Hi Kevin,

Thanks for the review. I've incorporated most of your editorial comments into my working copy of -06.

Responses to some other points are below.

On 28 Nov 2014, at 22:33, Kevin Ma J <[email-masked]> wrote:

> - Is the following statement true?  I thought the idea of advertising
>  support for redirection mode was so that a given CDN did not have to
>  support both mechanisms?
> 
>  "CDNI solutions are required to support both of the request routing
>   mechanisms illustrated in section 2.1 of [RFC7336], namely Iterative
>   Request Redirection and Recursive Request Redirection."
> 
>  When using the RI, it doesn't matter if the dCDNs support either;
>  they could support neither.  As long as the uCDN supported one, the
>  other, or both, and the dCDNs returned surrogate addresses over the
>  RI, then, it should just work?
> 
> - I think this can be simplified:
> 
>  "Therefore, the Redirection Interface is only relevant in the case of
>   Recursive Request Redirection and so this document will not discuss
>   Iterative Request Redirection further."
> 
>  to say:
> 
>  "This document will therefore only focus on Recursive Request Redirection."

I reworded to 
   The Redirection Interface is only relevant in the case of Recursive
   Request Redirection, as Iterative Request Redirection does not invoke
   any interaction over the Redirection Interface between interconnected
   CDNs.  Therefore the scope of this document is limited to Recursive
   Request Redirection.

> - I think it would be useful to list the actual requirements
>  (i assume this is referring to GEN-11 and RI-5) and
>  possibly have a reference to the requirements RFC7337.
> 
>  "Also, according to the CDNI generic and request routing interface
>   requirements, the CDNI solution shall support mechanisms to prevent
>   and detect RI request loops"
> 
>  e.g.:
> 
>  "CDNI requirements GEN-11 and RI-5 [RFC7337] specify that 
>   the CDNI solution shall support mechanisms to prevent
>   and detect RI request loops"

I tried referencing the requirements in RFC7337 and decided I didn;t like it so I reworded the sentence to simply say
   This document also defines an RI loop prevention and detection
   mechanism as part of the Redirection Interface.

> - Is the scope only signaled when the response cacheable?
>  Is the scope only allowed to be signaled when the response is cacheable?
>  The scope only really makes sense when it's cacheable, but is it an
>  error to send a scope if the response is not cacheable?

As you note the scope of tends to make sense if the RI response is cacheable but it is not an error to include a scope in an uncacheable RI response and the spec doesn't dictate behaviour because it is not an interoperability issue if a dCDN includes a scope in an uncacheable RI response.

> Section 4.2:
> - Though the cdn-path MAY be reflected back, are the transit CDNs
>  allowed to remove themselves (and all further dCDNs) from the chain
>  as they respond, or are they required to maintain the full chain, if
>  they choose to include cdn-path in the response.
> 
>  Similarly, is any CDN in the chain allowed to remove cdn-path from
>  the response, even if further downstream CDNs have included it
>  (i.e., the ultimate CDN decided to reflect)?

I added some text to cover this:
   Transit CDNs MUST NOT modify the cdn-path when cascading an RI
   request, except to append its own CDN Provider ID.

...

   If the cdn-path is reflected back in the RI response it MUST contain
   the value of cdn-path received in the associated RI request with the
   final dCDN's CDN Provider ID appended.  Transit CDNs MAY remove the
   cdn-path from RI responses but MUST NOT modify the cdn-path in other
   ways.

> Section 4.4.1:
> 
> - What is the use case for the dns-only flag?  Is it intended to
>  improve delivery performance?  Would it be configured by the
>  content owner to enforce request routing properties?

It is intended as a way for the uCDN to signal that it wants IP addresses of surrogates returned not a request router in a dCDN. E.g. because the uCDN/Content Provider knows that the content (e.g. a website) is not compatible with HTTP redirection for some reason.

In theory one could allow a dCDN to return a Request Router on the promise that the request router only performed DNS redirection but we didn't scope the fns-only flag that way because saying to only return IP addresses seemed cleaner.

> - If dns-only is set to true, and the transit CDN does not support DNS
>  redirection, is it always safe to propagate the request (assuming
>  the hop count and loop detection don't error out)?  Presumably there
>  is eventually either a dCDN that supports DNS or an error?

Yes it should always be safe as eventually there will either be a dCDN that supports the fns-only flag or an error.

>  It's not clear to me how this flag should be used (see also
>  questions on next section)?  If the authoritative CDN is returning
>  the DNS resolution to the UA, but the address provided by the dCDN
>  is a CNAME, does the dCDN have to honor that flag in subsequent DNS
>  queries to the dCDN?

I have tried to clarify this is the description of the dns-only flag and the description of DNS redirection responses 

     If True then dCDN MUST only use DNS redirection directly
     to a surrogate for its RI response and MUST include the
     dns-only property set to True on any cascaded RI requests.
     Defaults to False.

...

     A dCDN MUST NOT return a RT which is a Request Router if the dns-
     only key is set to True in the RI request.

> 
> Section 4.4.2:
> 
>  This is the TTL for the DNS response?  Is there an implied scope for
>  the RI response?  Should the uCDN not try to glean anything from it?
>  Either way, we might want to explicitly state whether or not the
>  uCDN can use that information (especially if the information
>  conflicts with the scope information in the HTTP response headers of
>  the RI response).

the ttl key is the TTL to be included in the DNS response sent to the User Agent. There is no implied scope beyond what can be inferred by a User Agent receiving that response. The ttl in the DNS redirection response sent to the uCDN does not imply any cache ability or scope for the RI response itself (that is signalled separately in the HTTP headers & the top-level scope key of the RI response).

> Section 4.5.1:
> 
> - For "cs-uri", is this the RFC2616 Request-URI from the HTTP request,
>  or is this the RFC7230 Effective Request URI?  Could/Should/Would
>  the uCDN ever transform the URI to make it understandable to the dCDN?

It is the RFC7230 Effective Request URI. I've made that more explicit.

I don't think the uCDN should transform the URL and the text now stating that it is the RFC7230 Effective Request URI should make that clear.

If a uCDN needs to transform for some reason, it should probably send the transformation in a different key in the JSON object.

> Section 4.5.2:
> 
> - Why is there a special case for "sc(cache-control)" in the table?
>  It is not mandatory and already covered by "sc(<headername>)"?

cs(location) is a similar case. They are both included as they are required (in the case of cs(location)) and often used (in the case of (cs(cache-control)) in redirection responses so it seems helpful to list them directly. They also serve as example of the syntax.

>  This is the cacheability of the HTTP response.  Is there an implied
>  scope for the RI response?

Yes the cs(cache-control) key contains the field-value for the Cache-Control: header to be included in the HTTP response sent to the User Agent. There is no implied scope in the same way as there is no implied scope for the t/l key in DNS redirection responses.

> Section 4.7:
> - Are error-codes generally vendor implementation/deployment dependent?
> 
>  "A three-digit numeric code defined by the server"
> 
>  Should there be a registry for all error codes?

The document already defines an IANA registry for RI error codes.

> - Depending on the answer to the dns-only question above, should there
>  also be an error code for "dCDN does not support DNS redirection and
>  does not want to give a surrogate address and dns-only set to true"?
>  Would that just be a 500?

I've added error code 506 for "Redirection protocol not supported":

   | 506  | Redirection  | The dCDN does not support the requested     |
   |      | protocol not | redirection protocol.  This error-code is   |
   |      | supported    | also used when the RI request has the dns-  |
   |      |              | only flag set to True and the dCDN is not   |
   |      |              | support or is not prepared to return a RT   |
   |      |              | of a surrogate directly.                    |

> - Is it valid for the dCDN to set the Cache-Control header for an
>  error response, e.g., out of capacity for the next 20 min?

Yes it is valid.

> - Is it necessary to have both of these requirements?  If the transit
>  CDNs never forward to looped dCDNs, the dCDNs should never be able
>  to detect a loop (assuming a uCDN doesn't sent to itself)?
> 
>  "When receiving RI requests a dCDN MUST check
>   the cdn-path and reject any RI requests which already contain the
>   downstream CDN's Provider ID in the cdn-path.  Transit CDNs MUST
>   check the cdn-path and not cascade the RI request to downstream CDNs
>   that are already listed in cdn-path."
> 
>  I don't see any harm in listing both checks, just to be safe, but I
>  didn't know if I was missing something?

It's belt & braces. If you only rely on the transit CDN to not forward to looped dCDNs then a misbehaving transit CDN could cause a loop. Checking on reception as well prevents that.

> - Why aren't the 502 and 503 errors a MUST?
> 
>  "If a downstream CDN receives a RI request whose cdn-path already
>   contains that downstream CDN's Provider ID the downstream CDN SHOULD
>   send a RI response with an error code of 502."
> 
>  "If a downstream CDN receives a RI request where the number of CDN
>   Provider IDs in cdn-path is greater than max-hops, the downstream CDN
>   SHOULD send a RI response with an error code of 503."

Because returning an error key is optional.

> Section 5:
> 
> - Should we make TLS a MUST?  Using similar text to the triggers draft?

I'll respond to this in a separate e-mail as Francois had a similar comment too.

Ben

> 
>> -----Original Message-----
>> From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
>> Sent: Monday, November 10, 2014 6:41 PM
>> To: [email-masked]
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-05.txt
>> 
>> Colleagues,
>> 
>> This update just contains a small number of editorial changes the editors
>> noticed when preparing for IETF91.
>> 
>> Regards
>> Ben
>> 
>> On 10 Nov 2014, at 23:39, [email-masked] wrote:
>> 
>>> 
>>> 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
>>>       Authors         : Ben Niven-Jenkins
>>>                         Ray van Brandenburg
>>> 	Filename        : draft-ietf-cdni-redirection-05.txt
>>> 	Pages           : 29
>>> 	Date            : 2014-11-10
>>> 
>>> 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-05
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-05
>>> 
>>> 
>>> 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]
>> https://www.ietf.org/mailman/listinfo/cdni