Early Review of draft-ietf-alto-new-transport-07
review-ietf-alto-new-transport-07-tsvart-early-aboba-2023-03-15-00

This is an early review of draft-ietf-alto-new-transport-07

The comments below are coming from a perspective based on recent work on media
delivery over QUIC in which scalable video coding can be combined with HTTP/3
and/or WebTransport features supporting partial reliability so as to deliver
media that is both resilient as well as low-latency.  However, the
considerations described below may not apply to ALTO, so please feel free to
ignore them if they make no sense.

Overall, the document does not lay out the transport requirements explicitly,
and so it is hard for me to tell whether the proposed design is optimal or not.
 In particular, it would be useful to understand the desired reliability vs.
latency tradeoff, as well as the requirements for backward compatibility (e.g.
need to operate over HTTP 1.x as well as HTTP/2 and HTTP/3).

There seems to be a requirement for the protocol to support HTTP 1.x as well as
HTTP/2 and HTTP/3, but this is not stated explicitly, nor is it justified. In
other WGs desiring to use the new capabilities of HTTP/3, a decision has
sometimes been made to limit the level of backward compatibility (e.g. support
for HTTP/3 and HTTP/2 only) in order to make it possible to take full advantage
of the features of HTTP/3.  This decision is easier to make for a new protocol
than for one which already has significant HTTP 1.x deployment. So if the
transport approach used here is contrained by the existing HTTP/1.x
deployments, it would be useful to say so up front.

Also, the requirements for reliability and latency are not explicitly laid out.
The diagrams show incremental update N+1 always depending on update N.  Is this
an inherent limitation imposed to meet a requirement, or is it a choice that
could potentially be modified? For example, do bad things happen if a client
were to obtain a coherent set of information at times N and N+2 but not at time
N+1? Or would it be better to delay receipt of the N+2 info so as to allow for
the retransmission of N+1 info?

There is a tradeoff between latency and reliability that can be made if layered
coding can be permitted.  For example, if it is possible to modify the
dependencies, a client wouldn't necessarily have to obtain every update (e.g.
if the bandwidth was insufficient to allow them all to be delivered within the
required time frame).

Are there circumstances where such a tradeoff would be desirable?  As an
example, there could be a base layer of updates where update N+2 depends on
update N, and an extension layer (with higher update frequency) where update
N+1 depends on update N.  The client could request both layers if it could
handle the higher frequency, or just the base layer if it could not. A diagram
describing this kind of two-layer dependency structure is here:
https://www.w3.org/TR/webrtc-svc/#L1T2*

ALthough such an approach does have lower coding efficiency, it can potentially
respond better to situations in which the client's bandwidth availability can
vary substantially, by taking fuller advantage of HTTP/3, allowing the client
to restore sync even if a "discardable" update were not delivered, as long as
the stream of "non-discardable" updates could be delivered.