Re: [alto] charter-ietf-alto-04-01

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Lars, all,

Apologies for commenting late, I was on holidays.

I would like just to comment on the activities we are doing in Telefonica with 
ALTO. The objective we pursue is to automate the retrieval of network topology 
for optimizing the delivery of video as primary service, targeting additional 
services in the future.

Telefonica has its own CDN development, serving VoD and live TV, and adding 
contents from 3rd parties. By leveraging on ALTO and interfacing the CDN with 
ALTO we try to solve two main issues:


(1)to retrieve an up-to-date view of the network topology, that is, where 
the IP prefixes from the end-users are attached. This is changing along tie 
because the reusing of the IP addressed, for instance in the migrations from 
xDSL to FTTH, consolidation of central offices, etc (similar situation happens 
for mobile service). By now, the actualization of the information is done 
manually, every 6 months, creating inefficiencies and being prone to errors.

(2)to optimize the delivery of service to those customers by taking into 
consideration network information (topology, cost map, and in the future 
advanced info such as available bw), not only application-side inputs (such as 
server loads, etc)

We have completed a 1st PoC leveraging on OSPF. Now we are moving the 
validation to a more complex scenario from one of the operational companies of 
Telefonica, which leverages on IS-IS and which has end-to-end MPLS 
connectivity, but not IP continuity (this implies for instance to handle 
several AS’s plus other complications). The objective is to extend the solution 
based on ALTO to the other operational companies of Telefonica along the time, 
in Europe and Latin America.

In summary, ALTO can help to automate hard tasks related to network operation 
and optimize the utilization of the network, benefiting both users and the 
operator itself.

Same ideas can be easily extrapolated for services we now foresee (refer to 
service edge draft, for instance), or to evolutions of existing content 
services (XR/AR). In this respect the value of ALTO is tremendously high.

Best regards

Luis

__
Dr. Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>

De: alto  En nombre de Y. Richard Yang
Enviado el: martes, 24 de agosto de 2021 16:43
Para: Lars Eggert 
CC: IETF ALTO ; alto-cha...@ietf.org; Qin Wu 
; The IESG 
Asunto: 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 
mailto:l...@eggert.org>> wrote:
Hi,

On 2021-8-24, at 16:07, Qin Wu mailto:bill...@huawei.com>> 
wrote:
> Thank you for reviewing the proposed re-charter of the ALTO working group.

> >

Re: [alto] charter-ietf-alto-04-01

[Martin Duke]

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.
>

Re: [alto] charter-ietf-alto-04-01

[Peng Liu]

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 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] charter-ietf-alto-04-01: (with COMMENT)

[Qin Wu]

Thank Ben for additional comment, see clarification below.
>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.
[Qin]:Thanks for bringing this up, regarding guidelines defined in 
draft-ietf-httpbis-bcp56bis-14
I think HTTP/2's multiplexing is the exact feature we are looking for to enhance
Incremental update SSE defined in RFC8895. Maybe there is some other features 
which could be
Leverages, I can not speak for ALTO proponents.


>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.
[Qin]Maybe protocol extension is not needed, but I assume some kind of mapping 
between ALTO and HTTP/2, HTTP/3 is needed, just like DNS over QUIC,RTP over 
QUIC.
see section 4 of RFC8650 for example, which provides different QoS treatment for
HTTP/1 and HTTP/2.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] charter-ietf-alto-04-01

[Y. Richard Yang]

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 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 

Re: [alto] charter-ietf-alto-04-01

[Lars Eggert]

Hi,

On 2021-8-24, at 16:07, Qin Wu  wrote:
> Thank you for reviewing the proposed re-charter of the ALTO working group.
> Obviously your opinions are very important as a Transport expert, but it is 
> disappointing that you have made such a strong objection so late in the 
> process and after the IESG decided that re-chartering was OK and sent the 
> charter out for external review.

I provided some comments to Martin directly some weeks ago, but I was unable to 
comment during the internal review due to vacation time. That said, it is fully 
appropriate for ADs to also raise comments during external review.

> > It's not clear to me why this effort would need a chartered WG vs. just a
> > mailing list and/or a wiki.
...
> The important difference is whether the IETF retains control of an IETF 
> protocol.

That is not actually a factor. The IETF retains change control over all 
protocols and other work it originates, even if the WG that did so has closed. 
The IETF is not relinquishing change control when it closes WGs.

> >> o Perform protocol maintenance for the existing published protocol.
> >
> > The default WG for protocol maintenance for TSV-area WGs that close is 
> > TSVWG.
> > Any such maintenance could hence be handled there.
> 
> It is true that this is one job for TSVWG.
> We would be worried that ALTO people and drafts would hide other work in TSVWG
> TSVWG meet for 2 hours at IETF-111. ALTO meet for 1 hour. Is that good 
> balance?

It depends on how much maintenance work you think would be needed. The only 
item I see expressed is support for H2 and H3.

> >> o Develop operational support tools for ALTO.
> >
> > I'm not aware of any larger-scale product deployments of ALTO - do some 
> > exists?
> > 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?

> >> 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.

> > "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,
Lars




signature.asc
Description: Message signed with OpenPGP
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto