Re: [alto] Intdir telechat review of draft-ietf-alto-new-transport-16

[[e-mail]]

Hi Bob,

Thanks for the review. Please see inline.

Best,
Kai


> -----Original Messages-----
> From: "Bob Halley via Datatracker" <[e-mail]>
> Send time:Thursday, 10/19/2023 22:11:44
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: [alto] Intdir telechat review of draft-ietf-alto-new-transport-16
> 
> Reviewer: Bob Halley
> Review result: Not Ready
> 
> I am an assigned INT directorate reviewer for draft-ietf-alto-new-transport.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
> 
> Based on my review, if I was on the IESG I would ballot this document as
> DISCUSS.
> 
> While I don't know much about ALTO, I have worked extensively with
> sequence-number-based versioning systems with both snapshots and incremental
> updates.
> 
> I have the following DISCUSS/ABSTAIN level issues:
> 
> I think the basic design is sound; my problem is really with the way the
> document is written.  Some sections are repetitive, some are well-specified,
> and others seem to be examples with explanatory (but also normative) text.  

[KAI] Sections 2-4 are meant to give the high-level ideas of the design
while Sections 5-7 specify the details. Could you point to us any particular
sections that you feel should be improved?

> The example-type sections felt fuzzy and underspecified.  For example, if I do
> 
>   GET /tips/2718281828459/ug/102/105
> 
> in a case where there is no "optional" incremental update edge from 102 to 105,
> i.e. I have to get 102->103, 103->104, and 104->105 individually, then it is
> not clear to me what happens.  Do I get 404?  I think this document would be
> very frustrating for prospective implementers.
> 

[KAI] Previously the whole updates graph will be exposed to clients but the idea
gets pushed back from previous reviews. Currently if one requests an edge that
does not exist, it gets a 404. I guess you are suggesting giving some hints to
the client on potential shortcuts instead of fetching the updates one by one. I
see two options:

First, the client can send the new next edge recommendation request (Sec 7.4)
to query the best next update of its current version. This option is already 
available in the current document.

Second, the server may include the recommended next edge for a query to a request
whose URL does not exist. For example, if one requests 102->106 that does not
exist, the server returns 102->103 in the response. One way is to use HTTP
redirect, but we are not sure if this conforms to the BCP of HTTP. Another way
is to encode this in the body, but is not preferred as it breaks our "type
system". Anyway, this option also requires two rounds of communication and hence
has no advantages over the first option, unless we piggy-back the recommended
next edge in every response. Still, I haven't found a good place to put that
piece of information yet. 

> An architectural worry is that I didn't see any notion of a "generation id" or
> "database id" or other unique name for the whole version history.  Generally
> speaking there is always a possibility of the replacement/regeneration of the
> entire database due to a catastrophic server failure or operator error.  As
> part of the recovery, new content is loaded and the prior version history is
> invalidated.  Ideally a client connecting would realize this and start from 0
> again, as opposed to asking from incremental changes from a history that
> doesn't exist any more.  The issue is that the sequence number spaces of the
> two histories might overlap, and thus the client might be given a nonsensical
> diff that would not apply instead of learning it needs to resync from scratch. 
> In some cases, this can lead to subtle and hard-to-detect content divergence.
> 

[KAI] When the catastrophic server failure happens, assuming all TIPS views are
lost, let's analyze what will happen:

- If the client detects the failure (e.g., because of 404 or multiple rounds of
  unsuccessful connection establishment), it knows the TIPS view is no longer
  there. The client will then drop its own history version and restart again.
- If it does not detect the failure and tries to fetch with the old history, the
  only chance that it may receive a reply is that there is a TIPS view with the
  same TIPS URI (overlapping of SN is not really a necessary condition here).
  But in Sec 6.2, we require the server to NOT reuse URI for different TIPS
  views. This is implementation specific and there are various options such as
  using UUID. As long as there is no URI collision, content divergence will not
  be a problem.

> Dependencies between different versioned objects, as discussed in 8.3, is
> understandable but also seems to undercut simple long pulling of individual
> URIs.  I'm not objecting to the dependencies themselves, as this is
> unavoidable.  I wonder if this might have been addressed in some other way that
> was less burdensome to clients, e.g. some sort of "versioned set of versions",
> though I grant this is not an easy problem.  I just felt late to hear about it
> in section 8.3 when the rest of the text seems to be encouraging me to long
> pull without other concerns.

[KAI] We were hoping to address this by scheduling at the server side as the
server may know the full dependency graph before transmitting the updates, but the
push design depends on server push and is considered not ready in previous reviews.
The issue is not new in ALTO: ALTO/SSE (RFC 8895) already gives some instructions
that may still apply. We can point developers to read Sec 9.2 of RFC 8895.

Also, we can definitely mention the dependent updates in the introduction to bring
attention to this issue. I will post the proposed text later.

> 
> On the nit level, I found the use of "prefetch" as a synonym for "long pull"
> confusing, as for me "prefetching" is a speculative caching term.  There is no
> speculation or caching going on here, we're just trying to do a "push" style of
> pubsub via "long polling" instead of repetitive polling or another form of push
> notification.
> 

[KAI] Replaced all usages of "prefetch" with "long-polling".

> 
> 
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto