Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

Two comments:

On Tue, Nov 21, 2023 at 7:09 AM Kai GAO <[e-mail]> 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.