Re: [CDNi] Request for WG Adoption: CDNI Metadata Model Extensions
Kevin Ma <kevin.j.ma.ietf@gmail.com> Sat, 09 July 2022 14:53 UTC
Return-Path: <kevin.j.ma.ietf@gmail.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA96C14F74A for <cdni@ietfa.amsl.com>; Sat, 9 Jul 2022 07:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JekNWZHccnJr for <cdni@ietfa.amsl.com>; Sat, 9 Jul 2022 07:53:52 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80463C14F740 for <cdni@ietf.org>; Sat, 9 Jul 2022 07:53:52 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id a15so1329490pfv.13 for <cdni@ietf.org>; Sat, 09 Jul 2022 07:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0eZ/ZId4foNYF7ftBXeX+wSoekoPxm9r0GtY8nUGTWo=; b=HYbXuuXXMeRmjyYmEfXT8oRuiTU+F2sIekGupsP6pVRx08UoshZRAN8bZR8p4IhHVi xap2kcTsbdldUlysTmSy1skKlKkp5G0W6LW6NH8TjulKZdnmI6+ZPFzOgNdFvTDW72ea aBaCtWE628xW1YnpDAe/sju9Ogr4rVtB06xnym54iRS2XIUFYEXP87sqqEttNo9f/ngL A6nigTex+dkI4RQh9u2ULGnQA/+WsPAk1pzGb3x5GmG2jVS2W3YbfRenu2eS4bnb6maZ GNk+j4LU/bjuAk1z6rYTyKrlsBU/y7GLquAYFkb24a5mlwM6lwWHr3fuvDEiQSfYKjBQ 7sQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0eZ/ZId4foNYF7ftBXeX+wSoekoPxm9r0GtY8nUGTWo=; b=HzVj8g4bKub37b1DYbHhSDm0q1WqeX31wA+DmjZ08xUTKBCegIqCnzCUQrYlNeKZR5 dudwtuknHlmW1r8C9Fryf98jZUI1FBpUVoo1RepNDulPUO3rUbfJzfgVW90CFh+sFWg4 1g+u6HWpaU5wQhHhx7+GAJYsxUKurDrTL752BQ9Bw4fimfE/+GJOrlCGGCioV9dwqw0x SoPq6aGYakCxJZiCQ8YGIv391rpopasJBwc70s+1HO1/gfwfkHP4T4Wflcgtv027GBpw l4YhXYZpCgERtbj4kPiVxvOtdfD2pxIx3G3WAntXdbk6pWI3+3zclTtNAR5k754U9rt1 jpyQ==
X-Gm-Message-State: AJIora/v3yRv2c9DBNTAakNsPBEixPHrfnHq2D74TEJ8eH6pAJFxsiD1 Lg9e/UsQDKLYJvLaP7wKy8dEYHGGuCVOp9UYmlkX2nwZ
X-Google-Smtp-Source: AGRyM1saa1SAjztnVVQj/lBcbA9kfMYHq2GMofNoSmkc0P/L/AYrZOGQgsS9C1W2SmO8qO/ff1JXGYj7+34WEqS392Q=
X-Received: by 2002:a62:2544:0:b0:52a:c1dd:8837 with SMTP id l65-20020a622544000000b0052ac1dd8837mr633611pfl.85.1657378431263; Sat, 09 Jul 2022 07:53:51 -0700 (PDT)
MIME-Version: 1.0
References: <7BEFC506-E2F6-4C2E-8946-6912C247902A@telefonica.com> <CAMrHYE3ZdBLD6dQ_p0ErhGbLP3yJe0Dc4UvHgKW8cu7PN6R5uQ@mail.gmail.com> <450F892D-0511-4692-92F2-8983DC1614A7@telefonica.com>
In-Reply-To: <450F892D-0511-4692-92F2-8983DC1614A7@telefonica.com>
From: Kevin Ma <kevin.j.ma.ietf@gmail.com>
Date: Sat, 09 Jul 2022 10:53:40 -0400
Message-ID: <CAMrHYE0J0NdVh04Q3LRRSse94WHXr7qyuNZ3EbuKXe5H6ycgpA@mail.gmail.com>
To: ALFONSO SILONIZ SANDINO <alfonso.siloniz.ext@telefonica.com>
Cc: "cdni@ietf.org" <cdni@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a768c605e3607c86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/y9CxRn6tCfuYPJfwaG8W1CdNkqw>
Subject: Re: [CDNi] Request for WG Adoption: CDNI Metadata Model Extensions
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jul 2022 14:53:56 -0000
Sounds good. Thanks Alfonso! On Thu, Jul 7, 2022 at 10:19 AM ALFONSO SILONIZ SANDINO < alfonso.siloniz.ext@telefonica.com> wrote: > Hi Kevin, > > > > Sorry for the late response. > > > > Thank you for your comment. Indeed this is something we are going to do > definetively, although probably will not arrive for IETF-114. So hopefully > we will submit a new version of the draft splitted up after that. > > > > Best regards, > > > > Alfonso > > > > > > *De: *Kevin Ma <kevin.j.ma.ietf@gmail.com> > *Fecha: *lunes, 4 de julio de 2022, 18:58 > *Para: *ALFONSO SILONIZ SANDINO <alfonso.siloniz.ext@telefonica.com> > *CC: *"cdni@ietf.org" <cdni@ietf.org> > *Asunto: *Re: [CDNi] Request for WG Adoption: CDNI Metadata Model > Extensions > > > > Hi Alfonso, > > > > I think there is a lot of good work in the draft. I'll reiterate > though that the draft is a bit dense, and I think it would benefit from > being split up at least into a set of non/less controversial metadata that > could easily be reviewed and approved (similar to the work on request > routing and footprints) and the more intricate processing stage content > (which I personally think is interesting and a good addition and callout on > the original metadata model, but will likely take more iteration to > converge). > > > > thanx! > > > > -- Kevin J. Ma > > > > On Thu, Mar 24, 2022 at 4:42 AM ALFONSO SILONIZ SANDINO < > alfonso.siloniz.ext@telefonica.com> wrote: > > Hi All, > > > > Following the discussion during IETF 113 meeting, after the changes made > to the draft attending different comments after IETF 112 meeting, I would > like to ask for the group to make this draft an adopted CDNi WG document. > > > > The latest version of the draft can be found here > <https://datatracker.ietf.org/doc/draft-goldstein-cdni-metadata-model-extensions/> > > > > About Kevin suggestion of breaking out this draft on smaller parts I think > is a very fair point that we will discuss with our colleagues in the SVA > Open Caching WG, as we want to maintain alignment in the OC documentation > with the drafts presented to CDN-I for easier referencing. > > > > As for Sanjay suggestion, I add here the list of comments to the previous > version and our responses that were in our slidedeck for the meeting but > for the sake of time was not possible to present in detail. > > > > Please, let us know if you agree or disagree with this adoption. And feel > free to make any additional comment. > > > > Best Regards, > > > > Alfonso Siloniz > > > > > > *draft v01* > > *draft v02* > > *Question* > > 2.2 > > 2.3.2 > > add cross reference for HeaderTransform > > Missing in v2. Set for v3 > > 2.2 > > 2.3.2 > > MI.AllowCompress: Without this metadata today, a dCDN is free to choose to > compress? t feels more natural to make the default true or change the > metadata to DisallowCompress? Otherwise, without an FCI advertisement of > whether the dCDN supports the metadata, it's hard to know what its default > behavior will be? > > Without it, there is no enforcement from the uCDN about dCDN behavior for > compression. The purpouse of the functionality is to force compression in > dCDN independently of how the uCDN content has been acquired. Agreed > probably the name does not reflect precisely the functionality, and > something like EdgeCompress or ForceCompress would be more suitable. In > discussion in the SVA OCWG > > 2.3 > > 2.1.1 > > I'm curious about the use case. The uCDN could just set the desired cache > policy in the response, rather than setting the metadata. Is the primary > use case where the uCDN does not want to set the cache policy in each > response and wants a default in the metadata? Or is there something else? > Is it to have a push interface (note: the triggers API provides a way to > invalidate)? > > Cache Control directives condition how any cache system in the path > between the uCDN origin and the user agent should behave. As the uCDN can > only use one specific Cache-Control header, it has no flexibility to > control the TTL of the objects in a dCDN cache. It would be the same for > the dCDN cache and for an intermediate cache system. > > As the uCDN can have control over the objects the dCDN stores (as with the > trigger interface mentioned) it can be of the uCDN interest to have a > longer TTL for the dCDN Caches (so there is less traffic to the uCDN > origins) but having a smaller TTL for the end users. Thus, the dCDN > supports a higher impact on requests, protecting the uCDN origin. For that, > CachePOlicy permits to define modifications on the Cache-Control directives > sent by the uCDN origin. Apart of that, the force property permits to > mandate the dCDN to use those values only in the case the uCDN origin does > not set the Cache Control directives. (as a default value) > > *draft v01* > > *draft v02* > > *Question* > > 2.2 > > 2.3.2 > > add cross reference for HeaderTransform > > Missing in v2. Set for v3 > > 2.2 > > 2.3.2 > > MI.AllowCompress: Without this metadata today, a dCDN is free to choose to > compress? t feels more natural to make the default true or change the > metadata to DisallowCompress? Otherwise, without an FCI advertisement of > whether the dCDN supports the metadata, it's hard to know what its default > behavior will be? > > Without it, there is no enforcement from the uCDN about dCDN behavior for > compression. The purpouse of the functionality is to force compression in > dCDN independently of how the uCDN content has been acquired. Agreed > probably the name does not reflect precisely the functionality, and > something like EdgeCompress or ForceCompress would be more suitable. In > discussion in the SVA OCWG > > 2.3 > > 2.1.1 > > I'm curious about the use case. The uCDN could just set the desired cache > policy in the response, rather than setting the metadata. Is the primary > use case where the uCDN does not want to set the cache policy in each > response and wants a default in the metadata? Or is there something else? > Is it to have a push interface (note: the triggers API provides a way to > invalidate)? > > Cache Control directives condition how any cache system in the path > between the uCDN origin and the user agent should behave. As the uCDN can > only use one specific Cache-Control header, it has no flexibility to > control the TTL of the objects in a dCDN cache. It would be the same for > the dCDN cache and for an intermediate cache system. > > As the uCDN can have control over the objects the dCDN stores (as with the > trigger interface mentioned) it can be of the uCDN interest to have a > longer TTL for the dCDN Caches (so there is less traffic to the uCDN > origins) but having a smaller TTL for the end users. Thus, the dCDN > supports a higher impact on requests, protecting the uCDN origin. For that, > CachePOlicy permits to define modifications on the Cache-Control directives > sent by the uCDN origin. Apart of that, the force property permits to > mandate the dCDN to use those values only in the case the uCDN origin does > not set the Cache Control directives. (as a default value) > > *draft v01* > > *draft v02* > > *Question* > > 2.6 > > 2.1.2 > > "it may be desirable to cache error responses at the uCDN for a short > period of time to prevent an overwhelmed origin service from being flooded > with requests"? Replace 's/uCDN/dCDN/' and 's/origin service/uCDN/' ? > > Could the uCDN specify the cache policies in the response? > > Removed that sentence. > > For the second questions: Same case as for MI.CachePolicy above. In fact, > this could be considered a particular case of the MI.CachePolicy for > errors. The uCDN can of course set the cache control directive for those > errors. But it is typical the uCDN prefers to protect its origin server of > a flood of requests when a non-desirable situation occur (an HTTP 500 error > for example), but wanting the UA to try a faster revalidation. Other > example, in the opposite way: A video fragment is not available yet in the > uCDN Origin but published in a manifest (Live DASH). The UA requests a > video fragment to the dCDN, and the dCDN requests it to the uCDN. When > having an HTTP 404 error (because maybe the object is in the process of > being available in the origin). If it sets a max-age of 10s in the > response, the dCDN will not revalidate the object until 10 seconds has > passed, so every UA trying to get the object will receive a 404 during 10 > seconds. But maybe the resource became available after just 1 second of the > first request. The first UA that requested the fragment will wait 10s to > get it again, but the rest of UA trying to access the same fragment will > get it right away. > > 2.7 > > 2.1.4 > > Is the intent that this metadata would be pulled from the uCDN on every > request and that the uCDN would made decisions based on the requestor: > "CacheBypassPolicy only applies to the current request"? Though not > explicity prohibited by the MI, it goes a bit beyond the original intent of > the metadata cacheability. > > Corrected the description. No relationship with the UA current request. > This metadata applies after is received in a configuration, for all the > requests that arrived since that moment that match the MI.ExpressionMatch > and onwards. For the same resource requested, the dCDN can have a cached > copy for those requests that don´t match the condition, while requesting a > new copy for those that match. > > 2.8.1 > > 2.3.4.1 > > Combine the two Mandatory-to-Specify bullets? > > Corrected > > *draft v01* > > *draft v02* > > *Question* > > 2.9.1 > > 2.5.2.1 > > Do you envision a registry for the private features? > > By definition, the possible PrivateFeatures are implementation specific. > As there could be a great variability on the possible properties we have > not discussed the idea of having a registry. An uCDN configuring a > HostMatch on multiple dCDNs should send a MI.PrivateFeatures metadata in > the configuration only for those that support it, and the content > particularized for each of those. As being a point to point configuration > does not seem needed to have a registry. > > 2.12 > > 2.5.3 > > I would expect the type to come from the redirection modes registry (*https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml#capabilities-redirection-modes > <https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml>* > )? > > It is not exactly the same. FCI.RequestRouting and MI.RequestRouting are > related to how the dCDN will make the Request Routing internally to direct > the user to the suitable streamer. In the reference mentioned, the types > HTTP-I or HTTP-R include the interative or recursive methods, while the > internal request routing in a dCDN is independent of those techniques. > > The most typical use case is that a uCDN make a Traffic delegation using > DNS-I or DNS-R, but wants to be sure that the dCDN is not going to do a > internal HTTP redirection. Thus, sending MI.RequestRouting as “DNS” force > the dCDN to use DNS RR internally and to avoid HTTP 302. > > 2.13 > > 2.5.1 > > I'm not clear what the two tiers are. In the case of a static ID, would > the existing ccid metadata (*https://datatracker.ietf.org/doc/html/rfc8006#section-4.2.8 > <https://datatracker.ietf.org/doc/html/rfc8006>*) suffice? > > Description expanded to clarify that point. This extension permits to > identify services AND properties in the service. So in the case of a static > ID without any property identification, Grouping could be sufficient. > > *draft v01* > > *draft v02* > > *Question* > > 2.14.1 > > 2.2.1.1 > > For ease of understanding, should probably just duplicate the > acquistion-auth, endpoints, and protocol properties > > Done > > 2.14.2 > > 2.2.1.2 > > - section 2.14.2: Is the intent to create a registry for load balancing > algorithms? > > In discussion > > 2.16 > > 2.3.3 > > "vod" and "live" are fairly video specific; could this be more generically > categorized? is the intent to convey information about source acquisition > (e.g., you may have to wait for live content to become available vs you may > be able to prefetch vod), delivery pacing or rate limiting, both, neither, > or other? > > The intention is related to the content delivery, not the content > acquisition. In HTTP Adaptative Streaming protocols, the behaviour of the > end users consumers (aka ‘players’) is quite different and it affects the > content delivery resources depending on this type. While a live content is > mainly RAM consuming, a VoD content is storage consuming. CDNs typically > can apply different optimizations, including using different hardware > elements depending on the type of the content. Thus, it is very important > that in video streaming processes the dCDN knows that information in > advance so it can apply those strategies, so the QoE will be superior. > > > > > ------------------------------ > > > 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 confidential and > privileged 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 > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > ------------------------------ > > 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 confidential and > privileged 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 >
- [CDNi] Request for WG Adoption: CDNI Metadata Mod… ALFONSO SILONIZ SANDINO
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Goldstein, Glenn
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Matthew Stock
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Guillaume Bichot
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Andrew Ryan
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Chaudhari, Pankaj
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Kevin Ma
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… ALFONSO SILONIZ SANDINO
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Kevin Ma
- Re: [CDNi] Request for WG Adoption: CDNI Metadata… Goldstein, Glenn
- Re: [CDNi] [E] Re: Request for WG Adoption: CDNI … Mishra, Sanjay