[PATCH] QUIC: optimized sending stream response

[Sergey Kandaurov]

> On 23 Feb 2023, at 15:49, Roman Arutyunyan <arut at nginx.com> wrote:
> 
> # HG changeset patch
> # User Roman Arutyunyan <arut at nginx.com>
> # Date 1677152799 -14400
> #      Thu Feb 23 15:46:39 2023 +0400
> # Branch quic
> # Node ID 6d471753917c083b4044f73557f9af8d91c20d36
> # Parent  3c33d39a51d334d99fcc7d2b45e8d8190c431492
> QUIC: optimized sending stream response.
> 
> When a stream is created by client, it's often the case that nginx will send
> immediate response on that stream.  An example is HTTP/3 request stream, which
> in most cases quickly replies with at least HTTP headers.
> 
> QUIC stream init handlers are called from a posted event.  Output QUIC
> frames are also sent to client from a posted event, called the push event.
> If the push event is posted before the stream init event, then output produced
> by stream may trigger sending an extra UDP datagram.  To address this, push
> event is now re-posted when a new stream init event is posted.
> 
> An example is handling 0-RTT packets.  Client typically sends an init packet
> coalesced with a 0-RTT packet.  Previously, nginx replied with a padded CRYPTO
> datagram, followed by a 1-RTT stream reply datagram.  Now CRYPTO and STREAM
> packets are coalesced in one reply datagram, which saves bandwidth.
> 

For the record, there are use-cases in connections without 0-RTT:

- response to the 1st 1-RTT request in a new connection could be sent
separately, because push event was already posted.

The first 1-RTT request is usually coalesced with Init(ACK)+HS(ACK,CRYPTO)
which are handled before 1-RTT and are the reason of posted push event.

- additionally, handling of ACK+STREAM packets resulted in corresponding
MAX_STREAMS and STREAM frames sent in separate packets/datagrams.

Although it doesn't result in noticeable bandwidth waste unlike with 0-RTT,
this is extra packets and cpu cycles spent on their serialization.

> diff --git a/src/event/quic/ngx_event_quic_streams.c b/src/event/quic/ngx_event_quic_streams.c
> --- a/src/event/quic/ngx_event_quic_streams.c
> +++ b/src/event/quic/ngx_event_quic_streams.c
> @@ -472,6 +472,17 @@ ngx_quic_get_stream(ngx_connection_t *c,
> 
>         if (qc->streams.initialized) {
>             ngx_post_event(rev, &ngx_posted_events);
> +
> +            if (qc->push.posted) {
> +                /*
> +                 * It's highly likely the posted stream will produce output
> +                 * immediately.  By postponing the push event, we coalesce
> +                 * the stream output with queued frames in one UDP datagram.
> +                 */
> +
> +                ngx_delete_posted_event(&qc->push);
> +                ngx_post_event(&qc->push, &ngx_posted_events);
> +            }
>         }
>     }

Looks good.

-- 
Sergey Kandaurov