On Sat, Oct 14, 2023 at 8:15 PM <[email protected]> wrote: > 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. > > > [KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views > with recent responses, may lead to unintended client behavior, which may > increase the server complexity to mitigate. >
The point of "tracking recent responses" is that you don't want to respond to an open request and then close the TIPS view because there are no open requests -- the server needs to give the client a few RTTs to request the new edge. What unintended client behavior arises from this? > >> 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. > > [KAI] I would rather not have this complexity. This puts too many > constraints on server implementation and some resources (e.g., endpoint > cost service) may not have a dependent base resource. > I would certainly not require this, but it is a way one could implement a server. > > One potential solution is: > > 1. Remove heartbeat and close, and state that a client 1) must not expect > the view to be permanent unless instructed by the service operator or > further extensions and 2) should send an open request to detect liveness of > the view if necessary. > 2. Add a subsection such as "Considerations for Resource Contention" and > leave the choice of handling contentions to the implementation, with > suggestions such as that usage-based solution may lead to unintended client > behavior. > > Personally I think deletion is still needed. Consider the case where the > server is charging clients based on usages such as number of concurrent > TIPS views and number of requests, removing deletion makes is impossible > for a client to actively control the TIPS views that remain open. I would > anticipate that we submit a new I-D enabling that feature :D > This solution works for me, although there's already a section on resource management that's pretty good. I don't like the idea of DELETE being used as some sort of pricing signal -- that seems like abuse of the protocol. > > >> Those are the thoughts that I have at this point. Any comments or >> suggestions are appreciated! >> >> Best, >> >> Kai >> >> -----Original Messages----- >> *From:* "Martin Duke" <[email protected]> >> *Send time:* Thursday, 10/12/2023 22:54:32 >> *To:* [email protected] >> *Cc:* [email protected], "Martin Thomson" < >> [email protected]>, "IETF ALTO" <[email protected]> >> *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 <[email protected]> wrote: >> >>> Hi Martin, >>> >>> Thanks for the comments. Please see inline. >>> >>> Best, >>> >>> Kai >>> >>> -----Original Messages----- >>> *From:* "Martin Duke" <[email protected]> >>> *Send time:* Thursday, 10/12/2023 03:27:14 >>> *To:* [email protected], "Martin Thomson" < >>> [email protected]> >>> *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 [email protected] https://www.ietf.org/mailman/listinfo/alto
