Skip to main content

Early Review of draft-ietf-alto-new-transport-07

Request Review of draft-ietf-alto-new-transport
Requested revision No specific revision (document currently at 22)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2023-03-28
Requested 2023-03-13
Requested by Mohamed Boucadair
Authors Kai Gao , Roland Schott , Y. Richard Yang , Lauren Delwiche , Lachlan Keller
I-D last updated 2023-03-15
Completed reviews Httpdir Last Call review of -14 by Martin Thomson (diff)
Secdir Last Call review of -15 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -15 by Linda Dunbar (diff)
Iotdir Telechat review of -17 by Wesley Eddy (diff)
Intdir Telechat review of -16 by Bob Halley (diff)
Artart Early review of -01 by Spencer Dawkins (diff)
Secdir Early review of -07 by Donald E. Eastlake 3rd (diff)
Opsdir Early review of -07 by Sheng Jiang (diff)
Rtgdir Early review of -07 by Russ White (diff)
Tsvart Early review of -07 by Dr. Bernard D. Aboba (diff)
Artart Early review of -07 by Spencer Dawkins (diff)
Httpdir Early review of -07 by Martin Thomson (diff)
The document is currently in the WGLC. Directorate review comments will be addressed as part of the WGLC. 

Thank you.
Assignment Reviewer Dr. Bernard D. Aboba
State Completed
Request Early review on draft-ietf-alto-new-transport by Transport Area Review Team Assigned
Posted at
Reviewed revision 07 (document currently at 22)
Result Not ready
Completed 2023-03-15
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:*

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.