Re: [CDNi] Request for WG Adoption: Capacity Insights
Andrew Ryan <andrew@andrewnryan.com> Fri, 08 July 2022 16:30 UTC
Return-Path: <anr1@anr1.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 458C2C14F746 for <cdni@ietfa.amsl.com>; Fri, 8 Jul 2022 09:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.086
X-Spam-Level:
X-Spam-Status: No, score=-7.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=neutral reason="invalid (public key: not available)" header.d=andrewnryan.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 MijqHnbg69Bu for <cdni@ietfa.amsl.com>; Fri, 8 Jul 2022 09:30:11 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 86B85C14F733 for <cdni@ietf.org>; Fri, 8 Jul 2022 09:30:11 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id a26so558621qto.10 for <cdni@ietf.org>; Fri, 08 Jul 2022 09:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrewnryan.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=7RAZCo1oQNFggFz/+ywTtLsqaDDodsnhyd1NGoCLbH8=; b=wnVRQ93ujahNr89lryiy8qFfLFmo/tR2aKQ3dxdshjD/R+mNJ9SVads6mmGfsDhrKx lQ47ovJaZFCkE75+qKSm8omXwGLCr4b2Y21n1sCj4tNj6syXQlNJ5R96wYUIqFhT5bPj iPIAp1nWRbmhvzVU5qBrTA9CtQ12WQz2S/vaI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=7RAZCo1oQNFggFz/+ywTtLsqaDDodsnhyd1NGoCLbH8=; b=v8jFSm0X2gP1XwN2CjK5+RjxtNpn+MRxB6wyr2RMfl+YF+ALvZkO1G2juzyAvrWBiR wyci066zpEN1MJz1B1RGVkpRL+vRbUWGSbNYTWSXUMr5zsqxRjk/JDktvTxAsMj+CjE1 o+a7xmR/+566LKBOGziBc/oeVSv86YRr5mI27sFrIlN9JGOST1BwCD9qf9BP2z3xMlfe fcVEw/DBO6nv39N/PwmGfejuTSt3DhJuGbMlnuIPaQiCtE0bQD9NLsMLIcwpjuWgS2ct 2ZlWZihf2jwOb/Y7OqTxG/LeUSCoXBI7hQvM8AIRLRXiha4A//ekJ+mPXraoZLJZTQwl n2QA==
X-Gm-Message-State: AJIora8vPTmNNu2uGIFpPpfQfrWPjSrgcpADdddSx1RfRPTSg6alE/Xi tJS3WdSY/7mBX8VmyiUQU4vz1Nejhw4QHQ==
X-Google-Smtp-Source: AGRyM1uOdyWgG63KEztgdBYnVEhPr9jtcMjBm7vB9S58jii/4g+ImnInmRJ0tEqZMQFuygClgb32WQ==
X-Received: by 2002:a05:6214:cc7:b0:472:f2c1:cf4b with SMTP id 7-20020a0562140cc700b00472f2c1cf4bmr3490948qvx.79.1657297808927; Fri, 08 Jul 2022 09:30:08 -0700 (PDT)
Received: from [192.168.1.179] (cpe-72-228-183-169.buffalo.res.rr.com. [72.228.183.169]) by smtp.gmail.com with ESMTPSA id s12-20020a05620a16ac00b006a70f581243sm32499795qkj.93.2022.07.08.09.30.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jul 2022 09:30:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------rcp7fJFvSY80PGaGz5JbfDSC"
Message-ID: <59cc06ae-fb40-8b1a-8451-3d50cf013560@andrewnryan.com>
Date: Fri, 08 Jul 2022 12:29:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Kevin Ma <kevin.j.ma.ietf@gmail.com>
Cc: "cdni@ietf.org" <cdni@ietf.org>, ben@rosenblum.dev
References: <926af66d-e51b-3565-2099-f9344378f034@andrewnryan.com> <CAMrHYE3XUQrhxgZPuQi=xsGt7MMqjHUCk4JUBByXPT6DbxP04w@mail.gmail.com>
From: Andrew Ryan <andrew@andrewnryan.com>
In-Reply-To: <CAMrHYE3XUQrhxgZPuQi=xsGt7MMqjHUCk4JUBByXPT6DbxP04w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/AMorlEIAaNw_tKy7tLcVUPrQrOw>
Subject: Re: [CDNi] Request for WG Adoption: Capacity Insights
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: Fri, 08 Jul 2022 16:30:17 -0000
On 7/4/2022 12:35 PM, Kevin Ma wrote: > Hi Andrew, > > (As a chair) Given the reduced scope, i.e., just two FCI objects > (though see my comments below), I think adoption would be within scope > of the current charter if other folks feel this is good work for the > WG to take on. I don't have a problem with issuing a formal call for > adoption. I've included some comments on the current draft below. > > thanx. > > -- Kevin J. Ma > > section 1.3: > - In the new paragraph about the uCDN calling a dCDN API interface, > what interface is that? Is that an interface outside of CDNI. It's > not clear if that relates to anything in this particular draft? It > would be good to clarify this. The intention here was that the uCDN would interact with an interface which provides FCI payloads. To remove ambiguity I can remove the the reference all together: Original: In normal operation a uCDN will communicate with a dCDN, via an interface, to collect and understand any limits that a dCDN has set forth for traffic delegation from a uCDN Proposed: In normal operation a uCDN will communicate with a dCDN to collect and understand any limits that a dCDN has set forth for traffic delegation from a uCDN > > section 2.1.1: > - What is the scope of uniqueness for the id? If it needs to be > global, then it needs a registry. If it needs to be dCDN unique, then > it is just on the dCDN to ensure? @Ben keep me honest here, but the intention is that the ID be unique within the scope of the uCDN and dCDN, i.e. the namespace is specific to this CDNi delegation relationship.In this case, it would be up to the dCDN to ensure uniqueness in the payload that it is returning to the uCDN. > - the configuration descriptions references a yet to be defined > Telemetry Interface? Is that in the scope of this document? If not, > it would be good to clarify (or remove) this. The Telemetry interface is NOT in scope of this document, we can add clarifying language to explicitly state this. In Section 2.1.1.1 an additonal sentence can be added: Proposed: The definition of a CDNI Telemetry interface is outside the scope of this document. > > section 2.1.1.1 <http://2.1.1.1>: > - Should there be a registry for telemetry source types? Will these > be globally unique and well specified (in an RFC?) for interoperability? @Ben I do think we will want a registry for telemetry source objects. The declaration of a "generic" type was meant as a place holder until a formal Telemetry Interface was defined. The Generic source type also allows CDNs which already have an existing relationship and have already established data channels for providing and consuming Telemetry to be used "as is" without requiring additional integration steps. > > section 2.1.1.2 <http://2.1.1.2>: > - What happens if there are duplicate names in a source object? I think the intention behind declaring that the name needs to be unique circumvented any discussion on how to handle duplicate names > - Is there a valid range for time-granularity, data-percentile, > and/or latency, e.g., 0-31622400, 0-100, and/or 0-2678400, > respectively? And what happens if values are out of range? The intention is that these are meant to provide guidance to the uCDN in terms of how accurate and how far behind real time the data set is, to help inform how to react from a traffic steering perspective. In terms of valid ranges, I think the data-percentile would have a natural range of 0-100. The others, I believe would not necessarily have a bound (outside of integer limits). The usefulness of very large time-granularity and latency values somewhat diminish the usefulness of this data for near real time traffic steering decisions. > > section 2.2.1: > - "CAN" is not an RFC2119 term. "CAN" -> "MAY"? Understood, we will work to change this > - What is the scope of uniqueness for the id? If it needs to be > global, then it needs a registry. If it needs to be dCDN unique, then > it is just on the dCDN to ensure? This should be unique between the uCDN and dCDN > - Are there limits related to maximum-hard, maximum-soft, and > current? Should those be specified along with the capacity limit > types? And what happens if values are out of range? I am not sure we want to introduce an artificial cap outside of the definition of the Integer itself as this will allow for the most flexibility and hopefully prevent having to revisit the draft to increment values in the future. > - section 2.2.1 already defines a "Telemetry Source Object"; can we > come up with a different name to make it less confusing? @ben ^^ > > section 2.2.1.1 <http://2.2.1.1>: > - Should there be a registry for capacity limit types? Will these > be globally unique and well specified (in an RFC?) for interoperability? I do believe this would make sense and part of the intention of defining it in this draft was an attempt to address that. If there is a more appropriate way to accomplish this, I would welcome guidance. > > section 2.2.1.2 <http://2.2.1.2>: > - so, these are pointers back into a "Telemetry Source Object"? > What happens if the reference is not found? @Ben we will need to discuss this case. It might be enough to require that dCDNs ensure consistency in this manner, and if not, the payload could be rejected by the uCDN. > > section 2.2.1.3 <http://2.2.1.3>: > - This is subdividing a footprint? Would it make more sense (or at > least be simpler) to just define more granular footprints. It seems > confusing to make essentially another way specify footprints. This was a very lengthy part of our discussion in this draft. There are use cases where "all traffic is not created equal" i.e Low Latency HLS will have much different request characteristics than Bulk game downloads or even Video On Demand. The CDNi Footprint object doesn't allow for granularity on a published host basis. We were working under the fundamental premise that we were trying to cause as little disruption to the fundamental components of CDNi and trying to encapsulate as much as we could related to capacity management without major overhauls to the original spec. We would greatly welcome discussion on this topic. > > section 4: > - I think there should probably be discussions of the potential > attacks if the data is intercepted/spoofed. Would there be any additional considerations outside of what is already established for FCI in general? > - I think we also need a privacy section that discusses the > potential issues of divulging internal information about the CDN. part of the data requirements are such that the data for capacity is scoped specifically to the uCDN,->dCDN delegation relationship..i.e. the data is very narrowly scoped. The data being presented is also data about the dCDN by the dCDN. Would there be any suggestions on how we might want to frame a statement for this? > > nits: > > section 1.3: > "it's current usage" -> "its current usage" > "uCDN of limits of" -> "uCDN limit on" > ", so that the uCDN can use to" -> " so that the uCDN can use it to" > " i.e. " -> ", i.e., " > "In the event that a" -> "In the event a" ACK > > section 2.1: > "CDNi" -> "CDNI" > "reference, allows" -> "reference allows" > "non ambiguous metric use use" -> "non ambiguous metric use be used" > "current usage and how" -> "current usage. How" > "to it's dCDN" -> "to its dCDN" > ack > section 2.1.1.2 <http://2.1.1.2>: > " . I.e. is" -> ", e.g., is" > "5 minutes" -> "300 seconds (i.e., 5 minutes)" > "one hour" -> "3600 seconds (i.e., one hour)" > > ack > > > On Tue, Apr 5, 2022 at 9:08 AM Andrew Ryan <andrew@andrewnryan.com> wrote: > > Greetings, > > Similar to the recent solicitation for adoption of the CDNI > Metadata > Model Extensions, I would like to submit a draft for consideration of > adoption: > > https://datatracker.ietf.org/doc/draft-ryan-cdni-capacity-insights-extensions/ > > The draft outlines extensions to the FCI payload registry, which will > enable communication of Capacity/Delegation limits between a uCDN and > dCDN. This draft has been presented at IETF 111, IETF 112 and most > recently at IETF 113 from which we have incorporated some great feed > back into several revisions of the draft. > > I look forward to any feedback and/or support for the adoption of > this > draft. Thank you very much for your time. > > Andrew Ryan > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >
- [CDNi] Request for WG Adoption: Capacity Insights Andrew Ryan
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Chaudhari, Pankaj
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Guillaume Bichot
- Re: [CDNi] Request for WG Adoption: Capacity Insi… ALFONSO SILONIZ SANDINO
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Kevin Ma
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Andrew Ryan
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Kevin Ma
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Andrew Ryan
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Kevin Ma
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Kevin Ma
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Andrew Ryan
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Kevin Ma
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Andrew Ryan
- Re: [CDNi] Request for WG Adoption: Capacity Insi… Andrew Ryan
- Re: [CDNi] [E] Re: Request for WG Adoption: Capac… Mishra, Sanjay
- Re: [CDNi] [E] Re: Request for WG Adoption: Capac… Kevin Ma