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 <liupeng...@chinamobile.com> 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 <liupeng...@chinamobile.com>* > > > *From:* Y. Richard Yang <y...@cs.yale.edu> > *Date:* 2021-08-24 22:42 > *To:* Lars Eggert <l...@eggert.org> > *CC:* IETF ALTO <alto@ietf.org>; alto-cha...@ietf.org; Qin Wu > <bill...@huawei.com>; The IESG <i...@ietf.org> > *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 <l...@eggert.org> wrote: > >> Hi, >> >> On 2021-8-24, at 16:07, Qin Wu <bill...@huawei.com> 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 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. >> > > >> > > This seems to fall under the "protocol maintenance" bullet above, so >> I'm not >> > > clear why this is a separate bullet. As stated above, this could be >> done in >> > > TSVWG if anyone cared. >> > >> > All work on a protocol after first RFC is “protocol maintenance”. We >> could write charter as single bullet “Do protocol maintenance” but that is >> not helpful to guide participants and make AD manage WG. >> >> I'll note that the charter actually does contain a bullet to "perform >> protocol maintenance", which is why I pointed out the overlap? >> >> > Also, this is big and important next step to make ALTO more relevant >> and useable in current Internet. >> >> What particular features of H2 and H3 would make ALTO more relevant and >> deployable in the current Internet? H2 or H3 do not obsolete H1. >> > > SSE is an important feature; see Sec. 4.3.3 of aforementioned CoNEXT19. > SSE is much cleaner using H2/H3. > > >> > > "HTTP ", paragraph 1, comment: >> > >> o Future use cases. The working group will provide a forum to >> discuss possible >> > >> future use cases. >> > > >> > > This discussion can be done on a mailing list without the need for a >> chartered >> > > WG. >> > >> > Yes, everything (even QUIC) can be done on mailing list without need >> for a WG. >> >> Actually, no. Specifications cannot (easily) be published without a WG. >> Discussions, on the other hand, can be had. >> >> > This item was added to draft charter after discussion with AD. The >> purpose is to scope this short term re-charter – if WG cannot show >> meaningful future use cases then there is no long future for WG. >> >> Noted. >> >> > Thanks, > Richard > > >> Thanks, >> Lars >> >> >> _______________________________________________ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
