Hi Martin, Thanks for the review. Sorry it took us a while to read related documents and discuss internally. Please see our proposed changes below. Best, Kai > -----Original Messages----- > From: "Martin Thomson via Datatracker" <noreply@xxxxxxxx> > Send time:Wednesday, 09/27/2023 13:00:00 > To: ietf-http-wg@xxxxxx > Cc: alto@xxxxxxxx, draft-ietf-alto-new-transport.all@xxxxxxxx, last-call@xxxxxxxx > Subject: Httpdir last call review of draft-ietf-alto-new-transport-14 > > Reviewer: Martin Thomson > Review result: Not Ready > > I reviewed the document previously, so this is an incremental review. > > Two major issues remain in the document. I don't believe that it would be > responsible to publish this document without correcting these issues. > > 1. The first relates to assumptions of connection-bound state and a fix would > require some small, but fundamental, changes to the protocol. > > 2. The second relates to the appendix on use of HTTP server push and might be > fixed either by dropping the capability along with some minor editorial > changes, or by reworking the design of the appendix. > > A lot of the explanation of the data model and the expected interaction models > are clearer in this version. The polling design seems reasonable, modulo the > first issue I note below. That said, I am not expert enough in this area to > say whether there is a need to create per-client state on servers to support > this interaction mode. > > Issue 1: Connection affinity > > Section 4.2 of the document is a defense of the decision in the protocol that > binds state to a connection. HTTP does not recognize connections as having any > state. The last paragraph of Section 4.11 of RFC 9205 explains this very > clearly: > > > Applications MUST NOT make assumptions about the relationship between > separate requests on a single transport connection; doing so breaks many of the > assumptions of HTTP as a stateless protocol and will cause problems in > interoperability, security, operability, and evolution. > > There are several recognized ways of working around the sorts of issues that > this document is trying to deal with. One might be to build a stateful > protocol that is not HTTP (as in Section 2.1 of RFC 9205). > > If the goal is to use HTTP, then you might be able to provide clients with URLs > that only reference the server instances that they are currently interacting > with. For instance, when the client opens a new TIPS view, the server could > provide an absolute URL to a resource that is hosted exclusively on that > instance (for instance, instance12345.alto.example as opposed to alto.example). > Clients would still be able to use the URL template style of queries relative > to that view, but the state would not be assumed to exist across the entire > service. > > This approach has some drawbacks, in that it can expose instances to more > powerful denial of service attacks, but it might provide the sort of properties > that Section 4.2 claims to be seeking. > [KAI] Thanks for pointing to RFC 9205. We also investigate some related documents mentioning persistent connections (e.g., RFC 6712). Indeed relying on the state of persistent connections is likely to break if there is an HTTP proxy, beyond the control of both the client and the server, sitting in between. Our intended use of the persistent connection serves two purposes: First is to provide a "namespace" for clients to operate independently. For this purpose, we actually have a design in the document similar to the "absolute URL" you proposed, but in the format of "example.alto.com/instance123" instead of "instance123.example.alto.com". Any particular reason you propose the subdomain format? Or you think the current subpath format can work too? Second is to monitor the liveness of the client. We were previously hoping to use the state of persistent connection as an indicator of the client's liveness. It seems that an ALTO-layer heartbeat mechanism may be needed for this purpose. The proposed solution is 1. Client sends open request 2. Server returns the root <tips-view-uri> with a HEARTBEAT_INTERVAL (in seconds) 3. Client periodically sends a POST (to avoid being cached) request to <tips-view-uri>/heartbeat every HEARTBEAT_INTERVAL with an incremental counter 4. Server may close the view if a close request is received or not receiving the heartbeat message for MAX_ALLOW_HEARTBEAT_STOPS intervals. We will really appreciate it if you can point us to any work that has a better design, as it looks like a generic problem. > Issue 2: Server push design > > The use of HTTP server push described in Appendix C is not consistent with > HTTP/2 or HTTP/3 and will not work. > > I've attempted to explain several times why this design is unworkable. I won't > try again here. > [KAI] We already move the push mode out of the main body. I guess eventually we have to let go. > Cheers, > Martin > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
