Re: [alto] Opsdir early review of draft-ietf-alto-new-transport-07

[Lachlan Keller <[e-mail]>]

Hi Sheng,

Thank you so much for taking the time to review the document.

In regards to your comment, thank you for pointing out the ambiguity. For
some background clarification:

Based on other review comments, Kai has since added a requirements section
about TIPS that mentions HTTP/1.x support is desired for "backwards
compatibility ... as many development tools and current ALTO
implementations are based on HTTP/1.x." Additionally, early versions of
this draft did constrain the HTTP version to HTTP/2 and HTTP/3 but after
the discussion with Mark Nottingham (after the HTTP early review) and the
chairs, we realize that the core of the design does not rely on HTTP/2 or
HTTP/3. Thus, the decision was to make the core mechanism independent of
HTTP versions but enable enhanced features when HTTP/2 or HTTP/3 is used.

To specifically address your issue: the main loop of the TIPS protocol is
that a client receives successive incremental updates of a monitored
resource when the resource changes. This can be done with either Client
Pull defined in Section 6 or Server Push defined in Section 7. Client Pull
is predominately 1 outstanding request at a time to fetch the most recent
update which works regardless of the HTTP version. Server Push only works
over an HTTP/2 or /3 connection as HTTP/1.x doesn't support server push.

Failures that cause a fallback to HTTP/1.x may include the ALTO server not
supporting, say, HTTP/2 or HTTP/3. In which case, the negotiation of the
HTTP protocol version is defined in the respective HTTP RFC documents and
falls outside of the TIPS protocol, which focuses on what goes on after a
persistent connection has been established.

Here is the proposed modification to section 2.5 of the document to clarify
this:
OLD
<name>TIPS with HTTP/1.x<name>

<t>While TIPS is designed to take advantage of newer HTTP features, TIPS
still functions with HTTP/1.x for client pull functionality only, with the
limitation that it cannot cancel any outstanding requests or fetch
resources concurrently over the same connection.<t>

NEW
<name>TIPS with Different HTTP Versions<name>

<t>The HTTP version a connection uses is negotiated between client and
server based on the respective HTTP RFC documents.</t>

 <t>While TIPS is designed to take advantage of newer HTTP features like
server push and substreams for concurrent fetch, TIPS still functions with
HTTP/1.x for client pull defined in Section 6, with the limitation that it
cannot cancel any outstanding requests or fetch resources concurrently over
the same connection due to the blocking nature of HTTP/1.x requests.
Additionally, because HTTP/1.x does not support server push, the use of
TIPS with server push defined in Section 7 is not available if a client
connects to an ALTO server with HTTP/1.x. If a client only capable of
HTTP/1.x desires to monitor multiple resources at the same time, it must
open multiple connections, one for each resource. For HTTP/2 and /3,
because of substreams, multiple resources can be monitored
simultaneously.</t>

On Tue, Apr 4, 2023 at 3:58 AM Sheng Jiang via Datatracker <[e-mail]>
wrote:

> Reviewer: Sheng Jiang
> Review result: Has Nits
>
> Reviewer: Sheng Jiang
> Review result: Ready with Nits
>
> I have reviewed this document as part of the OPS directorate's ongoing
> effort to review all IETF documents being processed by the IESG. Comments
> that
> are not addressed in last call may be included in AD reviews during the
> IESG
> review. Document editors and WG chairs should treat these comments just
> like
> any other last call comments.
>
> Document: draft-ietf-alto-new-transport-07
> Reviewer: Sheng Jiang
> Review Date: 2023-04-04
> Result: Ready with Nits
>
> This document intents for Standards Track. It  document specifies a new
> ALTO Transport Information Publication Service (TIPS), which takes
> advantage
> of HTTP/2 and later versions already support concurrent, non-blocking
> transport of multiple streams in the same HTTP connection. This document
> is well-written and READY with minor Nits (below) for publication.
>
> In section 2.5 "TIPS With HTTP/1.x". This document claims "TIPS
>    still functions with HTTP/1.x for client pull functionality only,
>    with the limitation that it cannot cancel any outstanding requests or
>    fetch resources concurrently over the same connection." However, it is
> unclear what operations/procedure defined in this document will fail when
> TIPS work over HTTP/1.x (also whether there are scenarios the server/client
> have to fall back to HTTP/1.x), the signal or error code the TIPS will
> provide, and how the server and client should act when these failures
> happen.
>
> This looks like an operational hole that authors must fill before
> publication.
> However, I am not sure, if there is no scenarios that the server/client
> have
> to fall back to HTTP/1.x, the authors may simply declare the TIPS SHOULD
> not
> work with HTTP/1.x.
>
>
>
>
>
>