Hi Mark, Martin, Spencer, First, thank you so much for the reviews. Sorry for the delay in responding asap, due to summer and travel.
One common comment we see from all three of you, in different texts, is essentially on the service model of the current document ( https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/): how much control on the ordering of the messages (Mark/Martin), in-order or not (Spencer). Hence, after the meeting early morning today, we feel that we should start a single thread to discuss this issue. We will send a summary of our responses to each of your individual reviews later. To help make clear the problem and the current design, let's start by summarizing the transport model of ALTO/SSE (RFC8895; https://datatracker.ietf.org/doc/html/rfc8895). We will state the problem as abstract as possible to see the essence of the problem and the potential design choices: - P1: A server offers multiple resources R = {R[1], R[2], R[3], R[4], ...}, where each R[i]i is represnted by a URI; - P2: A client can request from the server the monitoring of a subset M of the resources: M \subset R, e.g., M = {R[1], R[2], R[3]}; for example, R[1] is a network map, R[2] is a cost map using the network map R[1], and R[3] is an endpoint property map; for simplicity, assume the requested resources numbered 1 to |M| - P3: The server can push a sequence of incremental updates to the client for each resource in M. Denote {U[i,1], U[i,2], ...} as the update sequence from the server to the client for R[i] in M, where U[i,1] is the first response for the requested resource R[i], U[i,2] is an incremental update (patch) on top of U[i,1], U[i,3] is the incremental update on top of U[i,2], ... - P3.1: For flexibility, each U[i,j] can choose its own encoding; for example, U[1,1] is application/alto-networkmap+json, U[1,2] is application/merge-patch+json; concrete examples please see the current draft (search "Promised Stream 4" and "Promised Stream 6") - P4: Consider the dependency among the information resources in P3: {U[1,1], U[1,2], ...}, {U[2,1], U[2,2], ...}, and {U[3,1], ....}. There are two types: - P4.1 We have that U[i,j+1] depends on U[i,j] due to incremental updates---in the general case, the client needs to have received and processed U[i,j] to apply U[i,j+1], unless U[i,j+1] is a snapshot (not an incremental update). - P4.2 It is possible that U[i', j'] depends on U[i, j], where i' != i: for example, a cost map depends on the correct version of the network map. If one goes academic, there is a dependency graph that can describe the dependencies. In RFC8895, since it is a single HTTP connection, all of the {U[i,j]} are *linearized" by the server into a single sequence, and Section 6.7 of RFC8895 specifies the linearization (serialization) requirements (P4.1 and P4.2). As we know from concurrency control, linearization is strong and leaves performance on the table. One of the motivations for the new document is to take advantage of the more relaxed concurrency model allowed by HTTP/2 and HTTP/3. So what are the design points that the design team has considered: - D1 (linearization): the server pushes all {U[i,j]} in a single stream. Due to P3.1, there must be an internal structure to separate the U[i,j] boundaries and different U[i,j] can have different media types, leading back to RFC8895. - D2 (max concurrency): Each U[i,j] is sent in an independent (concurrent) push stream (and hence can use its own media type as it is) and let the application-layer handles dependency: ALTO has a build-in dependency check for cross-resource (P4.2) and the sequence numbers of incremental updates allow application (ALTO client) to figure out the same-resource dependency (P4.1). The application (ALTO client) buffers all streams to realize the ordering. - D3 (max concurrency with server barrier): It is D2 but requires that the server does not push U[i',j'] if there is a U[i,j], s.t., (1) U[i,j] is still being sent by the server to the client and (2) U[i',j'] depends on U[i,j]. The intention of the current document is to reflect D3. Note that for D3, the ALTO client still needs to handle the dependency correctly, as the streams may be only buffered at the kernel, and not processed. But the benefit of D3 over D2 is that it implements essentially some flow control, to avoid a faster server overwhelming a slower client. One design point that one may consider is - D4 (linearization of same resource and concurrency for different resources): the U[i,j] of the same R[i] is sent in the same stream (and hence linearized); this can be a reasonable design, but due to P3.1, it is still not clean; see D1 discussion. I hope that the preceding has clarified the stream control issue that the design faced. One can see that the issue can be considered as a generic issue--what to specify when embedding one concurrency model (P4.1/P4.2) into a given concurrency structure (HTTP/2 or HTTP/3). We took a quick look at DoH. It looks that the dependency model of DoH might be simpler: there is no same-resource (DNS resource type) due to no incremental updates (DNS update model appears to be the idempotent overwrite model) or cross-resource dependency. Please correct us if we have missed it. The current document tried to separate the issue into Sec. 8 (ALTO/H2 Stream Management). One way forward we can see is to (1) only specify that each U[i,] is mapped to its own stream (to handle P3.1), and (2) not specify the dependency among U[i,j] (i.e., specify as close as possible to specify nothing) and let the client figure out the dependency at the message; we add the requirement language such as "The client MUST check the dependency ...;" Sorry for the long email. Any comments? Thanks, Richard on behalf of co-authors
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
