Hi Spencer, Thanks for the reply! The reviews really help to make the draft in a better shape!
Thanks a lot and stay well! Best, Kai > -----Original Messages----- > From: "Spencer Dawkins at IETF" <spencerdawkins.i...@gmail.com> > Sent Time: 2023-06-06 04:23:04 (Tuesday) > To: kai...@scu.edu.cn > Cc: "alto@ietf.org" <alto@ietf.org>, mohamed.boucad...@orange.com, "draft-ietf-alto-new-transp...@ietf.org" <draft-ietf-alto-new-transp...@ietf.org>, "a...@ietf.org" <a...@ietf.org> > Subject: Re: Re: RE: [art] Second early ART ART review of draft-ietf-alto-new-transport (-07) > > Hi, Kai, > > On Tue, Apr 25, 2023 at 9:50 PM <kai...@scu.edu.cn> 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:*kai...@scu.edu.cn > > *Sent Time:*2023-03-22 11:15:10 (Wednesday) > > *To:* "alto@ietf.org" <alto@ietf.org>, "Spencer Dawkins at IETF" < > > spencerdawkins.i...@gmail.com>, mohamed.boucad...@orange.com > > *Cc:* "draft-ietf-alto-new-transp...@ietf.org" < > > draft-ietf-alto-new-transp...@ietf.org>, "a...@ietf.org" <a...@ietf.org> > > *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:*mohamed.boucad...@orange.com > > *Sent Time:*2023-03-18 03:35:29 (Saturday) > > *To:* "Spencer Dawkins at IETF" <spencerdawkins.i...@gmail.com>, " > > alto@ietf.org" <alto@ietf.org>, "draft-ietf-alto-new-transp...@ietf.org" < > > draft-ietf-alto-new-transp...@ietf.org> > > *Cc:* "a...@ietf.org" <a...@ietf.org> > > *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 <art-boun...@ietf.org> *De la part de* Spencer Dawkins at IETF > > *Envoyé :* vendredi 17 mars 2023 00:53 > > *À :* a...@ietf.org > > *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 </https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></https:></art-boun...@ietf.org></a...@ietf.org></alto@ietf.org></spencerdawkins.i...@gmail.com></a...@ietf.org></alto@ietf.org></kai...@scu.edu.cn></a...@ietf.org></draft-ietf-alto-new-transp...@ietf.org></alto@ietf.org></spencerdawkins.i...@gmail.com> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
