[alto] Zaheduzzaman Sarker's No Objection on charter-ietf-alto-04-01: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker]

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)

[Qin Wu]

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

[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

[alto] Benjamin Kaduk's No Objection on charter-ietf-alto-04-01: (with COMMENT)

[Benjamin Kaduk via Datatracker]

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

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