Re: [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)

[[e-mail]]

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-----
&gt; From: "Spencer Dawkins at IETF" <[e-mail]>
&gt; Sent Time: 2023-06-06 04:23:04 (Tuesday)
&gt; To: [e-mail]
&gt; Cc: "[e-mail]" <[e-mail]>, [e-mail], "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
&gt; Subject: Re: Re: RE: [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)
&gt; 
&gt; Hi, Kai,
&gt; 
&gt; On Tue, Apr 25, 2023 at 9:50 PM <[e-mail]> wrote:
&gt; 
&gt; &gt; Hi Spencer,
&gt; &gt;
&gt; &gt;
&gt; &gt; We have prepared a pre-release of the new transport document. You can see
&gt; &gt; the diffs with the link below, and the details are inline.
&gt; &gt;
&gt; &gt;
&gt; &gt; Please let us know if the updates address your comments. We look forward
&gt; &gt; to your feedback!
&gt; &gt;
&gt; 
&gt; I've looked at your responses, and I'm happy. with them, and
&gt; especially with the addition of the last sentence in
&gt; https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-09#name-tips-with-different-http-ve,
&gt; which does explicitly explain how to make use of HTTP/3 in TIPS.
&gt; 
&gt; I apologize for my slow response - COVID-19 plus more travel wasn't helping
&gt; me focus!
&gt; 
&gt; Best luck with this draft.
&gt; 
&gt; Spencer
&gt; 
&gt; 
&gt; &gt; Diff with -07:
&gt; &gt;
&gt; &gt;
&gt; &gt; https://author-tools.ietf.org/diff?doc_1=draft-ietf-alto-new-transport-07&amp;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
&gt; &gt;
&gt; &gt;
&gt; &gt; Best,
&gt; &gt;
&gt; &gt; Kai
&gt; &gt;
&gt; &gt; -----Original Messages-----
&gt; &gt; *From:*[e-mail]
&gt; &gt; *Sent Time:*2023-03-22 11:15:10 (Wednesday)
&gt; &gt; *To:* "[e-mail]" <[e-mail]>, "Spencer Dawkins at IETF" &lt;
&gt; &gt; [e-mail]&gt;, [e-mail]
&gt; &gt; *Cc:* "[e-mail]" &lt;
&gt; &gt; [e-mail]&gt;, "[e-mail]" <[e-mail]>
&gt; &gt; *Subject:* Re: RE: [art] Second early ART ART review of
&gt; &gt; draft-ietf-alto-new-transport (-07)
&gt; &gt;
&gt; &gt; Hi Spencer,
&gt; &gt;
&gt; &gt;
&gt; &gt; Thanks for the review. Please see our responses below
&gt; &gt;
&gt; &gt;
&gt; &gt; -----Original Messages-----
&gt; &gt; *From:*[e-mail]
&gt; &gt; *Sent Time:*2023-03-18 03:35:29 (Saturday)
&gt; &gt; *To:* "Spencer Dawkins at IETF" <[e-mail]>, "
&gt; &gt; [e-mail]" <[e-mail]>, "[e-mail]" &lt;
&gt; &gt; [e-mail]&gt;
&gt; &gt; *Cc:* "[e-mail]" <[e-mail]>
&gt; &gt; *Subject:* RE: [art] Second early ART ART review of
&gt; &gt; draft-ietf-alto-new-transport (-07)
&gt; &gt;
&gt; &gt; Hi Spencer,
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Thanks for providing the review in a timely manner. Much appreciated.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Unless I’m mistaken, the review was not forwarded to the ALTO WG list. I’m
&gt; &gt; adding the missing lists, fwiw.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; One quick comment on your previous comment about SETTINGS_ENABLE_PUSH, I
&gt; &gt; remember the authors provided a detailed discussion of the issues your
&gt; &gt; raised (see Slide 13 of
&gt; &gt; https://datatracker.ietf.org/meeting/114/materials/slides-114-alto-alto-over-new-transport-01
&gt; &gt; ).
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Cheers,
&gt; &gt;
&gt; &gt; Med
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; *De :* art <[e-mail]> *De la part de* Spencer Dawkins at IETF
&gt; &gt; *Envoyé :* vendredi 17 mars 2023 00:53
&gt; &gt; *À :* [e-mail]
&gt; &gt; *Objet :* [art] Second early ART ART review of
&gt; &gt; draft-ietf-alto-new-transport (-07)
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; This is my second early review of this document - the first was a review
&gt; &gt; of -01.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; My "Ready with Issues" is based solely on the number of references to
&gt; &gt; HTTP/3 server PUSH usage, which was tagged in my earlier review.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Beyond that, and the following nits, the document was easy and pleasant
&gt; &gt; for me to follow.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Best wishes to the working group!
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; I know a lot of things changed in this draft since I early-reviewed -01 -
&gt; &gt; I'm now early-reviewing -07 - but I'm not sure that my previous observation
&gt; &gt; about this HTTP setting
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; 0x02     SETTINGS_ENABLE_PUSH (a BCP14 “MUST”)
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; has been addressed.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; As I pointed out in my previous review RFC 9114 reserves this value in the
&gt; &gt; parallel HTTP/3 registry (
&gt; &gt; https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table) and says
&gt; &gt; this about these reserved values in
&gt; &gt; https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1:
&gt; &gt; 7.2.4.1. <https: datatracker.ietf.org="" doc="" html="" rfc9114#section-7.2.4.1="">Defined
&gt; &gt; SETTINGS Parameters
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9114#name-defined-settings-parameters="">
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Setting identifiers that were defined in [HTTP/2
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9113="">] where there is no
&gt; &gt; corresponding HTTP/3 setting have also been reserved (Section 11.2.2
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9114#iana-settings="">). These
&gt; &gt; reserved settings *MUST NOT* be sent, and their receipt *MUST* be treated
&gt; &gt; as a connection error
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9114#errors=""> of type
&gt; &gt; H3_SETTINGS_ERROR
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9114#h3_settings_error="">.¶
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" rfc9114#section-7.2.4.1-5="">
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; I don't know what needs to be changed in this specification to reflect
&gt; &gt; this, but even the abstract and the last paragraph of the Introduction
&gt; &gt; refer to "native HTTP/2 or HTTP/3 server push".
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection,
&gt; &gt; which doesn't support server push, so I know you folks have thought about
&gt; &gt; how that works.Do you need to address this for HTTP/3 as well?
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; More strategically, should you be encouraging clients to add support for
&gt; &gt; server PUSH in a new application protocol, if it's already been removed
&gt; &gt; from HTTP/3? But I see this document is in WGLC now, so you can think about
&gt; &gt; that and Do The Right Thing.
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Thanks for the comment. The current text does not work for HTTP/3, as
&gt; &gt; you mentioned that the initialization of server push has changed in HTTP/3.
&gt; &gt; However, it does not mean that the support for server push is removed in
&gt; &gt; HTTP/3. We will update section 7.2 to specify how to enable server push in
&gt; &gt; HTTP/3 using the procedure in
&gt; &gt; https://www.rfc-editor.org/rfc/rfc9114.html#name-server-push.
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: The process of enabling server push in HTTP/2 or /3 is now specified
&gt; &gt; in Section 8.1.1.
&gt; &gt;
&gt; &gt;
&gt; &gt; I have some BCP 14 questions about this text in
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; *3.3. *
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#section-3.3="">
&gt; &gt; *Uses*
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#name-uses="">
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; This set may be any subset of the ALTO server's network information
&gt; &gt; resources and may include resources defined in linked IRDs. However, it is
&gt; &gt; RECOMMENDED that the ALTO server selects a set that is closed under the
&gt; &gt; resource dependency relationship. That is, if a TIPS' "uses" set includes
&gt; &gt; resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS'
&gt; &gt; "uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost
&gt; &gt; map SHOULD also provide a TIPS view for the network map upon which that
&gt; &gt; cost map depends.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; I have the same question about R1 and R0, but let's start with a specific
&gt; &gt; case. If a TIPS for a cost map does not also provide a TIPS view for the
&gt; &gt; underlying network map, what happens next?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Thanks for the comment. If the TIPS (service) only provides a TIPS
&gt; &gt; view for the cost map but not for the network map, the client will not be
&gt; &gt; able to receive incremental updates about the network map. Thus, when there
&gt; &gt; is a change to the network map, the change will be reflected in a TIPS
&gt; &gt; incremental update of the cost map where the "depentdent-vtags" field will
&gt; &gt; be updated (see
&gt; &gt; https://datatracker.ietf.org/doc/html/rfc7285#section-11.2.3.6) Then,
&gt; &gt; the client knows the mapping between IP prefixes and the PID values has
&gt; &gt; changed but does not know the details. The client needs to query the
&gt; &gt; dependent network map resource to get the new mapping.
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: The paragraph is now in Section 5.3. We add a paragraph to clarify
&gt; &gt; the case if the set is not closed.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; (Nit) is there a missing term after TIPS in "a TIPS for a cost map" in
&gt; &gt; this paragraph?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Not exactly but the text is a bit unclear. We propose to use the
&gt; &gt; following text instead:
&gt; &gt;
&gt; &gt;
&gt; &gt; ..., if a TIPS service provides a TIPS view for a cost map, it SHOULD also
&gt; &gt; provide a TIPS view for the network map upon which that cost map depends.
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: The proposed text is in Section 5.3.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; In *4.4. *
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#section-4.4="">*Close
&gt; &gt; Request*
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#name-close-request="">
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; An ALTO client can indicate it no longer desires to pull/receive updates
&gt; &gt; for a specific network resource by "deleting" the TIPS view using the
&gt; &gt; returned tips-view-uri and the HTTP DELETE method. Whether or not the
&gt; &gt; server actually deletes the TIPS view is implementation dependent. Likely,
&gt; &gt; a server will remove the client from a dependency set associated with the
&gt; &gt; TIPS view. A server will not want to delete a TIPS view if another client
&gt; &gt; is using it.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; I'm guessing here, but this looks like it's conflating client usage with
&gt; &gt; server storage management. If client A says "delete the TIPS view", and no
&gt; &gt; other client is using it, that view is deleted, but if another client is
&gt; &gt; using it, and the view is not deleted, what happens next? I could imagine
&gt; &gt; that a server might delete the underlying TIPS view when all clients who
&gt; &gt; were using it have deleted it. Does server behavior in this case need to be
&gt; &gt; implementation dependent?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Thanks for the comment. From a client's point of view, it sees only
&gt; &gt; one copy of the TIPS view for any resource. However, on the server side,
&gt; &gt; there are different implementation options, especially for common resources
&gt; &gt; (e.g., network map or cost map) that may be frequently queried by many
&gt; &gt; clients:
&gt; &gt;
&gt; &gt;
&gt; &gt; - create multiple copies, one for each client --&gt; when the client deletes
&gt; &gt; the view, delete it in the server storage
&gt; &gt;
&gt; &gt; - create one copy for all clients
&gt; &gt;
&gt; &gt;   - maintain a refcount --&gt; when refcount == 0, delete
&gt; &gt;
&gt; &gt;   - never delete (thus no need to maintain the client usage)
&gt; &gt;
&gt; &gt;
&gt; &gt; I think this is implementation dependent. Maybe the text is somehow
&gt; &gt; misleading, how about the following?
&gt; &gt;
&gt; &gt;
&gt; &gt; ...Whether or not the server actually deletes the TIPS view is
&gt; &gt; implementation dependent. For example, an ALTO server may maintain a set of
&gt; &gt; clients that subscribe to the TIPS view of a resource: a client that
&gt; &gt; deletes the view is removed from the set, and the TIPS view is only removed
&gt; &gt; when the dependent set becomes empty.
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Managing a shared view is in Section 9.7, which summarizes the cases
&gt; &gt; that we discussed in the previous response.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; In this text,
&gt; &gt; 8.1.
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#section-8.1="">Considerations
&gt; &gt; for Load Balancing
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#name-considerations-for-load-bal="">
&gt; &gt;
&gt; &gt; TIPS allow clients to make concurrent pulls of the incremental updates
&gt; &gt; potentianlly through different HTTP connections. As a consequence, it
&gt; &gt; introduces additional complexties when the ALTO server is being load
&gt; &gt; balanced -- a feature widely used to build scalable and fault-tolerant web
&gt; &gt; services. For example, a request may be incorrectly processed if
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt;    - the backend servers are stateful, i.e., the TIPS view is created and
&gt; &gt;    stored only on a single server;
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt;    - the ALTO server is using layer-4 load balancing, i.e., the requests
&gt; &gt;    are distributed based on the TCP 5-tuple.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; are these conditions ANDed, or ORed? Is either condition sufficient to
&gt; &gt; cause a problem, or are both required?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: The two conditions need to both be true to cause the problem. We
&gt; &gt; propose to make this clear with the following text:
&gt; &gt;
&gt; &gt;
&gt; &gt; .... For example, a request may be incorrectly processed if the following
&gt; &gt; conditions both hold:
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: The section is moved to Section 9.1 and we fixed the nits.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Also, in the last paragraph of this section,
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt;    - For example, the ALTO server may configure layer-7 load balancers
&gt; &gt;    that distribute requests based on URL or cookies.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Isn't this talking something that an operator or provider of the ALTO
&gt; &gt; server would do, rather than the ALTO server itself?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: Yes, it should be the operator/provider of the ALTO server than the
&gt; &gt; server itself. Here is the proposed text:
&gt; &gt;
&gt; &gt;
&gt; &gt; For example, the operator or the provider of the ALTO server may configure
&gt; &gt; layer-7 load balancers that distribute requests based on URLs or cookies.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; I have a similar question about
&gt; &gt; 8.2.
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#section-8.2="">Considerations
&gt; &gt; for Choosing Updates
&gt; &gt; <https: datatracker.ietf.org="" doc="" html="" draft-ietf-alto-new-transport-07#name-considerations-for-choosing="">
&gt; &gt;
&gt; &gt; TIPS should be cognizant of the effects of its update schedule, which
&gt; &gt; includes both the choice of timing (i.e., when/what to trigger an update on
&gt; &gt; the updates graph) and the choice of message format (i.e., given an update,
&gt; &gt; send a full replacement or an incremental change).
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; and
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; Therefore, each TIPS may decide on its own whether to use JSON merge patch
&gt; &gt; or JSON patch according to the changes in network maps.
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt; &gt; is TIPS thinking, or is that up to a human?
&gt; &gt;
&gt; &gt;
&gt; &gt; KAI: It should be up to a human or the running code. The proposed text is
&gt; &gt; as below:
&gt; &gt;
&gt; &gt;
&gt; &gt; When implementing TIPS, a developer should be cognizant of the effects of
&gt; &gt; the update schedule...
&gt; &gt;
&gt; &gt;
&gt; &gt; and
&gt; &gt;
&gt; &gt;
&gt; &gt; Therefore, each TIPS service instance may choose to encode the updates
&gt; &gt; 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:></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]></[e-mail]>