Hi Spencer,
We have prepared a pre-release of the new transport document. You can see the diffs with the link below, and the details are inline. Please let us know if the updates address your comments. We look forward to your feedback! Diff with -07: https://author-tools.ietf.org/diff?doc_1=draft-ietf-alto-new-transport-07&url_2=https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/releases/download/draft-ietf-alto-new-transport-08-snapshot-20230426/draft-ietf-alto-new-transport-08.txt Best, Kai -----Original Messages----- From:[email protected] Sent Time:2023-03-22 11:15:10 (Wednesday) To: "[email protected]" <[email protected]>, "Spencer Dawkins at IETF" <[email protected]>, [email protected] Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: RE: [art] Second early ART ART review of draft-ietf-alto-new-transport (-07) Hi Spencer, Thanks for the review. Please see our responses below -----Original Messages----- From:[email protected] Sent Time:2023-03-18 03:35:29 (Saturday) To: "Spencer Dawkins at IETF" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: RE: [art] Second early ART ART review of draft-ietf-alto-new-transport (-07) Hi Spencer, Thanks for providing the review in a timely manner. Much appreciated. Unless I’m mistaken, the review was not forwarded to the ALTO WG list. I’m adding the missing lists, fwiw. One quick comment on your previous comment about SETTINGS_ENABLE_PUSH, I remember the authors provided a detailed discussion of the issues your raised (see Slide 13 of https://datatracker.ietf.org/meeting/114/materials/slides-114-alto-alto-over-new-transport-01). Cheers, Med De : art <[email protected]> De la part de Spencer Dawkins at IETF Envoyé : vendredi 17 mars 2023 00:53 À : [email protected] Objet : [art] Second early ART ART review of draft-ietf-alto-new-transport (-07) This is my second early review of this document - the first was a review of -01. My "Ready with Issues" is based solely on the number of references to HTTP/3 server PUSH usage, which was tagged in my earlier review. Beyond that, and the following nits, the document was easy and pleasant for me to follow. Best wishes to the working group! I know a lot of things changed in this draft since I early-reviewed -01 - I'm now early-reviewing -07 - but I'm not sure that my previous observation about this HTTP setting 0x02 SETTINGS_ENABLE_PUSH (a BCP14 “MUST”) has been addressed. As I pointed out in my previous review RFC 9114 reserves this value in the parallel HTTP/3 registry (https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says this about these reserved values in https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1: 7.2.4.1. Defined SETTINGS Parameters Setting identifiers that were defined in [HTTP/2] where there is no corresponding HTTP/3 setting have also been reserved (Section 11.2.2). These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR.¶ I don't know what needs to be changed in this specification to reflect this, but even the abstract and the last paragraph of the Introduction refer to "native HTTP/2 or HTTP/3 server push". Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection, which doesn't support server push, so I know you folks have thought about how that works.Do you need to address this for HTTP/3 as well? More strategically, should you be encouraging clients to add support for server PUSH in a new application protocol, if it's already been removed from HTTP/3? But I see this document is in WGLC now, so you can think about that and Do The Right Thing. KAI: Thanks for the comment. The current text does not work for HTTP/3, as you mentioned that the initialization of server push has changed in HTTP/3. However, it does not mean that the support for server push is removed in HTTP/3. We will update section 7.2 to specify how to enable server push in HTTP/3 using the procedure in https://www.rfc-editor.org/rfc/rfc9114.html#name-server-push. KAI: The process of enabling server push in HTTP/2 or /3 is now specified in Section 8.1.1. I have some BCP 14 questions about this text in 3.3. Uses This set may be any subset of the ALTO server's network information resources and may include resources defined in linked IRDs. However, it is RECOMMENDED that the ALTO server selects a set that is closed under the resource dependency relationship. That is, if a TIPS' "uses" set includes resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS' "uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost map SHOULD also provide a TIPS view for the network map upon which that cost map depends. I have the same question about R1 and R0, but let's start with a specific case. If a TIPS for a cost map does not also provide a TIPS view for the underlying network map, what happens next? KAI: Thanks for the comment. If the TIPS (service) only provides a TIPS view for the cost map but not for the network map, the client will not be able to receive incremental updates about the network map. Thus, when there is a change to the network map, the change will be reflected in a TIPS incremental update of the cost map where the "depentdent-vtags" field will be updated (see https://datatracker.ietf.org/doc/html/rfc7285#section-11.2.3.6). Then, the client knows the mapping between IP prefixes and the PID values has changed but does not know the details. The client needs to query the dependent network map resource to get the new mapping. KAI: The paragraph is now in Section 5.3. We add a paragraph to clarify the case if the set is not closed. (Nit) is there a missing term after TIPS in "a TIPS for a cost map" in this paragraph? KAI: Not exactly but the text is a bit unclear. We propose to use the following text instead: ..., if a TIPS service provides a TIPS view for a cost map, it SHOULD also provide a TIPS view for the network map upon which that cost map depends. KAI: The proposed text is in Section 5.3. In 4.4. Close Request An ALTO client can indicate it no longer desires to pull/receive updates for a specific network resource by "deleting" the TIPS view using the returned tips-view-uri and the HTTP DELETE method. Whether or not the server actually deletes the TIPS view is implementation dependent. Likely, a server will remove the client from a dependency set associated with the TIPS view. A server will not want to delete a TIPS view if another client is using it. I'm guessing here, but this looks like it's conflating client usage with server storage management. If client A says "delete the TIPS view", and no other client is using it, that view is deleted, but if another client is using it, and the view is not deleted, what happens next? I could imagine that a server might delete the underlying TIPS view when all clients who were using it have deleted it. Does server behavior in this case need to be implementation dependent? KAI: Thanks for the comment. From a client's point of view, it sees only one copy of the TIPS view for any resource. However, on the server side, there are different implementation options, especially for common resources (e.g., network map or cost map) that may be frequently queried by many clients: - create multiple copies, one for each client --> when the client deletes the view, delete it in the server storage - create one copy for all clients - maintain a refcount --> when refcount == 0, delete - never delete (thus no need to maintain the client usage) I think this is implementation dependent. Maybe the text is somehow misleading, how about the following? ...Whether or not the server actually deletes the TIPS view is implementation dependent. For example, an ALTO server may maintain a set of clients that subscribe to the TIPS view of a resource: a client that deletes the view is removed from the set, and the TIPS view is only removed when the dependent set becomes empty. KAI: Managing a shared view is in Section 9.7, which summarizes the cases that we discussed in the previous response. In this text, 8.1. Considerations for Load Balancing TIPS allow clients to make concurrent pulls of the incremental updates potentianlly through different HTTP connections. As a consequence, it introduces additional complexties when the ALTO server is being load balanced -- a feature widely used to build scalable and fault-tolerant web services. For example, a request may be incorrectly processed if the backend servers are stateful, i.e., the TIPS view is created and stored only on a single server; the ALTO server is using layer-4 load balancing, i.e., the requests are distributed based on the TCP 5-tuple. are these conditions ANDed, or ORed? Is either condition sufficient to cause a problem, or are both required? KAI: The two conditions need to both be true to cause the problem. We propose to make this clear with the following text: .... For example, a request may be incorrectly processed if the following conditions both hold: KAI: The section is moved to Section 9.1 and we fixed the nits. Also, in the last paragraph of this section, For example, the ALTO server may configure layer-7 load balancers that distribute requests based on URL or cookies. Isn't this talking something that an operator or provider of the ALTO server would do, rather than the ALTO server itself? KAI: Yes, it should be the operator/provider of the ALTO server than the server itself. Here is the proposed text: For example, the operator or the provider of the ALTO server may configure layer-7 load balancers that distribute requests based on URLs or cookies. I have a similar question about 8.2. Considerations for Choosing Updates TIPS should be cognizant of the effects of its update schedule, which includes both the choice of timing (i.e., when/what to trigger an update on the updates graph) and the choice of message format (i.e., given an update, send a full replacement or an incremental change). and Therefore, each TIPS may decide on its own whether to use JSON merge patch or JSON patch according to the changes in network maps. is TIPS thinking, or is that up to a human? KAI: It should be up to a human or the running code. The proposed text is as below: When implementing TIPS, a developer should be cognizant of the effects of the update schedule... and Therefore, each TIPS service instance may choose to encode the updates using JSON merge patch or JSON patch based on the changes in network maps. And in 8.6. Considerations for Updates to Ordinal Mode Costs While this document allows TIPS to offer incremental updates for ordinal mode cost maps, TIPS implementors should be aware that incremental updates for ordinal costs are more complicated than for numerical costs, and ALTO clients should be aware that small changes may result in large updates. I'm guessing that ALTO clients aren't aware. KAI: Yes, indeed. We will fix similar issues. The proposed text is as below: and developers should be aware that small changes may result in large updates when adding TIPS support for an ALTO client. I'm not sure I've caught all of these occurrences, but perhaps the GenArt reviewer will notice others, if they are present! _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
