Disable batched write in QuicWriteBlockedList.

As a reminder, HTTP/3 streams have two priority-related parameters received from
the clien in PRIORITY_UPDATE frames: urgency (int) and incremental (bool).

Writes can be continuous or round-robin. With continuous writes, if data is
written on a given stream, writing contiues as long as there is data for that
stream. Round-robin writes can be batched or not. If batched, writing on a
stream can continue if less than 16 kB of data has been written continuously on
that stream. If not batched, other streams with same urgency get a turn after a
single write. In any case, the size of a single write is not limited by

This applies to streams with the same urgency value. Streams always yield to
streams with higher priority (lower urgency value).

Incremental streams are always written round-robin. If
--gfe2_reloadable_flag_quic_priority_respect_incremental is
false, non-incremental streams are also written round-robin. If it is true, they
are written continuously. This was introduced in cl/511587715.

This CL introduces --gfe2_reloadable_flag_quic_disable_batch_write. If false,
round-robin writes are batched. If true, they are not batched. This applies to
incremental streams, and if
--gfe2_reloadable_flag_quic_priority_respect_incremental is false, then to
non-incremental streams as well.

An additional optimization is to prioritize the non-incremental stream with the
last write over incremental streams even if there was a write on the incremental
stream in the meanwhile (due to the non-incremental stream not having data to
write).  While this sounds unfair (in the sense that incremental streams may be
starved), this is no worse than incremental streams being blocked by a
non-incremental stream that can provide write data continuously.  The rationale
is that data on a non-incremental stream is useless for the client until all of
it is received, so once some of it was sent, send all of it.  (Note that
incremental streams do not immediately yield to other non-incremental streams
that have started writing, only to the most recent one.  They get at least one
turn to write their own data.)

Protected by FLAGS_quic_reloadable_flag_quic_disable_batch_write.

PiperOrigin-RevId: 516822305
6 files changed
tree: 348f95b4813760e0f4adcff9bc6f228da26c5358
  1. build/
  2. depstool/
  3. quiche/
  4. .bazelrc
  5. BUILD.bazel
  8. README.md
  10. WORKSPACE.bazel


QUICHE stands for QUIC, Http, Etc. It is Google‘s production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools. It powers Google’s servers, Chromium, Envoy, and other projects. It is actively developed and maintained.

There are two public QUICHE repositories. Either one may be used by embedders, as they are automatically kept in sync:

To embed QUICHE in your project, platform APIs need to be implemented and build files need to be created. Note that it is on the QUICHE team's roadmap to include default implementation for all platform APIs and to open-source build files. In the meanwhile, take a look at open source embedders like Chromium and Envoy to get started:

To contribute to QUICHE, follow instructions at CONTRIBUTING.md.

QUICHE is only supported on little-endian platforms.