Early Review of draft-ietf-alto-new-transport-07
review-ietf-alto-new-transport-07-artart-early-dawkins-2023-03-16-00

This is my second early review of this document - the first was a review of
-01.

My "Ready with Issues" is based solely on the number of references to
HTTP/3 server PUSH usage, which was tagged in my earlier review.

Beyond that, and the following nits, the document was easy and pleasant for
me to follow.

Best wishes to the working group!

I know a lot of things changed in this draft since I early-reviewed -01 -
I'm now early-reviewing -07 - but I'm not sure that my previous observation
about this HTTP setting

0x02     SETTINGS_ENABLE_PUSH (a BCP14 “MUST”)

has been addressed.

As I pointed out in my previous review RFC 9114 reserves this value in the
parallel HTTP/3 registry (
https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says
this about these reserved values in
https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1:
7.2.4.1. <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1>Defined
SETTINGS Parameters
<https://datatracker.ietf.org/doc/html/rfc9114#name-defined-settings-parameters>

Setting identifiers that were defined in [HTTP/2
<https://datatracker.ietf.org/doc/html/rfc9113>] where there is no
corresponding HTTP/3 setting have also been reserved (Section 11.2.2
<https://datatracker.ietf.org/doc/html/rfc9114#iana-settings>). These
reserved settings MUST NOT be sent, and their receipt MUST be treated
as a connection
error <https://datatracker.ietf.org/doc/html/rfc9114#errors> of type
H3_SETTINGS_ERROR
<https://datatracker.ietf.org/doc/html/rfc9114#H3_SETTINGS_ERROR>.¶
<https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1-5>

I don't know what needs to be changed in this specification to reflect
this, but even the abstract and the last paragraph of the Introduction
refer to "native HTTP/2 or HTTP/3 server push".

Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection,
which doesn't support server push, so I know you folks have thought about
how that works.Do you need to address this for HTTP/3 as well?

More strategically, should you be encouraging clients to add support for
server PUSH in a new application protocol, if it's already been removed
from HTTP/3? But I see this document is in WGLC now, so you can think about
that and Do The Right Thing.

I have some BCP 14 questions about this text in

3.3.
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-3.3>
Uses
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-uses>

This set may be any subset of the ALTO server's network information
resources and may include resources defined in linked IRDs. However, it is
RECOMMENDED that the ALTO server selects a set that is closed under the
resource dependency relationship. That is, if a TIPS' "uses" set includes
resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS'
"uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost
map SHOULD also provide a TIPS view for the network map upon which that
cost map depends.

I have the same question about R1 and R0, but let's start with a specific
case. If a TIPS for a cost map does not also provide a TIPS view for the
underlying network map, what happens next?

(Nit) is there a missing term after TIPS in "a TIPS for a cost map" in this
paragraph?

In 4.4.
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-4.4>Close
Request
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-close-request>

An ALTO client can indicate it no longer desires to pull/receive updates
for a specific network resource by "deleting" the TIPS view using the
returned tips-view-uri and the HTTP DELETE method. Whether or not the
server actually deletes the TIPS view is implementation dependent. Likely,
a server will remove the client from a dependency set associated with the
TIPS view. A server will not want to delete a TIPS view if another client
is using it.

I'm guessing here, but this looks like it's conflating client usage with
server storage management. If client A says "delete the TIPS view", and no
other client is using it, that view is deleted, but if another client is
using it, and the view is not deleted, what happens next? I could imagine
that a server might delete the underlying TIPS view when all clients who
were using it have deleted it. Does server behavior in this case need to be
implementation dependent?

In this text,
8.1.
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.1>Considerations
for Load Balancing
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-load-bal>

TIPS allow clients to make concurrent pulls of the incremental updates
potentianlly through different HTTP connections. As a consequence, it
introduces additional complexties when the ALTO server is being load
balanced -- a feature widely used to build scalable and fault-tolerant web
services. For example, a request may be incorrectly processed if
   -
   the backend servers are stateful, i.e., the TIPS view is created and
   stored only on a single server;
   -
   the ALTO server is using layer-4 load balancing, i.e., the requests are
   distributed based on the TCP 5-tuple.

are these conditions ANDed, or ORed? Is either condition sufficient to
cause a problem, or are both required?


Also, in the last paragraph of this section,


   -

   For example, the ALTO server may configure layer-7 load balancers that
   distribute requests based on URL or cookies.


Isn't this talking something that an operator or provider of the ALTO
server would do, rather than the ALTO server itself?

I have a similar question about
8.2.
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.2>Considerations
for Choosing Updates
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-choosing>

TIPS should be cognizant of the effects of its update schedule, which
includes both the choice of timing (i.e., when/what to trigger an update on
the updates graph) and the choice of message format (i.e., given an update,
send a full replacement or an incremental change).


and


Therefore, each TIPS may decide on its own whether to use JSON merge patch
or JSON patch according to the changes in network maps.

is TIPS thinking, or is that up to a human?

And in
8.6.
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.6>Considerations
for Updates to Ordinal Mode Costs
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-updates-t>

While this document allows TIPS to offer incremental updates for ordinal
mode cost maps, TIPS implementors should be aware that incremental updates
for ordinal costs are more complicated than for numerical costs, and ALTO
clients should be aware that small changes may result in large updates.


I'm guessing that ALTO clients aren't aware.


I'm not sure I've caught all of these occurrences, but perhaps the GenArt
reviewer will notice others, if they are present!