Re: [alto] Httpdir last call review of draft-ietf-alto-new-transport-14

The major concerns I had are gone.  Thanks.  I don't think that I'll have time to check on the finer details though.

On Wed, Oct 11, 2023, at 13:15, kaigao@scu.edu.cn wrote:
> Hi Martin and all,
>
> A new revision (-15) has been submitted to address the Httpdir last call review.
>
> Highlights:
>
> - Persistent connection and related sections are removed. A short 
> discussion is added to the appendix explaining the reason.
> - A new heartbeat request is introduced to check client liveness for a 
> TIPS view.
> - <tips-view-uri> is now an absolute path to enable potential scoping 
> with subdomain.
> - Specs for push-mode TIPS and related sections are removed, except a 
> short discussion left in the appendix.
>
> Please let us know if the proposed changes resolve the issues. Thanks!
>
> Best,
> Kai
>
>> -----Original Messages-----
>> From: kaigao@scu.edu.cn
>> Send time:Thursday, 10/05/2023 16:25:23
>> To: "Martin Thomson" <mt@lowentropy.net>
>> Cc: ietf-http-wg@w3.org, alto@ietf.org, draft-ietf-alto-new-transport.all@ietf.org, last-call@ietf.org
>> Subject: Re: [alto] Httpdir last call review of draft-ietf-alto-new-transport-14
>> 
>> 
>> 
>> 
>> > -----Original Messages-----
>> > From: "Martin Thomson" <mt@lowentropy.net>
>> > Send time:Thursday, 10/05/2023 11:26:32
>> > To: kaigao <kaigao@scu.edu.cn>
>> > Cc: ietf-http-wg@w3.org, alto@ietf.org, draft-ietf-alto-new-transport.all@ietf.org, last-call@ietf.org
>> > Subject: Re: Httpdir last call review of draft-ietf-alto-new-transport-14
>> > 
>> > On Thu, Oct 5, 2023, at 13:53, kaigao@scu.edu.cn wrote:
>> > > We will really appreciate it if you can point us to any work that has a better
>> > > design, as it looks like a generic problem.
>> > 
>> > The namespacing issue is easy to address using the design I sketched out.  That's a pretty common pattern.
>> > 
>> > The heartbeating mechanism you describe could work, though it could end up being wasteful.  
>> > 
>> > There is an alternative here, which is to avoid server-side state and put
>> > the necessary state into the URL you return to clients when "creating" a view.
>> > Then you don't need to rely on liveness checking so much.  You can have server
>> > side caches for any essential state that carries between requests, but you don't
>> > rely on that state being present.  Any state can be cleared as necessary (on a
>> > timer, say), without needing constant pings, because it can be recovered if
>> > necessary from the URL.  If you can get away with having no server-side state at
>> > all, this is even better, but I don't know how much these views represent
>> > substantial investment in computation or state such that it might be awkward to
>> > transfer that with every request.
>> 
>> Unfortunately this is not feasible in our case. The fundamental states include
>> 
>> 1. resource of interest
>> 2. parameters (e.g., filters)
>> 3. data & updates of the interested resource based on the parameters
>> 4. the current version of the client's data
>> 
>> We already encode 4 in the URL but the first 3 (especially 3) are the most
>> resource-consuming states. Unfortunately 3 can only be maintained by the
>> server and depend on 1 & 2.
>> 
>> In the ideal case, the client should release the resources when it terminates.
>> However, in case of failure or DoS attack, the heartbeat mechanism is needed
>> to identify resources that are no longer being used.
>> _______________________________________________
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto

Received on Wednesday, 11 October 2023 22:01:12 UTC