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" <martin.h.d...@gmail.com>
Send time:Thursday, 10/19/2023 00:46:46
To: kai...@scu.edu.cn
Cc: draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson"
<m...@lowentropy.net>, "IETF ALTO" <alto@ietf.org>
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 <kai...@scu.edu.cn> wrote:
-----Original Messages-----
From:"Martin Duke" <martin.h.d...@gmail.com>
Send time:Tuesday, 10/17/2023 22:45:05
To:kai...@scu.edu.cn
Cc:draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson"
<m...@lowentropy.net>, "IETF ALTO" <alto@ietf.org>
Subject: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
On Sat, Oct 14, 2023 at 8:15 PM <kai...@scu.edu.cn> 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" <martin.h.d...@gmail.com>
Send time:Thursday, 10/12/2023 22:54:32
To:kai...@scu.edu.cn
Cc:draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson"
<m...@lowentropy.net>, "IETF ALTO" <alto@ietf.org>
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 <kai...@scu.edu.cn> wrote:
Hi Martin,
Thanks for the comments. Please see inline.
Best,
Kai
-----Original Messages-----
From:"Martin Duke" <martin.h.d...@gmail.com>
Send time:Thursday, 10/12/2023 03:27:14
To:draft-ietf-alto-new-transport....@ietf.org, "Martin Thomson"
<m...@lowentropy.net>
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
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
