[alto] Artart last call review of draft-ietf-alto-cdni-request-routing-alto-16
Reviewer: Thomas Fossati
Review result: Ready with Nits
# Abstract
I suggest to slightly increase the precision:
OLD
[...] This document defines an FCI
protocol using the Application-Layer Traffic Optimization (ALTO)
protocol, following the guidelines defined in RFC 8008.
NEW
[...] This document defines a new Application-Layer Traffic
Optimization (ALTO) service called "CDNI Advertisement Service" that
provides an implementation of the FCI, following the guidelines
defined in RFC 8008.
# Section 2.1
While, in general, I have found the introduction and background section to
contain very clear and valuable information about context, rationale and
high level requirements and features, I am having some trouble parsing
this bit:
[...] Multiple
footprint constraints are additive, i.e., the advertisement of
different types of footprint narrows the dCDN candidacy
cumulatively.
Maybe it's just me, but I'd have appreciated if you could unpack this a
little.
# Section 2.2
For identification it's not the integrity property of signatures that
you care about but origin authentication:
OLD
o Security: The identification between uCDNs and dCDNs is an
important requirement. ALTO maps can be signed and hence provide
inherent integrity protection. Please see Section 8.
NEW
o Security: The identification between uCDNs and dCDNs is an
important requirement. ALTO maps can be signed and hence provide
inherent origin authentication. Please see Section 8.
It is not clear to a newcomer why a RESTful design is listed as one of
the criteria for choosing ALTO. Please be more specific about the
advantages. E.g., it's a good fit with the rest of the CDNI suite and
therefore reduces the cognitive dissonance for users and developers
alike? It allows at least some level of code reuse?
Typo:
OLD
[...] A CDNI FCI interface based on ALTO
would inherit this this extensive error-handling framework.
NEW
[...] A CDNI FCI interface based on ALTO
would inherit this extensive error-handling framework.
At this point in the document it may not be necessarily evident what
"the new endpoint property for ALTO" is -- at least to a newcomer. I
suggest sticking a reference to I-D.ietf-alto-unified-props-new when
the term is first introduced.
# Section 3
I suggest adding a note regarding I-JSON (as per RFC 8008).
# Section 3.1
Is this the only CDNI interface envisaged in ALTO? If the answer is
either "no" or "I don't know", it's probably better being more specific
WRT the name choice of the media type -- e.g.,
"application/alto-cdni-advertisement+json"?
# Section 3.2
Is there any specific recommendation regarding caching of these
resources?
# Section 3.5
The "uses" field SHOULD NOT appear unless the CDNI Advertisement
resource depends on other ALTO information resources
If the semantic of uses is not defined without an explicit resource
dependency why should you allow that? I.e., why is this not a MUST NOT
rather than just a SHOULD NOT?
# Section 3.6
Expand IRD. Maybe a better place to introduce the acronym is in Section
3.
What is the semantics of a CDNIAdvertisementData with empty
capabilities-with-footprints? (I suggest you provide a one-liner that
presents the context in which that would be meaningful.)
What is the semantics of ""global" coverage"? Is it what is
contractually (i.e., OOB) defined for the dCDN?
This text:
To be self-contained, below is a non-normative specification of
BaseAdvertisementObject.
I don't understand the "non-normative" bit: isn't this normatively
describing the syntax that implements the semantics defined in the CDNI
doc?
I am having a hard time parsing this text:
Note: Further optimization of BaseAdvertisement objects to
effectively provide the advertisement of capabilities with footprint
restrictions is certainly possible.
what optimisation are hinted here? And what is their relation with the
examples? Are those associated with the use of altopid? If so, you
should consider adding a forward reference to section 4.1 here.
# Section 3.7.3
Typo:
OLD
due to maintenance of the https/1.1 clusters
NEW
due to maintenance of the http/1.1 clusters
# Section 3.7.3
At the end of:
A benefit of using ALTO to provide CDNI Advertisement resources is
that such resources can be updated using ALTO incremental updates
maybe add a reference to RFC8895 (also, I think RFC8895 should be
normatively referenced rather than just informatively?)
There seems to be a typo in the example:
OLD
data: "capabilities": [
data: {
data: "capability-type": "FCI.DeliveryProtocol",
NEW
data: "capabilities-with-footprints": [
data: {
data: "capability-type": "FCI.DeliveryProtocol",
# Section 5.3
The definition:
[CDNIFCICapability cdni-capabilities<0..*>;]
looks a bit odd. I'd have thought one of
Re: [alto] Zaheduzzaman Sarker's No Objection on charter-ietf-alto-04-01: (with COMMENT)
Hi Zahed, The original use case for ALTO -- peer to peer -- is largely dead. The current charter's work supports the new CDN Interconnect use case. It is too early to see how this affects adoption of ALTO, and I'm not convinced we understand the current level of ALTO adoption. So, this charter focuses on closing loose ends on the existing ALTO work while we mature our understanding of the demand of for further extensions. Martin On Thu, Aug 26, 2021 at 5:31 AM Zaheduzzaman Sarker via Datatracker < nore...@ietf.org> wrote: > Zaheduzzaman Sarker has entered the following ballot position for > charter-ietf-alto-04-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-alto/ > > > > -- > COMMENT: > -- > > I see a need for protocol maintenance and potential extensions based on the > deployment experience. > > However, for future protocol usage I don't think there is a need to a > working > group. This actually even puts doubts about potential direction that the > working group will take, hence not a deterministic focus or item that the > working group can deliver on. I mean to say, the future discussions can be > separated and might result in - ALTO is not a good fit for the future > usages. > > Also, as far as I understand ALTO uses the HTTP semantics hence the h2/h3 > adoption seems like a implementation choice on the ALTO server. Should > there > any issues on that adoption, that should be covered in the maintenance and > extension bullet based on current deployment. > > Having said that, I wont block this rechartering but would suggest to > rethink > about the focuses set on the charter. > > > > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)
Hi Eric, I've edited the charter to reflect your concerns. On Thu, Aug 26, 2021 at 5:48 AM Qin Wu wrote: > Thanks Eric, see comments inline below. > -邮件原件- > >发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] > >发送时间: 2021年8月26日 14:06 > >收件人: The IESG > >抄送: alto-cha...@ietf.org; alto@ietf.org > >主题: Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT) > > >Éric Vyncke has entered the following ballot position for > >charter-ietf-alto-04-01: No Objection > > >When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > >The document, along with other ballot positions, can be found here: > >https://datatracker.ietf.org/doc/charter-ietf-alto/ > > > > -- > >COMMENT: > -- > > >While I still wonder whether there is a need for a ALTO 'extension' > working group, I do not object the rechartering. > [Qin]: Yes, ALTO operational support doesn't require ALTO protocol > extension, ALTO over HTTP3 needs to be investigated to see whether the > protocol extension or just guidance is required? > Even protocol extension is not needed, guidance on ALTO over HTTP2 or > HTTP3 is still useful, e.g., how multiple stream carried in one connection > can be leverage to support SSE. > See section 4 of RFC8650 > " > 4. QoS Treatment > >Qos treatment for event streams is described in Section 2.3 of >[RFC8639]. In addition, if HTTP/2 is used, the publisher MUST: > >* Take the "weighting" leaf node in [RFC8639] and copy it into the > HTTP/2 stream weight, Section 5.3 of [RFC7540], and > >* Take any existing subscription "dependency", as specified by the > "dependency" leaf node in [RFC8639], and use the HTTP/2 stream for > the parent subscription as the HTTP/2 stream dependency (as > described in Section 5.3.1 of [RFC7540]) of the dependent > subscription. > >* Set the exclusive flag (Section 5.3.1 of [RFC7540]) to 0. > >For dynamic subscriptions with the same Differentiated Services Code >Point (DSCP) value to a specific publisher, it is recommended that >the subscriber sends all URI GET requests on a common HTTP/2 session >(if HTTP/2 is used). Conversely, a subscriber cannot use a common >HTTP/2 session for subscriptions with different DSCP values. > " > As an example, HTTP 1.1 and HTTP 2.0 actually introduce different QoS > treatment. > > >Nevertheless I am puzzled by the apparent conflict of a YANG model > milestone and the sentence "This *may* include YANG models and OAM > mechanisms"... > [Qin]: Okay, will see how to fix it. > >About the protocol extensions for H/2 and H/3, does it imply the use of > multistreaming ? > [Qin]: I think some design guideline should be investigated, e.g., > multiple stream multiplexing is one feature that can be leveraged to > enhance SSE, maybe there are other design principles here, e.g., ALTO over > HTTP over QUIC features > I will ask ALTO proponents to chime in to comment on this. > >One minor nit: please introduce OAM at first use. > [Qin]: Thanks. > > > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] charter-ietf-alto-04-01
Hi Lars, I'm initiating a discussion about the value of the document deliverables in the charter. Meanwhile, I've already edited the charter to be a little more explicit why the routing WG activities are called out in the text. Thanks for your comments. On Thu, Aug 26, 2021 at 7:46 AM Peng Liu wrote: > Hi all, > > Indeed, Amin's speech in sigcomm NAI 2021 inspired me a lot. I hope ALTO > can be rechartered to cover more networking use cases, such as our > computing aware networking use case and requirements. we really want to > investigate how ALTO can be integrated into our work and serve as one of > key components in our framework. Yes, we are looking for more help and > input on this topic. > > Regards, > Peng > > Peng Liu | 刘鹏 > China Mobile | 移动研究院 > mobile phone：13810146105 > email: * liupeng...@chinamobile.com * > > > *From:* Y. Richard Yang > *Date:* 2021-08-24 22:42 > *To:* Lars Eggert > *CC:* IETF ALTO ; alto-cha...@ietf.org; Qin Wu > ; The IESG > *Subject:* Re: [alto] charter-ietf-alto-04-01 > Hi Lars, > > I saw your comment and have to chime in. > > I have to respectfully disagree with your assessment: "Overall, I remain > unconvinced that there is sufficient work/interest in this space to warrant > a chartered WG." I am not sure if you attended the NAI@SIGCOMM'21 > Workshop yesterday. There was clearly a huge interest and work in the > space. The title of Amin Vahdat's talk is "Application-Defined Networking", > as "It now opens the next wave of opportunities toward Application-Defined > Networking, Where application efficiency metrics drive network control > configuration policy, Integration into compute and storage infrastructure→ > job placement, replication, Visibility into distributed systems structure, > including Load Balancing, Thread Scheduling, RPCs, RDMA, and Collectives", > using the sentences from the keynote. Now, let's go more specific to ALTO > and to engineering. The work of Flow Director, in the scope of ALTO, was > reported in CoNEXT'19 (https://gsmaragd.github.io/publications/CoNEXT2019/). > Luis mentioned ongoing deployment efforts at Telefonica; there is the > on-going deployment of ALTO at the Greater Bay Network, which is a large, > among the most-advanced networks covering Shenzhen, Hong Kong; there is the > ongoing MoWIE work, based on and the need to extend ALTO, by China Mobile > and Tencent... I agree that ALTO is far far far from taking over the > world, but I have a totally different assessment. > > If when you say that there is not sufficient work, you mean that *the > charter* does not include sufficient work. This is by design and good > guidance: the WG substantially limits the scope of the recharter to > consolidate the WG in the short term, and there was a huge disappointment > from many industry parties on the removing of their work from the charter > discussions---not sure if you attended some of the recharter discussions, > there was a large amount of proposed work but they were mostly removed. > > Please see below. > > On Tue, Aug 24, 2021 at 9:29 AM Lars Eggert wrote: > >> Hi, >> >> On 2021-8-24, at 16:07, Qin Wu wrote: >> > Thank you for reviewing the proposed re-charter of the ALTO working >> group. >> >> > > It's not clear to me why this effort would need a chartered WG vs. >> just a >> > > mailing list and/or a wiki. >> > > A chartered WG has many benefits. As one example, multiple participants > spend huge efforts on the ALTO work and bring "human resources" to IETF; an > informal mailing list/wiki will be harder to justify the efforts. I assume > that many IETF WGs can also operate mostly as a mailing list/wiki; then the > participation can be lower, it will be harder to maintain scope, to meet > deadlines. We feel that the WG recharter has wonderful guidance to be > focused, to be timely. > >> >> > >> o Develop operational support tools for ALTO. >> > > >> > > See above. > > >> > > I'm not aware of any larger-scale product deployments of ALTO - do >> some exists? >> > > See some examples above. > > > > Otherwise, I question whether operational tools can effectively be >> developed >> > > without relevant operational experience. > > >> > There is big suggestion that the reason for no larger-scale product >> deployment of ALTO is because missing operational support tools. >> > It is big mistake to make protocol without operational support. >> > We saw this happen many times with OAM added much later. It make the >> protocol hard to use and is bad for operator. >> >> Would you point me at a discussion where this lack of operational support >> was brought up by a potential large-scale deployer as a reason to not >> deploy ALTO? >> >> > The issue of lacking operational support was not proposed by academics, > but by people from the operator sides, during ALTO meetings, e..g., by Lyle > Bertz (T-Mobile), Luis (Telefonica). The main complexity discussed by the > Steering Giants report was mostly operational. > > > >> o Support for modern
Re: [alto] Benjamin Kaduk's No Objection on charter-ietf-alto-04-01: (with COMMENT)
HI Ben, I edited the H/2 and 3 bullet to read as follows: o Support for modern transport protocols. ALTO only uses the capabilities of HTTP version 1. While ALTO can operate successfully over any version of HTTP, it would benefit from leveraging HTTP/2 and HTTP/3 capabilities such as push. The WG will produce an ALTO extension that leverages these capabilities if they can be shown to improve performance. It more accurately states the current status. On Thu, Aug 26, 2021 at 6:34 AM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > charter-ietf-alto-04-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-alto/ > > > > -- > COMMENT: > -- > > o Support for modern transport protocols. ALTO only uses the > capabilities of HTTP version 1. Since then, the IETF has developed > HTTP/2 and HTTP/3. The working group will develop any necessary > protocol extensions and guidance to support the use of ALTO over HTTP/2 > and HTTP/3. > > The IESG is reviewing on this same telechat a "bis" version of BCP56, > guidelines for applications using HTTP. Let's discuss whether this > language is consistent with the guidance contained therein, which > includes: > >[...] Requiring a particular >version of HTTP makes it difficult to use in these situations, and >harms interoperability. Therefore, it is NOT RECOMMENDED that >applications using HTTP specify a minimum version of HTTP to be used. > >However, if an application's deployment would benefit from the use of >a particular version of HTTP (for example, HTTP/2's multiplexing), >this ought be noted. > > My understanding is that typically it suffices to "just use HTTP", and > that there should be no need for ALTO extensions to support running the > protocol over HTTP/2 or HTTP/3. Any HTTP-version-specific work would > then be about making more effective use of features that are available > in those later versions, without requiring them to be available, or > perhaps (hopefully not) fixing issues with the original ALTO specification > that caused it to not be HTTP-version-agnostic. > > > > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
