Sounds good to me. On Wed, Oct 18, 2023 at 10:34 PM <[email protected]> wrote:
> Hi Martin, > > I would like to change the wording a bit to make sure they guidelines are > interpreted as applicable only when the resources are sufficient: > > > OLD: > > 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. > > NEW: > > If resources allow, servers SHOULD avoid closing TIPS views that have > active polling edge requests or have recently served responses > until clients have had a reasonable interval to request the next update. > > > I will update the document in my evening and post if you think it's OK. > > > Best, > > Kai > > > -----Original Messages----- > *From:* "Martin Duke" <[email protected]> > *Send time:* Thursday, 10/19/2023 00:46:46 > *To:* [email protected] > *Cc:* [email protected], "Martin Thomson" < > [email protected]>, "IETF ALTO" <[email protected]> > *Subject:* Re: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15 > > 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
