Sounds good. I'm going to move this forward, but here are some nits for the next iteration. If you can post an update in the next few days, that would be ideal.
(S4.1) I think this change is clearer about the intent here: OLD It must be noted that a server may close a TIPS view, e.g., under high system load or due to inactivity. It is RECOMMENDED that a client detects the liveness and declares interests of the TIPS view by sending a polling edge request. For example, as long as the polling request to <tips-view-uri>/ug/<j>/<j+1> does not receive error code 404, the TIPS view is still alive. NEW A server MAY close a TIPS view at any time, e.g., under high system load or due to client inactivity. In the event that a TIPS view is closed, an edge request will receive error code 404 in response, and the client will have to request a new TIPS view URI. If resources allow, servers SHOULD avoid closing TIPS views that have active polling edge requests. Servers also SHOULD avoid closing TIPS views that have recently served responses, until clients have had a reasonable interval to request the next update. (S8.7) OLD the ALTO server maintains the set of clients that have sent a polling request to the TIPS view, and only removes the view from the storage when the set becomes empty. NEW the ALTO server maintains the set of clients that have sent a polling request to the TIPS view, and only removes the view from the storage when the set becomes empty and no client immediately issues a new edge request Let me know if you have issues with those changes. Martin On Tue, Oct 17, 2023 at 6:23 PM <[email protected]> wrote: > > > > -----Original Messages----- > *From:* "Martin Duke" <[email protected]> > *Send time:* Tuesday, 10/17/2023 22:45:05 > *To:* [email protected] > *Cc:* [email protected], "Martin Thomson" < > [email protected]>, "IETF ALTO" <[email protected]> > *Subject:* Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15 > > > > 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? > > [KAI] OK, I get it. I thought the recent response would apply to not only > the open request but to previous request as well. The unintended behavior > is that clients compete by sending unnecessary requests to refresh the time > of recent response, which I mentioned in previous replies. If we restrict > guideline <2> to open requests, then there is no problem. > > >>> 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. > > > [KAI] OK. Then we will revise the document based on this proposal and put > new considerations in the resource management section. > > >> >>> 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
