Hi Bernard, Many thanks for the prompt review. Much appreciated!
To ease tracking the points you raised, I created three issues at https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/labels/tsvart. One of these points is related to a pending comment to clarify to what extent the current design adheres to RFC9205, especially the considerations related to the versioning. I trust the authors will engage soon, preferably by addressing separately each of the three key issues. Thanks. Cheers, Med > -----Message d'origine----- > De : Bernard Aboba via Datatracker <[email protected]> > Envoyé : mercredi 15 mars 2023 21:49 > À : [email protected] > Cc : [email protected]; [email protected] > Objet : 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. > > 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 > N+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 > N+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. > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
