Re: [alto] System and Service Performance Benchmarking vs Network Performance Exposure
Hi Qin, This is meant to be more about to health of the ALTO server itself instead of that of the underlying network. This is to monitor the functioning of the ALTO protocol with various statistics and counters. Is the use of the term "ALTO-specific performance metrics", a source of confusion? We could change that... Thanks! Dhruv On Sat, Jul 9, 2022 at 8:10 PM Qin Wu wrote: > Hi, All: > > In draft-ietf-alto-oam-yang-00, two YANG models have been defined: > > 1.ietf-alto.yang: focusing on server configuration > > 2.ietf-alto-stats.yang: focusing on performance monitor and logging and > fault reporting > > I am not sure I understand the role or responsibility of the second model > ietf-alto-stats.yang > > It seems the second yang module more looks into System and Service > performance measurement based on requirements defined in section 3.4.3 of > RFC7971: > > “ > > 3.4.3. System and Service Performance > > > >A number of interesting parameters can be measured at the ALTO > >server. [RFC7285] suggests certain ALTO-specific metrics to be > >monitored: > > > >o Requests and responses for each service listed in an Information > > Directory (total counts and size in bytes). > > > >o CPU and memory utilization > > > >o ALTO map updates > > > >o Number of PIDs > > > >o ALTO map sizes (in-memory size, encoded size, number of entries) > > > >This data characterizes the workload, the system performance as well > >as the map data. Obviously, such data will depend on the > >implementation and the actual deployment of the ALTO service. > >Logging is also recommended in [RFC7285]. > > > > ” > > ALTO sever doesn’t need to collect these information from its southbound > interface or from the underlying network. > > Since ALTO server can expose Cost metric information to ALTO client, I am > wondering how these network performance related cost metrics are collected, > > Doesn’t ALTO Server be triggered to initiate measurement task and collect the > network performance information from the underlying network? Or these > measurement task have been pre-provisioned. > > > > What do I miss? > > > > -Qin (Speak as individual) > > > ___ > 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
Re: [alto] Working Group Last Call for draft-ietf-cdni-additional-footprint-types
Hi Jensen, Thanks for laying out the options! Nir, Do you have any thoughts on Jensen's suggestion? thanx! -- Kevin J. Ma On Tue, Jul 5, 2022 at 8:47 PM Jensen Zhang wrote: > Hi Kevin, > > Thanks for the information about the new CDNI footprint types. > > RFC 9241 is going to be published soon. To leverage Sec 6 of RFC 9241 [1], > the new footprint type should be added to the ALTO Entity Domain Types > registry. > > [1] > https://www.rfc-editor.org/authors/rfc9241.html#name-query-footprint-properties- > > In the recent ALTO WG weekly meeting, we had some brief discussion on how > to proceed. There are two options: > > 1. Add a new section/subsection in > draft-ietf-cdni-additional-footprint-types to register the new footprint > type "subdivisioncode" to the ALTO Entity Domain Types registry. > 2. Submit a new document to ALTO WG later to update the ALTO Entity Domain > Types registry. > > Personally, I will suggest the second option. It will keep the current > document clean and not interrupt the IETF process. > > I cc'ed ALTO mailing list to see if we have any other feedback from other > ALTO experts. > > Best, > Jensen > > > On Mon, Jul 4, 2022 at 10:59 PM Kevin Ma > wrote: > >> Hi Jensen/Jan, >> >> With the ALTO CDNI draft to be published shortly, one question came up >> wrt the adding of new footprint types to CDNI: should the ALTO Entity >> Domain Types registry also be updated? In the case of >> draft-ietf-cdni-additional-footprint-types, should subdivisioncode be added >> to the ALTO Entity Domain Types registry? >> >> thanx! >> >> -- Kevin J. MA >> >> On Thu, May 12, 2022 at 12:52 AM Kevin Ma >> wrote: >> >>> Hi All, >>> >>> As we discussed in the session at IETF 113, the footprint extension >>> draft (draft-ietf-cdni-additional-footprint-types) is pretty >>> straightforward and registers two useful new footprint types. There were >>> no objections to moving to WGLC in the session, though Benson Muite did >>> mention a potential concern about ISO3166 codes. This is the official >>> working group last call. If you have any comments, questions, or concerns >>> please respond to this thread. >>> >>> The latest version of the draft can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/ >>> >>> This WGLC will stay open for two weeks and close on May 26, 2022. If no >>> objections or major issues are raised in that time, we will move to submit >>> the draft to the IESG. >>> >>> thanx! >>> >>> -- Kevin and Sanjay >>> >> ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] System and Service Performance Benchmarking vs Network Performance Exposure
Hi, All: In draft-ietf-alto-oam-yang-00, two YANG models have been defined: 1.ietf-alto.yang: focusing on server configuration 2.ietf-alto-stats.yang: focusing on performance monitor and logging and fault reporting I am not sure I understand the role or responsibility of the second model ietf-alto-stats.yang It seems the second yang module more looks into System and Service performance measurement based on requirements defined in section 3.4.3 of RFC7971: " 3.4.3. System and Service Performance A number of interesting parameters can be measured at the ALTO server. [RFC7285] suggests certain ALTO-specific metrics to be monitored: o Requests and responses for each service listed in an Information Directory (total counts and size in bytes). o CPU and memory utilization o ALTO map updates o Number of PIDs o ALTO map sizes (in-memory size, encoded size, number of entries) This data characterizes the workload, the system performance as well as the map data. Obviously, such data will depend on the implementation and the actual deployment of the ALTO service. Logging is also recommended in [RFC7285]. " ALTO sever doesn't need to collect these information from its southbound interface or from the underlying network. Since ALTO server can expose Cost metric information to ALTO client, I am wondering how these network performance related cost metrics are collected, Doesn't ALTO Server be triggered to initiate measurement task and collect the network performance information from the underlying network? Or these measurement task have been pre-provisioned. What do I miss? -Qin (Speak as individual) ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] JOSE objects carrying ALTO payloads for server authentication
Hi, All: RFC7285 speaks a lot about client authentication, e.g., section 15.3.2 " For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported to achieve ALTO client authentication to limit the number of parties with whom ALTO information is directly shared. TLS client authentication may also be supported. Depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services. Access control can also help to prevent Denial-of-Service attacks by arbitrary hosts from the Internet. See [ALTO-DEPLOYMENT] for a more detailed discussion on this issue. " Section 8.3.5 " 8.3.5. Authentication and Encryption ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. See Section 15.1.2 for security considerations and Section 16 for manageability considerations regarding the usage of HTTPS/TLS. For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available. " But it only briefly touches server authentication at the end of section 16.2.4: " Multiple ALTO servers can be deployed for scalability. A centralized configuration database may be used to ensure they are providing the desired ALTO information with appropriate security controls. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency. " I think server authentication is important in the server to server communication, since the client needs to Make sure the ALTO information is generated by appropriate ALTO server See section 5.5 of RFC7165, " 5.5. ALTO Application-Layer Traffic Optimization (ALTO) is a system for distributing network topology information to end devices, so that those devices can modify their behavior to have a lower impact on the network [RFC6708]. The ALTO protocol distributes topology information in the form of JSON objects carried in HTTP [RFC2616] [ALTO]. The basic version of ALTO is simply a client-server protocol, so simple use of HTTPS suffices for this case [RFC2818]. However, there is beginning to be some discussion of use cases for ALTO in which these JSON objects will be distributed through a collection of intermediate servers before reaching the client, while still preserving the ability of the client to authenticate the original source of the object. Even the base ALTO protocol notes that "ALTO Clients obtaining ALTO information through redistribution must be able to validate the received ALTO information" to ensure that it was generated by an appropriate ALTO server. In this case, the security requirements are straightforward. JOSE objects carrying ALTO payloads will need to bear digital signatures from the originating servers, which will be bound to certificates attesting to the identities of the servers. There is no requirement for confidentiality in this case, since ALTO information is generally public. " It did discussed server to server communication case. I am wondering how ALTO information is carried in the JOSE objects, is there JOSE protocol extension needed? Also I am wondering whether ALTO OAM need to consider the use case where ALTO information distributed between A set of ALTO server or intermediate server and provide some configuration definition for both client authentication and server authentication. -Qin ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
