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.
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.
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.
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
