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
