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

From: Kevin Ma <[email-masked]>
Date: Fri, 25 Jun 2021 23:14:59 -0400

Hi Guillaume,

  Sorry for the late reply.

> My interpretation is again the following:
> This is based on the fact that in *iterative mode*, the dCDN is not
concerned by whether the uCDN uses DNS or HTTP redirect

  wrt the above statement, again I don't think this was the intent.

  What is not stated in section 5.5 of RFC8008, but what I believe to be
the intent, is that if there is no Redirection Mode advertisement, then the
implication to the uCDN should be that the dCDN does not support (or want)
any redirection from the uCDN.  HTTP-I/DNS-I are not a signal of "don't
care" to the uCDN; HTTP-I/DNS-I are an explicit signal of "It is ok to
delegate to me, but don't bother with the CDNI RI", i.e., sending an FCI
with an empty list of Redirection Modes means don't redirect anything to
me.  Note: The bootstrap case was never covered by CDNI, so there is always
a caveat that the initial state can be defined out-of-band.

  What I believe to have been the intent is:

  HTTP-I means, you can redirect to me using HTTP (maybe I don't have a DNS
RR), but don't use the RI (maybe I don't have an RI server)
  DNS-I means, you can redirect to me using DNS (maybe I don't have an HTTP
RR), but don't use the RI (maybe I don't have an RI server)
  HTTP-R means, you can redirect to me using HTTP (maybe I don't have a DNS
RR), but only use the RI (maybe I don't have an HTTP RR, or I just want to
pre-screen all redirects)
  DNS-R means, you can redirect to me using DNS (maybe I don't have an HTTP
RR), but only use the RI (maybe I don't have a DNS RR, or I just want to
pre-screen all redirects)
  and empty list means "I don't want any redirects".

--  Kevin J. Ma

On Wed, May 12, 2021 at 1:45 PM Guillaume Bichot <
[email-masked]> wrote:

> Hi Kevin,
>
> Thanks for the answer.
>
> Regarding your proposal for the redirection modes definition:
>
>
>
>   - "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.
>
>
>
> Your interpretation related to the *iterative mode*  is still unclear.
>
>
>
> Regarding “HTTP-I”,“HTTP without using RI” may have different
> interpretations: Either the dCDN advertises about supporting the request
> routing method performed by the uCDN (delegation) or the dCDN advertises
> about the request routing method that itself supports (for the second hop).
>
> Same issue with "DNS-I" and “DNS without using the RI”
>
>
>
> My interpretation is again the following:
>
> This is based on the fact that in *iterative mode*, the dCDN is not
> concerned by whether the uCDN uses DNS or HTTP redirect; at the end this
> translates in  supporting a DNS lookup for converting an FQDN into an IP
> addresses in both cases. However the terminal and therefore the uCDN may
> care about the kind or redirection mode the dCDN can support.
>
>
>
> 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 (RI)
> for handling HTTP related requests.
>
> DNS-R: the dCDN supports the Request Routing redirection interface (RI)
> for handling DNS related requests
>
>
>
> Guillaume
>
>
>
> *From:* Kevin Ma <[email-masked]>
> *Sent:* Saturday, May 1, 2021 7:35 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 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:
>
> 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…
>
>
>
>   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.
>
>
>
> [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.
>
>
>
>   "-R" means requests over the RI, and "-I" means no requests over the RI.
>
>
>
> [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]> 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.
>
>
>
> 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] <[email-masked]>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C22515b545bc24158728c08d90c62e646%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637554441198463575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0dNPQwd6cmiDyCw8nInjEXK5gbs5dFP%2BAeA4sjzYXbo%3D&reserved=0>
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C22515b545bc24158728c08d90c62e646%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637554441198473532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hwuOHWWqkm68ZtZntm7klOIqMWGmjeJyXl%2BZnJxsvno%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%7C22515b545bc24158728c08d90c62e646%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637554441198473532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FM3LdZIOdC35WmS0tEEtgIji5tZKlYDwgKGVFGZtZOY%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C22515b545bc24158728c08d90c62e646%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637554441198483488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kvb08NqGtgzE6d%2Bb%2B%2Fm5j3Fv%2FT2d6FEcuiTveB1Nijs%3D&reserved=0>
>
>
>
>

---

From: Kevin Ma <[email-masked]>
Date: Fri, 25 Jun 2021 23:46:19 -0400

Hi Alfonso,

  Good example!  But, I think it could also be as simple as, the dCDN being
able to say: I am doing maintenance or having a capacity issue atm, please
stop hammering my DNS server?

  wrt your -I proposals, the "intermediate target" is whatever was decided
out-of-band by the uCDN and dCDN or the RFC8804 Redirection Target, most
likely a dCDN RR, but could potentially be a surrogate?

  wrt your -R proposals, I would say "the dCDN supports the Request Routing
redirection interface" should be "the dCDN requires the Request Routing
redirection interface".  I don't think the intent was to let the uCDN
choose between RI or not if only a -R is specified.

thanx!

--  Kevin J. Ma

On Tue, May 18, 2021 at 10:10 AM ALFONSO SILONIZ SANDINO <
[email-masked]> wrote:

> Hello,
>
>
>
> Let me introduce myself. I work at Telefonica CDN and I am participating
> in the SVA Open Caching group in several subgroups. I’ve been talking
> lately with Guillaume about this issue and I would like to share my vision
> about this.
>
>
>
> First, some things about the RFC8008 and RFC7336 regarding RedirectionMode.
>
>
>
> I share Guillaume thought that there is clear relationship between both
> RFCs about Redirection Mode. Although I see what Kevin  says of the
> examples in Section 3 of RFC 7336. The only relationship appears in RFC
> 8008 section 2.3 where we can red:
>
>
>
> Were the volume of FCI updates from dCDNs to exceed the volume of
>
>    requests to the uCDN, it might make more sense for the uCDN to query
>
>    dCDNs upon receiving requests *(as is the case in the recursive*
>
> *   redirection mode described in [**RFC7336
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7336&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cfd1716be4e7a474989aa08d91475d980%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637563318697737663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=giYAE%2FTj5htd2eOpyy4BC%2BKkxV5I19%2B4ngcPGULK1Dk%3D&reserved=0>*
> *]),*
>
>
>
>
>
> After that, there is no explanation about the Redirection Mode in the rest
> of RFC 8008, but some links with RFC 7336 as in here: (RFC 8008 Section 4):
>
>
>
> This document also registers CDNI Payload Types [RFC7736
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7736&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cfd1716be4e7a474989aa08d91475d980%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637563318697747594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Dg6QE89A%2FTEcmoqjobvfq9uDt1eHBY7ZdlzMPw0mR8%3D&reserved=0>]
> for the
>
>    initial capability types (see Section 6
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8008%23section-6&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cfd1716be4e7a474989aa08d91475d980%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637563318697747594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AjjKyhVQ%2FLMeg8MXS3VwjCsYZApGSLcn8Vpr7ezjsc4%3D&reserved=0>
> ):
>
>
>
> ….
>
> Redirection Mode *(e.g., DNS redirection vs. HTTP redirection as*
>
> *      discussed in [**RFC7336
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7336&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7Cfd1716be4e7a474989aa08d91475d980%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637563318697747594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EwIE%2FlPYSWUR2xbVCN1yh%2BkNl4o15NWO%2B8h5CObnNgM%3D&reserved=0>*
> *])*
>
>
>
>
>
> It would be very useful, in my opinion, to have a more clear definition of
> what a RedirectionMode is. Overall, that this a capability that is
> announced by the dCDN to the uCDN, so the uCDN can make decisions on how to
> delegate the traffic. And it is only related to this delegation mechanism,
> and not related to how the dCDN does the interal request routing.
>
>
>
> Now, about this point,  is where I am not agree with Guillaume proposal.
> Mainly because of this sentence:
>
>
>
> *This proposal is based on the fact that in iterative mode, the dCDN is
> not concerned by whether the uCDN uses DNS or HTTP redirect; at the end
> this translates in  supporting a DNS lookup for converting an FQDN into an
> IP addresses in both cases. However the terminal and therefore the uCDN may
> care about the kind or redirection mode the dCDN can support.*
>
>
>
> There are some requirements a dCDN needs to accomplish in order to permit
> an uCDN to do a Iterative DNS delegation. Mainly two:
>
>    - In DNS-I, a dCDN will receive an HTTP GET request from the end user
>    with a host header using a FQDN that belongs to the uCDN realm, and not the
>    dCDN realm. This is an use case is not supported by default in a Surrogate
>    or Request Router. So the dCDN is concerned about this method.
>    - When using HTTPS the uCDN needs to share the certificates with the
>    dCDN in some manner
>
>
>
> These two reasons justify that the dCDN needs to be concerned of how the
> uCDN is going to make the delegation. Or in other words, it justifies the
> dCDN must announce if it is capable or not to handle such DNS delegation.
>
>
>
> For HTTP-I: We could say this method does not require anything in the dCDN
> and probably that is true. But, it acts in contrast with HTTP-R. I guess
> there could be use cases where a dCDN does not want to expose its realm, or
> handling own certificates (required if HTTPS is mandatory), or whatever and
> prefer receiving traffic only with the CP/uCDN domain. It could be
> perfectly legitimate and the absence of that in the FCI could permit it.
>
>
>
> Taking all this in account, I would make a proposal about the different
> Redirection Modes definition:
>
>
>
> HTTP-I: the dCDN allows the request routing redirection mode based on HTTP
> redirect to an intermediate target. Final surrogate is decided in the dCDN.
>
> DNS-I: the dCDN allows the request routing redirection mode based on DNS
> delegation to an intermediate target. Final surrogate is decided in the
> dCDN.
>
> HTTP-R: the dCDN supports the Request Routing redirection interface/API
> for handling HTTP related requests to return the final Surrogate for an
> specific end user.
>
> DNS-R: the dCDN supports the Request Routing redirection interface/API for
> handling DNS related requests to return the final Surrogate for an specific
> end user
>
>
>
> For any other constraint from the uCDN to the dCDN, as not using internal
> HTTP redirections IN the dCDN, I suggest that should be cover in the
> Metadata Interface as a GenericMetadata that could be announced in the FCI,
> and configured by the uCDN with the MI calls.
>
>
>
> Does this make sense?
>
>
>
>
>
> Alfonso
>
>
>
>
>
>
>
>
>
> *De: *CDNi <[email-masked]> en nombre de Guillaume Bichot <
> [email-masked]>
> *Fecha: *miércoles, 12 de mayo de 2021, 19:46
> *Para: *Kevin Ma <[email-masked]>
> *CC: *"[email-masked]" <[email-masked]>
> *Asunto: *Re: [CDNi] no semantic attached to the RFC8008 Redirection modes
>
>
>
> Hi Kevin,
>
> Thanks for the answer.
>
> ·   If the dCDN signals “-R” that means “Recursive mode”;  it supports
> ·   If the dCDN signals “-I” that means “Iterative mode”;  it supports
> ·   For the recursive mode, based on our assumption that the dCDN
> ·   For the iterative mode,  based on our assumption that the dCDN
> 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:
>
>
>
> 3.Define a new object in RFC8006 allowing the uCDN to select the
> 4.Define a new redirection mode, let’s say *HTTP-I-MANIFEST*, indicating
> that the *dCDN supports*
> 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
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

---

From: Kevin Ma <[email-masked]>
Date: Sat, 26 Jun 2021 00:49:19 -0400

Hi Guillaume,

  wrt 1/ Manifest rewriting, I assume we all probably agree that the
general problem is better solved by either server-side or client-side
manifest rewrite?  ;)
  wrt  HTTP-I-MANIFEST, I think it would probably make more sense to have
HTTP-I-NO-SEGMENTS, since the dCDN may not be manifest only - it could be
manifest and icons and html, etc.?  But, more generally, could this be
handled by a request routing rate limit or by intelligent use of the RI to
get a surrogate address to which all segment requests could be directly
redirected?

  wrt 2/ Advertising/configuring the dCDN routing request methods, I think
that allowing the uCDN to control dCDN RR decisions is generally out of
scope of CDNI; it is not an interconnection/interoperability issue.  CDNI
was not intended to infringe upon dCDN autonomy, outside of CDNI Metadata.
Also, what you propose only works for a 2-level CDN federation; if there
are an arbitrary number of tCDNs, then just knowing what the immediate dCDN
supports is not enough?  Note: A uCDN could also be an arbitrary tCDN in a
cascaded CDN hierarchy.
  That said, you could try to solve this with a piece of CDNI Metadata,
e.g., given new Metadata objects for HttpRedirectOnly or DnsRedirectOnly,
have two different PathMatch objects /http and /dns which have
HttpRedirectOnly and DnsRedirectOnly set, respectively?
  Out of curiosity, is the concern that the dCDNs lack the intelligence to
make the same decision as the uCDN?  or just that the uCDN in this
particular scenario is not a generalized uCDN and has some greater
responsibility?

thanx!

--  Kevin J. Ma

On Thu, May 27, 2021 at 12:33 PM Guillaume Bichot <
[email-masked]> wrote:

> Hi all.
>
>
>
> I agree with Alfonso’s rational and what he proposed sounds reasonable.
> With such definitions we stay close to the assumptions we made in SVA when
> designing the OC API at the beginning.
>
>
>
> HTTP-I: the dCDN allows the uCDN request routing redirection mode based on
> HTTP redirect to an intermediate target. Final surrogate is decided in the
> dCDN.
>
> DNS-I: the dCDN allows the uCDN request routing redirection mode based on
> DNS delegation to an intermediate target. Final surrogate is decided in the
> dCDN.
>
> Now we have to address the two remaining problems: 1/manifest rewriting as
> a delegation mechanism and 2/ Advertising/configuring the dCDN routing
> request methods
>
>
>
> 1/ Manifest rewriting
>
> With this method, the uCDN delivers the modified manifest to the UA.
> Modification is done based on the FCI information  (FCI.RedirectTarget)
>
> The problem is that with MPEG DASH, as there is no concept of main
> playlist (like with HLS), after having received the manifest from the uCDN,
> the player is going to start playing through sending segment request to the
> dCDN RR (Request Router) that is an serious issue triggering efficiency
> problems (all subsequent segment requests will go to the dCN RR) until the
> manifest (modified again by the dCDN RR that time) gets downloaded by the
> player (which is not guaranteed). This is an issue for the HTTP-I mode only
> meaning that for the dCDN announcing that it supports HTTP-I is not
> sufficient. We need to add new values for allowing the dCDN to signal that
> it does not support segment request in iterative mode.
>
> This would give the additional value HTTP-I-MANIFEST
>
>
>
> Reusing the definitions from Alfonso:
>
>
>
> HTTP-I: the dCDN allows the request routing redirection mode (for all type
> of  HTTP requests) based on HTTP redirect to an intermediate target. Final
> surrogate is decided in the dCDN.
>
> HTTP-I-MANIFEST: the dCDN allows the request routing redirection mode
> (only for manifest/playlist related request) based on HTTP redirect to an
> intermediate target. Final surrogate is decided in the dCDN.
>
>
>
> 2/ Advertising/configuring the dCDN routing request methods
>
> In some deployment, the uCDN would like to control the way the dCDN
> performs request routing. As we agree now, allowing/supporting HTTP-I or
> DNS-I  delegation mode does not disclose the request routing method the
> dCDN is going to use. It can announce (FCI) that it supports HTTP-I and
> route the request through DNS based redirection and vice-versa. The thing
> is that the uCDN is supposed to control the UA and be aware of the player’s
> capabilities; the latter may not support HTTP redirect for instance or even
> it may not support DNS. Therefore there is a need for a/ the dCND to
> announce/advertise its request routing capabilities and b/ for the uCDN to
> configure/select the dCDN request routing mode(s).
>
>
>
> This  would drive to the following two new objects :
>
>
>
> FCI.RequestRouting
>
> {
>
> MI.RequestRouting
>  <https://www.broadpeak.tv/>
>
>
>
>  <https://twitter.com/broadpeak>
>
>  <https://www.linkedin.com/company/broadpeak_2/>
>
>  <https://broadpeak.tv/>
>
>
>
>
>
> *From:* ALFONSO SILONIZ SANDINO <[email-masked]>
> *Sent:* Tuesday, May 18, 2021 4:10 PM
> *To:* Guillaume Bichot <[email-masked]>; Kevin Ma <
> [email-masked]>
> *Cc:* [email-masked]; FRANCISCO JOSE CANO HILA <
> [email-masked]>
> *   redirection mode described in [**RFC7336*
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7336&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102434808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a6QeuiOEJ5zDPDDmw%2FEU77hrs4ZRPwJ4CLyDj8pLiAM%3D&reserved=0>
> *]),*
>
>
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7736&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102434808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oaAPHJFgq%2BeofG%2BNstaXwQG0mhC%2F38mazBMpwhC1f1s%3D&reserved=0>]
> for the
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8008%23section-6&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102444771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Rv96bzDM9XXRANrFfTAaWW5GwFNzadKFS4cAJGzs6Rg%3D&reserved=0>
> ):
>
>
>
> ….
>
> *      discussed in [**RFC7336*
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7336&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102444771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AjKTyYDs0k%2BXOfQKe5wTckhzCaEvh5t5PK7NgWEH8dM%3D&reserved=0>
> *])*
>
>
>
>
>
> ·         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.
>
>
>
> 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.
> 3.       Define a new object in RFC8006 allowing the uCDN to select the
> 4.       Define a new redirection mode, let’s say *HTTP-I-MANIFEST*,
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.broadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102454721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V4VQ7vsA20K5twPqmZW78OHvNaCNNRC99ThK0AqTiSE%3D&reserved=0>
>
>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fbroadpeak&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102454721%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Sy%2BDiovW34GVcAUkA7mkgLDsGKn77v31XZe1Ti72LgE%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%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102464677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qDByl81ZgJgJDFUv%2BYkLVqHNQGq%2FZGOKRYUq%2Bz0X%2FqQ%3D&reserved=0>
>
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbroadpeak.tv%2F&data=04%7C01%7CGuillaume.Bichot%40broadpeak.tv%7C385028be031249353aae08d91a06a1d7%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637569438102464677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RzIOceFTs%2Br0f63%2Fanhpy1q56h1TuQkApKEiUzSRFdo%3D&reserved=0>
>
>
>
>