Httpdir early review of draft-ietf-alto-new-transport-07

Reviewer: Martin Thomson
Review result: Not Ready

I'm going to level-set here from the outset.  I have not given this document as
thorough a review as it might need to be sure, but only because I was unable to
understand it in the hour or so that I spent.  That's clearly not enough time
for something this complex, so adjust the finding of "Not Ready" accordingly.

# Introduction

This document aims to describe an ALTO-specific means of providing clients with
updates to the transport and network information.  It expands on previous
efforts that use SSE, which are generic, but maybe don't take advantage of the
newer HTTP server push feature.

## This is ALTO

I like that this doesn't shy away from making its design very specific to the
application.  Lots of people get grandiose ideas that their design is wonderful
and generally applicable and try to build something very generic, in the process
losing touch with both the needs of their application.  They might convince
(maybe deluding) themselves that others will take on their wonderful ideas and
apply them to completely different applications.

This document suffers from no such delusions, which is great because this work
is really very difficult to understand for an outsider.  I was involved
peripherally with the initial ALTO HTTP design, so have some familiarity with
its goals and structure, but I found this document very difficult to process.
Maybe more time would help, but I really can't justify spending that time.

So I want to focus on the really high-level stuff.

## High Level

The first of my issues makes me wonder if this has been implemented at all.  And
as I went through this, I found myself asking that same question again multiple
times.  Has it?

Finally, I feel obligated to point out that expending effort on HTTP server push
is perhaps unwise given its relative adoption and success.  That is, it has not
really succeeded in browsers and is being removed.  Much of the benefit that a
protocol like ALTO gains is from using common infrastructure, design paradigms,
tooling, and so forth.  ALTO is a small user of HTTP and so benefits from the
millenia of effort put in to improve HTTP by larger users. Those benefits don't
extend to server push, so there is a real risk of this work becoming hard or
impossible to deploy.

## Caveat, Reprise

To soften this a little, it is entirely possible that some of my criticism is
rooted in not understanding the details well enough.  This is a tower built on
top of a tower build on top of a tower build on top of a protocol that I know
reasonably well, but it is a long way from where I stand to the top of that
topmost tower.  And it is fair to say that a good review of this document (what
I an not claiming to provide) would demand that I gain familiarity with the
entire stack.  However, I think that there are several aspects of this document
that could do with some dedicated editorial effort in order to improve this sort
of accessibility.  I've highlighted a few, but I almost certainly missed others
because my focus was on HTTP usage primarily (for instance, I did not consider
whether the security considerations were reasonable or even approximately
comprehensive).


# Issues

## Server Push Usage

Section 7.1 says "A client can add itself explicitly to the receiver set or add
itself to the receiver set when requesting the TIPS view."  It describes two
methods for doing this, but neither indicates which request will remain open so
that the client can receive push promises.

HTTP server push requires that the server send pushes alongside an outstanding
request, but aside from discussion of streams in Section 7.3.1, I can't work out
how the client would do that.  Section 2.4 also fails to make this clear.

Consequently, I cannot convince myself that the primary feature of this document
will work.

## Use of Undefined and Poorly Defined Terms

I'm raising this to the level of a serious issue because this draft is made
extraordinarily difficult to understand as a result of this.  Take Section 2.3,
which introduces some terms.  That same section then includes completely
different terms in Figure 1; terms that turn out to be critical concepts.

I'll also note, though you might treat this as a separate issue, that while the
use of template-like URLs as a convention is a powerful explanatory tool, the
draft doesn't make this clear enough.  The use of i and j for instance, are
introduced in an example, which is easy to skip, only to find that the rest of
the document critically depends on understanding what those mean.


## DELETE, but not

Section 4.4 describes a use for HTTP's DELETE verb that is novel to say the
least.  If the goal is to use DELETE to remove something and that something is a
client's membership in a group (a receiver set here), then you should provide
each client with a URL of their own to delete.  Whether you provide a resource
for the collection (which might be useful for adding clients) or not is up to
you, but this approach is not consistent with how HTTP is expected to operate
and will result in surprises.

Of course, the use of one request (here, the DELETE) to stop server push that
might be happening on another request, is also not how server push is expected
to work.


## Connections and Clients

I can't pin this one down, but there seems to be some sort of assumption that
there is a 1:1 correspondence between connections and clients.  That is not how
HTTP works.  In HTTP, every request stands on its own.  Though there might be
linkages between requests, those linkages should not affect how HTTP itself
operates, including server push.  (You might detect a common theme here.)

As I noted, I'm not completely certain about raising this issue because of a
lack of clarity about how the protocol is supposed to operate.


## Specification by Example

I found that this document leaned a little too heavily on examples, to the point
that it sometimes does not concretely specify expected behaviour at all. The
content of examples were used to show the general shape of what is being
considered.  As I noted before, examples can be a powerful explanatory tool, but
it means that the true interoperability requirements are not always directly
written.  Implementers need to infer normative requirements in some cases.

See the use of /<tips-view-uri>/... everywhere it appears, Section 2.1.1
(schema, where the figures are critical to understanding; I also found Figure 2
very hard to understand, so I had to ignore it, even if it still seems crucial),
Figure 4, the figures in Section 2.4, Section 8.3.

Probably the biggest hole here is j+1 in examples.  I couldn't find a statement
anywhere that says that increments need to strictly increment by 1 each time
(separately, why 101 and not just 1?).  There seems to be an assumption about
that, but the directory resources all seem to indicate that the server is
responsible for numbering increments.  Fixing that seems important.

## Complicated

This design is very complex.  Some of the details in the document probably do
not need to be specified in the level of detail provided.  Section 5 for
instance describes resources that provide clients with data about other
resources, which isn't really consistent with HTTP principles, but they probably
aren't necessary either.

As long as servers adhere to the invariants (S5.5), clients can ask for
incremental resources based on what they know and either get a snapshot or
increments based on what the server is willing to serve them and what they are
willing to process.  The design here requires additional round trips to gather
information about the information the client really wants when it could probably
ask for a resource, use etags to indicate what it has, use Accept to indicate
what it can handle, and the server could then work out what best to serve up.

A specific problem that this design creates is strong coupling.  The client
needs to know about URI structure in order to use the information in the TIPS
view.

Similar comments might apply to managing the set of clients that might want
server push (though again, see the first issue).

# Nits

These are just the ones that really jumped out.

I suggest checking for typos, I saw many.

Please use proper section references when linking.  Links in the form `<xref
target="RFC1234" section="4.5"/>` will ensure that your HTML is properly
generated.

Please submit a bug report for whatever is going on with the caption on Figure
2.  It looks like you have a cross reference in there that xml2rfc is mangling.

"long pull" is not a thing (Section 2.1)

"Connection: Closed" is not a thing (Section 4.2)

Please use real lists (1) especially when the content of the item is long and
(2) because it makes (a) reading and (b) citing the document easier.

I can't work out why "next-edge" (Section 5.2) is null when server push is
disabled.  Why would a client need to know that only when push is enabled?  If
push is enabled, won't the client be pushed the next increment?  On the other
hand, if push is disabled, won't the client need to know what to request next?


## Section 5.5 is Complicated

Section 5.5 says:

> Continuity: ns -> ne, anything in between ns and ne also exists (implies ni ->
  ni + 1 patch exists), where ns is start-seq and ne is end-seq

This section might be reduced to saying:

> A server needs to ensure that any resource state that it makes available MUST
be reachable by clients, either directly via a snapshot (that is, relative to 0)
or indirectly by requesting an earlier snapshot and a contiguous set of
incremental updates.

Received on Thursday, 23 March 2023 02:24:23 UTC