On Fri, Oct 13, 2023 at 12:36 AM <kai...@scu.edu.cn> wrote: > Hi Martin, > > Thanks for the summary. I like the simplicity of approach 2 but here are > some concerns. > > The previous service model is more like First-Come First-Serve, so that > the server keeps the resources for views that already exist and reject > requests if the resources are constrained. Approach 2 can still be FCFS > based on the implementation & configuration but seems more best-effort, > given the implication that server offers no guarantee to the TIPS view. >
Agreed that it's best effort. The original draft delivered to me was best effort, but was pretty vague about what servers can do. (2) has a bunch of guidelines for servers so clients can make assumptions, but servers can break them when under stress. > If the liveness of a TIPS view depends on the usage, I wonder if that will > encourage clients to compete, for example, by making requests that are not > necessary. In the extreme case, a client may even try disabling caching on > intention to make sure the repeated requests arrive at the server, which > essentially becomes heartbeating but with data in the response. Even though > a malicious client can still do that in the current design, the incentives > for normal clients will be much weaker as they can do that legitimately. > The intent of (2) is not to keep stats on the number of open requests for a resource! I think it's a bad idea because of caching, etc. Instead, if there's an open request it should be retained. If there are no stats on the number of open requests, then caching doesn't matter. I do agree that this could create a behavior where the client doesn't actually need 102/103 but puts in the request just to keep the TIPS view alive. From your previous reply, it seems like not having an open edge request on a resource is an edge case. I think I would prefer that we recommend that a client that doesn't need an update right away just be prepared for the TIPS view to go away. > Another potential issue is that creating new TIPS views with customized > filters (unshareable) is likely to be more computationally expensive than > computing the incremental updates. If there is a resource concern, I would > anticipate that allocating the resources to a steady set of TIPS views is > more efficient. While this may be addressed by using a smarter scheduler, > the client developers cannot know that and may also program defensively, > e.g., by making frequent queries to detect liveness of the view and try > recreating the view before new updates arrive -- otherwise a complete fetch > might be needed. > If custom filters are a big issue, another way to implement this is to have a sequence number space for the base (unfiltered) resource. All filtered requests would use this TIPS view, but many of the updates would be null if they didn't affect filtered elements. This is noisier but reduces state at the server. The noise could be mitigated by the next edge request in Sec 7.4. It's all tradeoffs. Those are the thoughts that I have at this point. Any comments or > suggestions are appreciated! > > Best, > > Kai > > -----Original Messages----- > *From:* "Martin Duke" <martin.h.d...@gmail.com> > *Send time:* Thursday, 10/12/2023 22:54:32 > *To:* kai...@scu.edu.cn > *Cc:* draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson" < > m...@lowentropy.net>, "IETF ALTO" <alto@ietf.org> > *Subject:* Re: AD comments on draft-ietf-alto-new-transport-15 > > Kai, > > Adding the ALTO list for proper archiving of this thread. > > I don't see that the fact that it's a proxy matters here; if there is > *any* open request from anywhere, that's an indication that someone is > still interested in the TIPS view. > > If I understand MT's comments correctly, he would prefer somewhat looser > requirements on the server here. This has some friction with my AD review, > but maybe we can synthesize something better here. > > I see two ways forward: > 1) This Heartbeat/DELETE design with the discussed changes. It's clever > but a little complicated, and I have concerns about the scalability of > Heartbeats. > > 2) A set of rules that sets reasonable expectations of the server that the > client can use, but that ultimately falls back on 404s. No Heartbeat or > DELETE. Something like: > > Servers might have to delete a TIPS view due to resource constraints, > especially when the resource is specific to a single client. > > - Servers SHOULD NOT delete a TIPS view when there is an open request for > an edge. > - Servers SHOULD NOT delete a TIPS view if it sent a response for an edge > in the last few seconds. > - Servers MUST respond with a 404 or 410 if the requested TIPS view has > been destroyed. Clients can then request a new TIPS view. > > I would lean towards (2), but am interested in what you and the team > think. > > Martin Duke > > > > > > On Thu, Oct 12, 2023 at 6:58 AM <kai...@scu.edu.cn> wrote: > >> Hi Martin, >> >> Thanks for the comments. Please see inline. >> >> Best, >> >> Kai >> >> -----Original Messages----- >> *From:* "Martin Duke" <martin.h.d...@gmail.com> >> *Send time:* Thursday, 10/12/2023 03:27:14 >> *To:* draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson" < >> m...@lowentropy.net> >> *Subject:* AD comments on draft-ietf-alto-new-transport-15 >> >> Hello ALTO and Martin, >> >> Thanks to Martin for his excellent HTTPDIR review and the team's quick >> work to update the draft. The primary purpose of this email is to verify >> with Martin that the edits are sufficient to address his concerns, as those >> objections are quite detailed. >> >> I also have a couple of followup questions and nits for my own >> understanding: >> >> - Is it a valid use case for the client to open a tips view and then not >> have a request open for an edge? (i.e. can it hold a tips review "in >> reserve" in case it has a need for the resource?) If not, it seems like a >> simpler way to do this would be for the server to keep the tips view open >> as long as there is an open request for an edge (giving a grace period of a >> few RTTs from when a request is filled to allow the client to request the >> next edge). IIUC, this seems much easier than the heartbeat mechanism, and >> more scalable: a cache only needs to forward one GET per update, instead of >> N heartbeats going all the way back to the origin. >> >> >> [KAI] The current document does not demand the client to always send an >> open request. One reason is that, in the case of handling dependent TIPS >> views, a client may hold the request to fetch the latest update of one >> resource (e.g., a cost map) when it is still processing updates for a >> dependent resource (e.g., a network map). Even if we demand that, one >> lesson I learnt from the previous persistent connection debate is that the >> open request, which implies that the underlying connection is still up, may >> not reflect the status of a client but that of a proxy. >> >> Assuming that doesn't work, two questions about heartbeat and DELETEs: >> >> - (S4.1) I don't think the DELETE mechanism works properly. Let's say >> there are two clients subscribing to a TIPS view and they both are sending >> Heartbeat POST requests. if the first client sends DELETE, the server >> really should not delete the TIPS view! >> >> [KAI] Yes the server should not. We do mention how to correctly manage >> shared views in section 8.7. >> >> Sec 6 says "The server MAY keep track of which clients are subscribing to >> each TIPS view to determine whether or not it should delete a TIPS view and >> its corresponding updates graph and associated data." ISTM this is an >> obsolete relic from an earlier design (as some GETs may never arrive at the >> server due to a cache), and a better sentence might be "The server SHOULD >> keep track of how many clients are sending it heartbeat messages and SHOULD >> NOT delete the TIPS view until each client has either sent a DELETE request >> or failed to send a Heartbeat message in the required interval". >> >> [KAI] The proposed text is clearer. We will update the text with a small >> variantion: the server may close the view if multiple heartbeat messages >> are not received. >> >> - (S6.4) There are a few instances of "must" here that I believe should >> be "MUST"? >> >> [KAI] Indeed. Updated as suggested. >> >> thanks >> Martin (Duke) >> >>
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
