Hi Martin,
Thanks for the comments. Please see inline.
Best,
Kai
-----Original Messages-----
From:"Martin Duke" <[email protected]>
Send time:Saturday, 10/14/2023 04:04:43
To: [email protected]
Cc: [email protected], "Martin Thomson"
<[email protected]>, "IETF ALTO" <[email protected]>
Subject: Re: Re: AD comments on draft-ietf-alto-new-transport-15
On Fri, Oct 13, 2023 at 12:36 AM <[email protected]> wrote:
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.
Agreed that it's best effort. The original draft delivered to me was best
effort, but was pretty vague about what servers can do. (2) has a bunch of
guidelines for servers so clients can make assumptions, but servers can break
them when under stress.
[KAI] I agree that we should give clearer instructions/guidelines to servers.
The arguments below are trying to review the current guidelines.
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.
The intent of (2) is not to keep stats on the number of open requests for a
resource! I think it's a bad idea because of caching, etc. Instead, if there's
an open request it should be retained.
If there are no stats on the number of open requests, then caching doesn't
matter.
[KAI] I didn't mean to keep the stats of open requests. For guideline <1>,
there is no need to increase the number as long as there is (at least) one.
However, one would anticipate that each client will always make an open request
to each TIPS view that it is monitoring. Good side of this behavior is that a
client may get notified immediately when the TIPS view is destroyed.
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.
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.
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
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
