Subject: [CDNi] no semantic attached to the RFC8008 Redirection modes

From: Guillaume Bichot <[email-masked]>
Date: Wed, 21 Apr 2021 17:03:46 +0000

Hi all

In SVA Open Caching we have a discussion related to issues that touch some of the fundamentals of CDN and we would be interested to hear what the CDNi group thinks about those issues.

FCI and Redirection modes

RFC8008 ("CDNI RR Footprint/Capabilities Semantics") lists a number of capabilities related to request routing the dCDN may advertize through the FCI interface. Regarding the "Redirection mode" object, a redirection-modes property gathers a list of up to four possible values (namely HTTP-I, HTTP-R, DNS-I, DNS-R) defined in section 6.2. If one looks for the definition/semantic attached to each of this value, the table in 6.2 indicates RFC8008 ! In other words, there is no semantic attached to each of these values.

In SVA we have a discussion about whether these values describe what is possible/supported between the uCDN-dCDN interface or what is possible/supported in the dCDN.  RFC7336 gives us some insights about this question as it  discloses a set of definitions and examples. The following extract from RFC7336 sounds quite clear although  it does not  explicitly define the said RFC8008 Redirection modes.

Iterative CDNI Request Redirection:  When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      base its redirection purely on a local decision (and without
      attempting to take into account how the Downstream CDN may in turn
      redirect the user agent).  In that case, the Upstream CDN
      redirects the request to the Request Routing system in the
      Downstream CDN, which in turn will decide how to redirect that
      request: this approach is referred to as "Iterative" CDNI Request
      Redirection.

Recursive CDNI Request Redirection:  When an Upstream CDN elects to

      redirect a request towards a Downstream CDN, the Upstream CDN can

      query the Downstream CDN Request Routing system via the CDNI

      Request Routing Redirection interface (or use information cached

      from earlier similar queries) to find out how the Downstream CDN

      wants the request to be redirected.  This allows the Upstream CDN

      to factor in the Downstream CDN response when redirecting the user

      agent.  This approach is referred to as "Recursive" CDNI Request

      Redirection.  Note that the Downstream CDN may elect to have the

      request redirected directly to a Surrogate inside the Downstream

      CDN, or to any other element in the Downstream CDN (or in another

      CDN), to handle the redirected request appropriately.

>From that extract, one could understand that redirection modes advertized by the dCDN relate to the redirection mode the uCDN can perform. However, whatever method or redirection the uCDN may perform (i.e. DNS or HTTP redirect), it seems it has no impact on the dCDN (according to the workflows depicted in RFC7336) and therefore would require no FCI advertisement from the dCDN about supporting these modes of redirection.

Let's see what could be the semantic attached to each of these redirection modes values.

The semantic attached to "-I" or "-R" is quite clear when reading both RFC 7337 (section 5) and RFC7336:

  *   If the dCDN signals "-R" that means "Recursive mode";  it supports receiving requests to only the final surrogate cache. No dCDN request router is involved.
  *   If the dCDN signals "-I" that means "Iterative mode";  it supports receiving requests to an intermediate endpoint (said request router) which have to route the request in a second iterative step to the final surrogate cache.

The advertized mode (iterative or recursive) is not dependent to whether the dCDN supports the Request Routing redirection interface/API (e.g. RFC 7975). This is clear when reading RFC 7337 (section 5) but in contradiction with RFC7336 (see the extracted text above related to the recursive mode) .

Now about DNS versus HTTP:

  *   For the recursive mode, based on our assumption that the dCDN advertising its supports for HTTP redirect and/or DNS redirect as the delegation method to be used by the uCDN is useless, there is no need for the dCDN to advertise anything particular. Instead  could be used to signal the support of the Request Routing redirection interface/API (e.g. RFC 7975) and more particularly whether DNS or HTTP is supported.
  *   For the iterative mode,  based on our assumption that the dCDN advertising its supports for HTTP redirect and/or DNS redirect as the delegation method to be used by the uCDN is useless, it would make sense, however that the dCDN (the request router) advertises it it supports DNS or HTTP redirect itself for the second iterative redirect operation.  Why ? Because the second redirection step performed by the dCDN-RR  like the first one (performed by the uCDN-RR) impacts the user agent. The uCDN may have the possibility through configuration to restrict the dCDN-RR  redirect modes for implementation reasons like DNS redirect  or HTTP redirect may not be supported by the end user application.

As you can see, the semantic attached to those redirection modes are unbalanced and unclear when reading RFC8008.

This drives to three related proposals.

  1.  Update RFC 8008  in order to describe the semantic associated with the redirection-modes property's four possible values (namely HTTP-I, HTTP-R, DNS-I, DNS-R)
  2.  Define the semantic in a way this can provide a mean for the uCDN to influence the way the dCDN perfoms request routing.
I would then propose those definitions for the FCI redirection modes that could be the basis for a change request in CDNi in relation with FCI (RFC 8008)I:

HTTP-I: the dCDN supports request routing redirection based on the HTTP redirect method (independently of the uCDN request routing  method).
DNS-I: the dCDN supports request routing redirection  based on the DNS method (independently of  the uCDN request routing  method).
HTTP-R: the dCDN supports the Request Routing redirection interface/API for handling HTTP related requests.

DNS-R: the dCDN supports the Request Routing redirection interface/API for handling DNS related requests.

  1.  Define a new object in RFC8006 allowing the uCDN to select the redirection mode(s) (among those supported by the dCDN) that the dCDN can operate in iterative mode
MI.IterativeRequestRouting
                {
                  "Redirection-modes": ["HTTP", "DNS" ]
}

The root of the discussion: manifest rewrite
In order to complexify the subject, we are defining in SVA a new request routing redirection method based on manifest rewriting (i.e, the uCDN, on a manifest/playlist request, update the URIs in the manifest/playlist in order for the terminal's player to be redirected to the dCDN request router (interactive mode) or even directly to the final surrogate cache server node (recursive mode).
Due to the considerations depicted above, we did not find appropriate  to add a new FCI redirection modes capabilities (e.g. "MANIFEST-I, MANIFEST-R) as what the dCDN will see is either HTTP or DNS related transactions. However, it turns out that in some situation (like dealing with MPEG DASH manifest and operating HTTP redirect in iterative mode with the dCDN-RR), the dCDN may not support this form of redirection; for instance, if the uCDN updates the MPEG Dash manifest with URIs pointing out the dCDN-RR, the player must submit subsequent segment requests to the dCDN-RR that must redirect those requests to the final cache node implying a very un-efficient workflow.

This drives to the related proposal (note that with DNS-I or HTTP-R and DNS-R, there is no such issue):

  1.  Define a new redirection mode, let's say HTTP-I-MANIFEST, indicating that the dCDN supports request routing redirection based on the HTTP redirect method (independently of  the uCDN request routing  method) for manifest requests only.
If HTTP-I is indicated, it would mean any kind of delegation is supported (i.e. request routing method used by the uCDN); the dCDN  performs request routing based on HTTP redirect.  If HTTP-I-MANIFEST is indicated, it would mean any kind of delegation is supported (i.e. request routing method used by the uCDN); the dCDN  performs request routing based on HTTP redirect but just for manifest requests.

Hoping you got those points. Remember that these issues are under discussion and we have on the table other alternatives proposed by SVA colleagues for solving some of  those issues. We think that sharing this with the CDNI group might help in clarifying the semantic behind the CFI redirection modes, selecting the best alternative for handling the MI configuration and FCI advertizements related to the redirection modes  and also may be considering new alternatives.

Guillaume Bichot

Guillaume Bichot
Principal Engineer, Head of Exploration

m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>
[Logo]<https://www.broadpeak.tv/>

[twitter]<https://twitter.com/broadpeak>
[linkedin]<https://www.linkedin.com/company/broadpeak_2/>
[website]<https://broadpeak.tv/>

---

From: Kevin Ma <[email-masked]>
Date: Wed, 28 Apr 2021 23:32:35 -0400

Hi Guillaume,

> If one looks for the definition/semantic attached to each of this value,
the table in 6.2 indicates RFC8008 !

  I guess I've never thought of it that way, but the intent of the document
was to describe the semantics of what "footprint" and "capabilities" mean
within the CDNI context.  Though we chose to define the base capabilities
(i.e., delivery protocol, acquisition protocol, redirection mode, cdni
logging and cdni metadata), I don't think we ever thought about defining
"semantics" for those; those semantics are all defined in separate
documents.  As noted, the redirection modes are defined in RFC 7336.

> The semantic attached to “-I” or “-R” is quite clear when reading both
RFC 7337 (section 5) and RFC7336:

  I think the table in Section 6.2 of RFC 8008 ties the "-I" and "-R" to
"Iterative" and "Recursive", respectively.

  I think Section 3 of RFC 7975 has the best summary:

   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.

  "-R" means requests over the RI, and "-I" means no requests over the RI.

  In RFC 7336, the examples in sections 3.2 and 3.3 show this key
difference in the "RR/RI REQ" and "RR/RI" RESP" that exist in the 3.3
recursive redirection example, whereas the 3.2 iterative redirection
example does not.

> In order to complexify the subject, we are defining in SVA a new request
routing redirection method based on manifest rewriting

  wrt manifest rewrite, are you familiar with RFC 6983 (specifically
section 3.3)?  We did originally consider some of these issues, but in the
interest of limiting scope and IPR exposure, the WG decided not to tackle
manifest rewrite.  I think it is probably worthwhile restarting the
discussion, but I want to clear up any iterative vs. recursive confusion
first.

thanx!

--  Kevin J. Ma

On Wed, Apr 21, 2021 at 1:03 PM Guillaume Bichot <
[email-masked]> wrote:

> Hi all
>
>
>
> In SVA Open Caching we have a discussion related to issues that touch some
> of the fundamentals of CDN and we would be interested to hear what the CDNi
> group thinks about those issues.
>
>
>
> *FCI and Redirection modes*
>
>
>
> RFC8008 (“CDNI RR Footprint/Capabilities Semantics”) lists a number of
> capabilities related to request routing the dCDN may advertize through the
> FCI interface. Regarding the “Redirection mode” object, a redirection-modes
> property gathers a list of up to four possible values (namely HTTP-I,
> HTTP-R, DNS-I, DNS-R) defined in section 6.2. If one looks for the
> definition/semantic attached to each of this value, the table in 6.2
> indicates RFC8008 ! In other words, there is no semantic attached to each
> of these values.
>
>
>
> In SVA we have a discussion about whether these values describe what is
> possible/supported between the uCDN-dCDN interface or what is
> possible/supported in the dCDN.  RFC7336 gives us some insights about this
> question as it  discloses a set of definitions and examples. The following
> extract from RFC7336 sounds quite clear although  it does not  explicitly
> define the said RFC8008 Redirection modes.
>
>
>
> From that extract, one could understand that redirection modes advertized
> by the dCDN relate to the redirection mode the uCDN can perform. However,
> whatever method or redirection the uCDN may perform (i.e. DNS or HTTP
> redirect), it seems it has no impact on the dCDN (according to the
> workflows depicted in RFC7336) and therefore would require no FCI
> advertisement from the dCDN about supporting these modes of redirection.
>
>
>
> Let’s see what could be the semantic attached to each of these redirection
> modes values.
>
>
>
> The semantic attached to “-I” or “-R” is quite clear when reading both RFC
> 7337 (section 5) and RFC7336:
>
>    - If the dCDN signals “-R” that means “Recursive mode”;  it supports
>    receiving requests to only the final surrogate cache. No dCDN request
>    router is involved.
>    - If the dCDN signals “-I” that means “Iterative mode”;  it supports
>    receiving requests to an intermediate endpoint (said request router) which
>    have to route the request in a second iterative step to the final surrogate
>    cache.
>
>
>
> The advertized mode (iterative or recursive) is not dependent to whether
> the dCDN supports the Request Routing redirection interface/API (e.g. RFC
> 7975). This is clear when reading RFC 7337 (section 5) but in contradiction
> with RFC7336 (see the extracted text above related to the recursive mode) .
>
>
>
>    - For the recursive mode, based on our assumption that the dCDN
>    advertising its supports for HTTP redirect and/or DNS redirect as the
>    delegation method to be used by the uCDN is useless, there is no need for
>    the dCDN to advertise anything particular. Instead  could be used to signal
>    the support of the Request Routing redirection interface/API (e.g. RFC
>    7975) and more particularly whether DNS or HTTP is supported.
>    - For the iterative mode,  based on our assumption that the dCDN
>    advertising its supports for HTTP redirect and/or DNS redirect as the
>    delegation method to be used by the uCDN is useless, it would make sense,
>    however that the dCDN (the request router) advertises it it supports DNS or
>    HTTP redirect itself for the second iterative redirect operation.  Why ?
>    Because the second redirection step performed by the dCDN-RR  like the
>    first one (performed by the uCDN-RR) impacts the user agent. The uCDN may
>    have the possibility through configuration to restrict the dCDN-RR
>     redirect modes for implementation reasons like DNS redirect  or HTTP
>    redirect may not be supported by the end user application.
>
>
>
> As you can see, the semantic attached to those redirection modes are
> unbalanced and unclear when reading RFC8008.
>
>
>
>    1. Update RFC 8008  in order to describe the semantic associated with
>    the redirection-modes property’s four possible values (namely HTTP-I,
>    HTTP-R, DNS-I, DNS-R)
>    2. Define the semantic in a way this can provide a mean for the uCDN
>    to influence the way the dCDN perfoms request routing.
>    I would then propose those definitions for the FCI redirection modes
>    that could be the basis for a change request in CDNi in relation with FCI
>    (RFC 8008)I:
>
>
>
> *HTTP-I: the dCDN supports request routing redirection based on the HTTP
> redirect method (independently of the uCDN request routing  method).
> DNS-I: the dCDN supports request routing redirection  based on the DNS
> method (independently of  the uCDN request routing  method).   HTTP-R: the
> dCDN supports the Request Routing redirection interface/API for handling
> HTTP related requests.*
>
> *DNS-R: the dCDN supports the Request Routing redirection interface/API
> for handling DNS related requests.*
>
>    1. Define a new object in RFC8006 allowing the uCDN to select the
>    redirection mode(s) (among those supported by the dCDN) that the dCDN can
>    operate in iterative mode
>
>                   “Redirection-modes”: [“HTTP”, “DNS” ]
>
> }
>
>
>
> *The root of the discussion: manifest rewrite       *
>
> In order to complexify the subject, we are defining in SVA a new request
> routing redirection method based on manifest rewriting (i.e, the uCDN, on a
> manifest/playlist request, update the URIs in the manifest/playlist in
> order for the terminal’s player to be redirected to the dCDN request router
> (interactive mode) or even directly to the final surrogate cache server
> node (recursive mode).
>
> Due to the considerations depicted above, we did not find appropriate  to
> add a new FCI redirection modes capabilities (e.g. “MANIFEST-I, MANIFEST-R)
> as what the dCDN will see is either HTTP or DNS related transactions.
> However, it turns out that in some situation (like dealing with MPEG DASH
> manifest and operating HTTP redirect in iterative mode with the dCDN-RR),
> the dCDN may not support this form of redirection; for instance, if the
> uCDN updates the MPEG Dash manifest with URIs pointing out the dCDN-RR, the
> player must submit subsequent segment requests to the dCDN-RR that must
> redirect those requests to the final cache node implying a very
> un-efficient workflow.
>
>
>
>    1. Define a new redirection mode, let’s say *HTTP-I-MANIFEST*,
>    indicating that the *dCDN supports*
> *request routing redirection based on the HTTP redirect method
>    (independently of  the uCDN request routing  method) for manifest requests
>    only.   *If HTTP-I is indicated, it would mean any kind of delegation
>    is supported (i.e. request routing method used by the uCDN); the dCDN
>     performs request routing based on HTTP redirect.  If HTTP-I-MANIFEST is
>    indicated, it would mean any kind of delegation is supported (i.e. request
>    routing method used by the uCDN); the dCDN  performs request routing based
>    on HTTP redirect but just for manifest requests.
>
>
>
> Hoping you got those points. Remember that these issues are under
> discussion and we have on the table other alternatives proposed by SVA
> colleagues for solving some of  those issues. We think that sharing this
> with the CDNI group might help in clarifying the semantic behind the CFI
> redirection modes, selecting the best alternative for handling the MI
> configuration and FCI advertizements related to the redirection modes  and
> also may be considering new alternatives.
>
>
>
> Guillaume Bichot
>
>
>
>
>
>
>
> *Guillaume Bichot*
> *m:* +33 685 597 666    *p:* +33 222 740 350
>
> [email-masked] <[email-masked]>
>
>  <https://www.broadpeak.tv/>
>
>
>
>  <https://twitter.com/broadpeak>
>
>  <https://www.linkedin.com/company/broadpeak_2/>
>
>  <https://broadpeak.tv/>
>
>
>

---

From: Guillaume Bichot <[email-masked]>
Date: Thu, 29 Apr 2021 15:02:27 +0000

Hi Kevin, comments inline [GBI]
Guillaume

From: Kevin Ma <[email-masked]>
Sent: Thursday, April 29, 2021 5:33 AM
To: Guillaume Bichot <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] no semantic attached to the RFC8008 Redirection modes

Hi Guillaume,

> If one looks for the definition/semantic attached to each of this value, the table in 6.2 indicates RFC8008 !

  I guess I've never thought of it that way, but the intent of the document was to describe the semantics of what "footprint" and "capabilities" mean within the CDNI context.  Though we chose to define the base capabilities (i.e., delivery protocol, acquisition protocol, redirection mode, cdni logging and cdni metadata), I don't think we ever thought about defining "semantics" for those; those semantics are all defined in separate documents.  As noted, the redirection modes are defined in RFC 7336.

[GBI] Strictly speaking the redirection modes are not defined n RFC 7336. The latter defines what is "Iterative CDNI Request Redirection" and what is "Recursive CDNI Request Redirection". In addition it explains the concept behind DNS redirection and HTTP redirection. but does not defines what means "HTTP-I, HTTP-R, DNS-I and DNS-R. This is my point.

> The semantic attached to "-I" or "-R" is quite clear when reading both RFC 7337 (section 5) and RFC7336:

  I think the table in Section 6.2 of RFC 8008 ties the "-I" and "-R" to "Iterative" and "Recursive", respectively.
[GBI] Yes and what does mean "Iterative and "Recursive" may be the issue. In RFC7336, the definition are not coherent. It says that with the "Iterative" mode, the uCDN redirects without considering how the dCDN may redirect the request".  This statement is perfectly compatible with using the RI interface when the dCDN returns RT that corresponds to the dCDN request router.
Overall there is a lack of coherency. It is like there has been some kind of conflict regarding all this terminology and an agreement was found which makes the reader simply lost...

   CDNs.

[GBI] This statement is strange and in contradiction with the protocol defined by RFC7975 that permits to return redirection targets corresponding to a dCDN request router. So one can conclude that the redirection interface can be used for both iterative and recursive modes. This interpretation is confirmed when reading the introduction (section 1) of RFC7975. The value of the protocol is that it is synchronous whereas without such interface/protocol, only the asynchronous method can be used (FCI + MI) that is valid for only the iterative mode.

[GBI] I disagreed with this interpretation based on the definition of the "Recursive CDNI Request Redirection" in RFC736 (section 1.1 terminology) but contradicted by RFC7975 itself (see what  I just wrote above) and by the RFC 7337 section 5/RI-4.  But finally I concluded almost the same than you: Forget about "Recursive" or "iterative". -R would mean, I support the RI interface and -I would mean I do not support the RI interface. This is the sense of my proposal below.

In RFC 7336, the examples in sections 3.2 and 3.3 show this key difference in the "RR/RI REQ" and "RR/RI" RESP" that exist in the 3.3 recursive redirection example, whereas the 3.2 iterative redirection example does not.

[GBI] Not sure to understand what you mean here. 3.2 describes an example about "iterative HTTP redirect" and 3.3 describes an example about "recursive HTTP redirect".

[GBI] Overall, we still do not know what means "HTTP-I, HTTP-R, DNS-I and DNS-R that is key for CDN delegation. From the dCDN perspective there is nothing that differentiates HTTP-redirect  and  DNS-redirect method used by the uCDN.  Moreover there is nothing in CDNi MI that can be used by the uCDN to forbid/authorize a certain type of dCDN request routing (assuming it is iterative). This is problematic: e.g. a UA could not support HTTP redirect.

Nothing in what is written in RFC 7336 or RFC 7975 seems to contradict the following interpretation. The question I  have is therefore. Do you agree with this interpretation that would solve our problem?

HTTP-I: the dCDN supports request routing redirection based on the HTTP redirect method (independently of the uCDN request routing  method).
DNS-I: the dCDN supports request routing redirection  based on the DNS method (independently of  the uCDN request routing  method).
HTTP-R: the dCDN supports the Request Routing redirection interface/API for handling HTTP related requests.
DNS-R: the dCDN supports the Request Routing redirection interface/API for handling DNS related requests

> In order to complexify the subject, we are defining in SVA a new request routing redirection method based on manifest rewriting

  wrt manifest rewrite, are you familiar with RFC 6983 (specifically section 3.3)?  We did originally consider some of these issues, but in the interest of limiting scope and IPR exposure, the WG decided not to tackle manifest rewrite.  I think it is probably worthwhile restarting the discussion, but I want to clear up any iterative vs. recursive confusion first.

[GBI] Yes. Absolutely agree.

thanx!

--  Kevin J. Ma

On Wed, Apr 21, 2021 at 1:03 PM Guillaume Bichot <[email-masked]<mailto:[email-masked]>> wrote:
Hi all

Guillaume Bichot

Guillaume Bichot

m: +33 685 597 666    p: +33 222 740 350
[email-masked]<mailto:[email-masked]>
[Logo]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726042290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Czrc6%2FMwza8fsxsS1VnNWTG7ichtt4x2mTNpyZpBF2I%3D&reserved=0>

[twitter]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726052243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4N3JAID5rYIBZCIgHpF4Ehs7jEd6EcoK%2BgEnTG7inkk%3D&reserved=0>
[linkedin]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fbroadpeak_2%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726052243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d6GnyZMm4YHWXaCFypxRa0LLz0MR6wo7%2BUfnqwDnVho%3D&reserved=0>
[website]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726062202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6822b90DWh5Zo6SKRqT%2B1v8SzAlHMHyT1l6mPuOC024%3D&reserved=0>

---

From: Kevin Ma <[email-masked]>
Date: Sat, 1 May 2021 01:35:02 -0400

Hi Guillaume,

  I don't think your proposed interpretations are wrong, but I don't know
that they precisely describe the original intent of iterative and recursive
routing.  The intent afair was: "-R" means uCDNs must use the RI to ask the
dCDN and "-I" means no requests over the RI.

  In hindsight, I agree that the definitions in RFC 7336 could have been
clearer:

   Iterative CDNI Request Redirection:  When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      base its redirection purely on a local decision

   Recursive CDNI Request Redirection:  When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      query the Downstream CDN Request Routing system via the CDNI
      Request Routing Redirection interface

  The iterative definition could have said "the Upstream CDN may not query
the Downstream CDN Request Routing system via the CDNI Request Routing
Redirection interface"; and the recursive definition could have said "the
Upstream CDN is required to query the Downstream CDN Request Routing system
via the CDNI Request Routing Redirection interface".

  Regardless, the intent for the redirection modes was:

  - "HTTP-I" was intended to correspond to the example in Section 3.2 of
RFC 7336, i.e., HTTP without using the RI;
  - "HTTP-R" was intended to correspond to the example in Section 3.3 of
RFC 7336, i.e., HTTP with the uCDN using the RI to query the dCDN;
  - "DNS-I" was intended to correspond to the example in Section 3.4 of RFC
7336, i.e., DNS without using the RI; and
  - "DNS-R" was intended to correspond to the example in Section 3.5 of RFC
7336, i.e., DNS with the uCDN using the RI to query the dCDN.

  I will say that it doesn't make sense to advertise both "-I" and "-R",
but if the dCDN wanted to enforce use of the RI by the uCDN, the dCDN could
advertise only "-R", or if the dCDN did not support the RI, it could
advertise only "-I".  We could consider publishing an informational RFC or
BCP to clarify the intent described above and some use cases if that would
be helpful?

  Are the above mode definitions clear (even if they do not necessarily
comport with your interpretations of the text)?  If so, do you think
the modes as defined above are good or useful?  If not, I think that is a
worthwhile discussion to have.  And/or if you think that there are better
and more useful modes to have, I think that is also something worth
discussing.

thanx.

--  Kevin J. Ma

On Thu, Apr 29, 2021 at 11:02 AM Guillaume Bichot <
[email-masked]> wrote:

> *From:* Kevin Ma <[email-masked]>
> *Sent:* Thursday, April 29, 2021 5:33 AM
> *To:* Guillaume Bichot <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [CDNi] no semantic attached to the RFC8008 Redirection
> modes
>
>
>
> Hi Guillaume,
>
>
>
>   I guess I've never thought of it that way, but the intent of the
> document was to describe the semantics of what "footprint" and
> "capabilities" mean within the CDNI context.  Though we chose to define the
> base capabilities (i.e., delivery protocol, acquisition protocol,
> redirection mode, cdni logging and cdni metadata), I don't think we ever
> thought about defining "semantics" for those; those semantics are all
> defined in separate documents.  As noted, the redirection modes are defined
> in RFC 7336.
>
>
>
> [GBI] Strictly speaking the redirection modes are not defined n RFC 7336.
> The latter defines what is “Iterative CDNI Request Redirection” and what is
> “Recursive CDNI Request Redirection”. In addition it explains the concept
> behind DNS redirection and HTTP redirection. but does not defines what
> means “HTTP-I, HTTP-R, DNS-I and DNS-R. This is my point.
>
>
>
> [GBI] Yes and what does mean “Iterative and “Recursive” may be the issue.
> In RFC7336, the definition are not coherent. It says that with the
> “Iterative” mode, the uCDN redirects without considering how the dCDN may
> redirect the request”.  This statement is perfectly compatible with using
> the RI interface when the dCDN returns RT that corresponds to the dCDN
> request router.
>
> Overall there is a lack of coherency. It is like there has been some kind
> of conflict regarding all this terminology and an agreement was found which
> makes the reader simply lost…
>
>
>
> [GBI] I disagreed with this interpretation based on the definition of the
> “Recursive CDNI Request Redirection” in RFC736 (section 1.1 terminology)
> but contradicted by RFC7975 itself (see what  I just wrote above) and by
> the RFC 7337 section 5/RI-4.  But finally I concluded almost the same than
> you: Forget about “Recursive” or “iterative”. -R would mean, I support the
> RI interface and -I would mean I do not support the RI interface. This is
> the sense of my proposal below.
>
>
>
> In RFC 7336, the examples in sections 3.2 and 3.3 show this key difference
> in the "RR/RI REQ" and "RR/RI" RESP" that exist in the 3.3 recursive
> redirection example, whereas the 3.2 iterative redirection example does not.
>
>
>
> [GBI] Not sure to understand what you mean here. 3.2 describes an example
> about “iterative HTTP redirect” and 3.3 describes an example about
> “recursive HTTP redirect”.
>
>
>
> [GBI] Overall, we still do not know what means “HTTP-I, HTTP-R, DNS-I and
> DNS-R that is key for CDN delegation. From the dCDN perspective there is
> nothing that differentiates HTTP-redirect  and  DNS-redirect method used by
> the uCDN.  Moreover there is nothing in CDNi MI that can be used by the
> uCDN to forbid/authorize a certain type of dCDN request routing (assuming
> it is iterative). This is problematic: e.g. a UA could not support HTTP
> redirect.
>
>
>
> Nothing in what is written in RFC 7336 or RFC 7975 seems to contradict the
> following interpretation. The question I  have is therefore. Do you agree
> with this interpretation that would solve our problem?
>
>
>
>
> HTTP related requests. DNS-R: the dCDN supports the Request Routing
> redirection interface/API for handling DNS related requests*
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726042290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Czrc6%2FMwza8fsxsS1VnNWTG7ichtt4x2mTNpyZpBF2I%3D&reserved=0>
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726052243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4N3JAID5rYIBZCIgHpF4Ehs7jEd6EcoK%2BgEnTG7inkk%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fbroadpeak_2%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726052243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d6GnyZMm4YHWXaCFypxRa0LLz0MR6wo7%2BUfnqwDnVho%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cd1c0b9a250a847e4633608d90abf767c%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637552639726062202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6822b90DWh5Zo6SKRqT%2B1v8SzAlHMHyT1l6mPuOC024%3D&reserved=0>
>
>
>
>