Two comments: On Tue, Nov 21, 2023 at 7:09 AM Kai GAO <[email protected]> wrote:
> - I didn't find any explanation of how the "Concurrent, non-blocking update >> > transmission" requirement is meet by the new transport. is this solved by >> the >> use of HTTP/3 with uses QUIC and does not have HOL blocking within a >> connection? Or is this addressed by multiple concurrent HTTP connection >> to the >> ALTO server? This need to be understood better and we should define what >> actually "Concurrent, non-blocking update transmission" means in this >> context >> of fetching updates. >> >> HTTP/2 was of course intended to be non-blocking at the application layer. Resources can be delivered whenever they are ready, instead of in order of request. That's pretty important for update use cases like this one. Of course, it doesn't solve blocking related to packet loss -- that's what QUIC is for. But it's totally accurate to say that this transport provides non-blocking transmission under either version of HTTP. > > [KAI] The requirement basically requires that incremental updates can be > transmitted > at the same time (concurrent) and the transmission of one update will not > be blocked > by the transmission of another update. This can be realized by 1) multiple > HTTP > connections, or 2) HTTP/3 using multiple streams. This is compared with > RFC 8895 > where SSE multiplexes the updates in a single sequence. You make a good > point that > we should clarify how this can be done with new transport. We will add a > paragraph to > Sec 2.1 and upload a revision soon. > I don't see a new paragraph in Sec 2.1 in draft-18. Please post a new draft with the change, or update this thread with your changed intent.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
