Hi Bernard, We have made a pre-release of the new transport document based on your review and some others'. You can see the updates using the link below and here is a short summary:
- Requirements for the document are summarized in Section 2.1 Transport Requirements. The requirements are slightly different from what we responded in previous emails. Please take a look and see if these requirements make sense to you. - The ability to offer "layered coding" or as we call shortcuts is preserved but how to do the layered coding is left outside the scope of the document. See sections 7.4 and 9.8 for related specifications and implementation considerations. Please let us know if the updates address your comments. We look forward to your feedback! Diff with -07: https://author-tools.ietf.org/diff?doc_1=draft-ietf-alto-new-transport-07&url_2=https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/releases/download/draft-ietf-alto-new-transport-08-snapshot-20230426/draft-ietf-alto-new-transport-08.txt Best, Kai > -----Original Messages----- > From: kai...@scu.edu.cn > Sent Time: 2023-03-23 00:58:30 (Thursday) > To: "Bernard Aboba" <bernard.ab...@gmail.com> > Cc: tsv-...@ietf.org, alto@ietf.org, draft-ietf-alto-new-transport....@ietf.org > Subject: Re: Tsvart early review of draft-ietf-alto-new-transport-07 > > Hi Bernard, > > Thanks for the enlightening review. Please see the responses inline. > > Best, > Kai > > > > -----Original Messages----- > > From: "Bernard Aboba via Datatracker" <nore...@ietf.org> > > Sent Time: 2023-03-16 04:49:06 (Thursday) > > To: tsv-...@ietf.org > > Cc: alto@ietf.org, draft-ietf-alto-new-transport....@ietf.org > > Subject: Tsvart early review of draft-ietf-alto-new-transport-07 > > > > Reviewer: Bernard Aboba > > Review result: Not Ready > > > > 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. > > > > KAI: I like the connection to media delivery. I see that there are some similarities, > for example, snapshots to I-frames and incremental updates to P-frames. Could you > please give us some pointers to the work you are referring to? > > > 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). > > KAI: You are right and it's a very good suggestion to put forward the > requirements first. We will put a new section in the next revision. Some key > requirements include: > > 1. Availability: Clients can subscribe at any time and are still able to get > a complete snapshot. > 2. Efficiency: Enable concurrent delivery of the update data. Enable selective > delivery of update data. > 3. Backward compatibility: The mechanism can operate over HTTP/1.x as well as > HTTP/2 and HTTP/3. The mechanism should reuse constructs from previous ALTO > standards. > > > > > 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. > > KAI: We will make this requirement explicit in the next revision. Early versions of > this draft does 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 is to make the core mechanism independent of HTTP versions but enable > enhanced features when HTTP/2 or HTTP/3 is used. > > > > > 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? > > > > KAI: Thanks for the comment. One small clarification: the N and N+1 are not id for > the incremental updates, they actually refer to the logical version of the content. > The content of the data is always the same as long as the updates along a legitimate > path from an old version to the new version are applied sequentially. > > It is true that the draft requires that the incremental update from N to N+1 always > exists (to enable long-polling), but it is legitimate to have an incremental update > from N to N+2. So I wouldn't say that it's a choice but it is not a hard constraint > either. Then in the TIPS view the server will return something like: > > <tips-view-root> > - ug > - 0 > - ... > - N > - N+1 > - N+2 <----- This indicates an incremental update from N to N+2 > - N+1 > - N+2 > - N+2 > - N+3 > > Thus, the client can request updates either from N to N+1 and then from N+1 to N+2, or > directly from N to N+2. However, even though the updates can be transmitted in parallel, > they must be applied sequentially, at least with the current coding (JSON merge patch). > > To answer your last two questions, let us assume N+2 and N+1 in the question refer > to the update from N+1 to N+2 and from N to N+1. > > > Do bad things happen if ...? > Yes, the client may potentially get an incorrect result if it applies update N+2 first. > > > Would it be better to delay ...? > That depends. The client can receive update N+2 first but only applies it after applying > update N+1. This may avoid the idle time if transmitting update N+2 takes longer than > applying update N+1, see below. > > Delay: > |---recv n+1---|---retrans n+1---|---recv n+2---| > |-apply n+1-| |---apply n+2---| > > No delay: > |---recv n+1---|---retrans n+1---| > |---recv n+2---| > |-apply n+1-|---apply n+2---| > > > 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. > > > > KAI: Thanks for the comment. We believe the current document does support layered > coding: if a server implements layered coding, the updates can be expressed using > the current update graph structure (maybe we should make this more explicit?). > We do not have the concept of "discardable" updates in the document but it is > possible to achieve higher efficiency by discarding some updates. For example, in > Section 5.1 and 7.2.1, we mention that the client (when using pull mode) and the > server (when using push mode) may not necessarily transmit the stepwise updates > but only take shortest paths in the dependency graph -- any update that is not on > the shortest path can be discarded. > > I like the idea of layered coding. It may speed up the search of shortest path if > upper layer coding is likely to be "shorter" than lower layer coding, like in skip > lists. However, I am not sure that we have a good sense of how to do layered coding > for ALTO resources or more generally JSON objects right now. How about we can add a > section to discuss "layered coding" as a recommendation for server implementation > first? Then we may seek to standardize that with more analysis and evidences of > the benefits.</tips-view-root></nore...@ietf.org> </bernard.ab...@gmail.com> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
