Hi, Kai, On Tue, Apr 25, 2023 at 9:50 PM <[email protected]> wrote:
> 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! > I've looked at your responses, and I'm happy. with them, and especially with the addition of the last sentence in https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-09#name-tips-with-different-http-ve, which does explicitly explain how to make use of HTTP/3 in TIPS. I apologize for my slow response - COVID-19 plus more travel wasn't helping me focus! Best luck with this draft. Spencer > 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. > <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1>Defined > SETTINGS Parameters > <https://datatracker.ietf.org/doc/html/rfc9114#name-defined-settings-parameters> > > > > Setting identifiers that were defined in [HTTP/2 > <https://datatracker.ietf.org/doc/html/rfc9113>] where there is no > corresponding HTTP/3 setting have also been reserved (Section 11.2.2 > <https://datatracker.ietf.org/doc/html/rfc9114#iana-settings>). These > reserved settings *MUST NOT* be sent, and their receipt *MUST* be treated > as a connection error > <https://datatracker.ietf.org/doc/html/rfc9114#errors> of type > H3_SETTINGS_ERROR > <https://datatracker.ietf.org/doc/html/rfc9114#H3_SETTINGS_ERROR>.¶ > <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1-5> > > > > 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. * > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-3.3> > *Uses* > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-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. * > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-4.4>*Close > Request* > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-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. > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.1>Considerations > for Load Balancing > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-load-bal> > > 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. > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.2>Considerations > for Choosing Updates > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-choosing> > > 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. > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.6>Considerations > for Updates to Ordinal Mode Costs > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-updates-t> > > 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
