xref: /src/crypto/external/apache2/openssl/dist/doc/designs/ddd/REPORT.md

Report on the Conclusions of the QUIC DDD Process
=================================================

The [QUIC Demo-Driven Design process](README.md) was undertaken to meet the OMC
requirement to develop a QUIC API that required only minimal changes to existing
applications to be able to adapt their code to use QUIC. The demo-driven design
process developed a set of representative demos modelling a variety of common
OpenSSL usage patterns based on analysis of a broad spectrum of open source
software projects using OpenSSL.

As part of this process, a set of proposed diffs were produced. These proposed
diffs were the expected changes which would be needed to the baseline demos to
support QUIC based on theoretical analysis of the minimum requirements to be
able to support QUIC. This analysis concluded that the changes needed to
applications could be kept very small in many circumstances, with only minimal
diff sizes to the baseline demos.

Following the development of QUIC MVP, these demos have been revisited and the
correspondence of our actual final API and usage patterns with the planned diffs
have been reviewed.

This document discusses the planned changes and the actual changes for each demo
and draws conclusions on the level of disparity.

Since tracking a set of diffs separately is unwieldy, both the planned and
unplanned changes have been folded into the original baseline demo files guarded
with `#ifdef USE_QUIC`. Viewing these files therefore is informative to
application writers as it provides a clear view of what is different when using
QUIC. (The originally planned changes, and the final changes, are added in
separate, clearly-labelled commits; to view the originally planned changes only,
view the commit history for a given demo file.)

ddd-01-conn-blocking
--------------------

This demo exists to demonstrate the simplest possible usage of OpenSSL, whether
with TLS or QUIC.

### Originally planned changes

The originally planned change to enable applications for QUIC amounted to just a
single line:

```diff
+    ctx = SSL_CTX_new(QUIC_client_method());
-    ctx = SSL_CTX_new(TLS_client_method());
```

### Actual changes

The following additional changes needed to be made:

- `QUIC_client_method` was renamed to `OSSL_QUIC_client_method` for namespacing
  reasons.

- A call to `SSL_set_alpn_protos` to configure ALPN was added. This is necessary
  because QUIC mandates the use of ALPN, and this was not noted during the
  DDD process.

ddd-02-conn-nonblocking
-----------------------

This demo exists to demonstrate simple non-blocking usage. As with
ddd-01-conn-blocking, the name resolution process is managed by `BIO_s_connect`.

It also arbitrarily adds a `BIO_f_buffer` pushed onto the BIO stack
as this is a common application usage pattern.

### Originally planned changes

The originally planned changes to enable applications for QUIC amounted to:

- Change of method (as for ddd-01-conn-blocking);

- Use of a `BIO_f_dgram_buffer` BIO method instead of a `BIO_f_buffer`;

- Use of a `BIO_get_poll_fd` function to get the FD to poll rather than
  `BIO_get_fd`;

- A change to how the `POLLIN`/`POLLOUT`/`POLLERR` flags to pass to poll(2)
  need to be determined.

- Additional functions in application code to determine event handling
  timeouts related to QUIC (`get_conn_pump_timeout`) and to pump
  the QUIC event loop (`pump`).

- Timeout computation code which involves merging and comparing different
  timeouts and calling `pump` as needed, based on deadlines reported
  by libssl.

Note that some of these changes are unnecessary when using the thread assisted
mode (see the variant ddd-02-conn-nonblocking-threads below).

### Actual changes

The following additional changes needed to be made:

- Change of method name (as for ddd-01-conn-blocking);

- Use of ALPN (as for ddd-01-conn-blocking);

- The strategy for how to expose pollable OS resource handles
  to applications to determine I/O readiness has changed substantially since the
  original DDD process. As such, applications now use `BIO_get_rpoll_descriptor`
  and `BIO_get_wpoll_descriptor` to determine I/O readiness, rather than the
  originally hypothesised `SSL_get_poll_fd`.

- The strategy for how to determine when to poll for `POLLIN`, when to
  poll for `POLLOUT`, etc. has changed since the original DDD process.
  This information is now exposed via `SSL_net_read_desired` and
  `SSL_net_write_desired`.

- The API to expose the event handling deadline for the QUIC engine
  has evolved since the original DDD process. The new API
  `SSL_get_event_timeout` is used, rather than the originally hypothesised
  `BIO_get_timeout`/`SSL_get_timeout`.

- The API to perform QUIC event processing has been renamed to be
  more descriptive. It is now called `SSL_handle_events` rather than
  the originally hypothesised `BIO_pump`/`SSL_pump`.

The following changes were foreseen to be necessary, but turned out to actually
not be necessary:

- The need to change code which pushes a `BIO_f_buffer()` after an SSL BIO
  was foreseen as use of buffering on the network side is unworkable with
  QUIC. This turned out not to be necessary since we can just reject the
  BIO_push() call. The buffer should still be freed eventually when the
  SSL BIO is freed. The buffer is not used and is unnecessary, so it is
  still desirable for applications to remove this code.

ddd-02-conn-nonblocking-threads
-------------------------------

This is a variant of the ddd-02-conn-nonblocking demo. The base is the same, but
the changes made are different. The use of thread-assisted mode, in which an
internal assist thread is used to perform QUIC event handling, enables an
application to make fewer changes than are needed in the ddd-02-conn-nonblocking
demo.

### Originally planned changes

The originally planned changes to enable applications for QUIC amounted to:

- Change of method, this time using method `QUIC_client_thread_method` rather
  than `QUIC_client_method`;

- Use of a `BIO_get_poll_fd` function to get the FD to poll rather than
  `BIO_get_fd`;

- A change to how the `POLLIN`/`POLLOUT`/`POLLERR` flags to pass to poll(2)
  need to be determined.

  Note that this is a substantially smaller list of changes than for
  ddd-02-conn-nonblocking.

### Actual changes

The following additional changes needed to be made:

- Change of method name (`QUIC_client_thread_method` was renamed to
  `OSSL_QUIC_client_thread_method` for namespacing reasons);

- Use of ALPN (as for ddd-01-conn-blocking);

- Use of `BIO_get_rpoll_descriptor` rather than `BIO_get_poll_fd` (as for
  ddd-02-conn-nonblocking).

- Use of `SSL_net_read_desired` and `SSL_net_write_desired` (as for
  ddd-02-conn-nonblocking).

ddd-03-fd-blocking
------------------

This demo is similar to ddd-01-conn-blocking but uses a file descriptor passed
directly by the application rather than BIO_s_connect.

### Originally planned changes

- Change of method (as for ddd-01-conn-blocking);

- The arguments to the `socket(2)` call are changed from `(AF_INET, SOCK_STREAM,
  IPPROTO_TCP)` to `(AF_INET, SOCK_DGRAM, IPPROTO_UDP)`.

### Actual changes

The following additional changes needed to be made:

- Change of method name (as for ddd-01-conn-blocking);

- Use of ALPN (as for ddd-01-conn-blocking).

ddd-04-fd-nonblocking
---------------------

This demo is similar to ddd-01-conn-nonblocking but uses a file descriptor
passed directly by the application rather than BIO_s_connect.

### Originally planned changes

- Change of method (as for ddd-01-conn-blocking);

- The arguments to the `socket(2)` call are changed from `(AF_INET, SOCK_STREAM,
  IPPROTO_TCP)` to `(AF_INET, SOCK_DGRAM, IPPROTO_UDP)`;

- A change to how the `POLLIN`/`POLLOUT`/`POLLERR` flags to pass to poll(2)
  need to be determined.

- Additional functions in application code to determine event handling
  timeouts related to QUIC (`get_conn_pump_timeout`) and to pump
  the QUIC event loop (`pump`).

- Timeout computation code which involves merging and comparing different
  timeouts and calling `pump` as needed, based on deadlines reported
  by libssl.

### Actual changes

The following additional changes needed to be made:

- Change of method name (as for ddd-01-conn-blocking);

- Use of ALPN (as for ddd-01-conn-blocking);

- `SSL_get_timeout` replaced with `SSL_get_event_timeout` (as for
  ddd-02-conn-nonblocking);

- `SSL_pump` renamed to `SSL_handle_events` (as for ddd-02-conn-nonblocking);

- The strategy for how to determine when to poll for `POLLIN`, when to
  poll for `POLLOUT`, etc. has changed since the original DDD process.
  This information is now exposed via `SSL_net_read_desired` and
  `SSL_net_write_desired` (as for ddd-02-conn-nonblocking).

ddd-05-mem-nonblocking
----------------------

This demo is more elaborate. It uses memory buffers created and managed by an
application as an intermediary between libssl and the network, which is a common
usage pattern for applications. Managing this pattern for QUIC is more elaborate
since datagram semantics on the network channel need to be maintained.

### Originally planned changes

- Change of method (as for ddd-01-conn-blocking);

- Call to `BIO_new_bio_pair` is changed to `BIO_new_dgram_pair`, which
  provides a bidirectional memory buffer BIO with datagram semantics.

- A change to how the `POLLIN`/`POLLOUT`/`POLLERR` flags to pass to poll(2)
  need to be determined.

- Potential changes to buffer sizes used by applications to buffer
  datagrams, if those buffers are smaller than 1472 bytes.

- The arguments to the `socket(2)` call are changed from `(AF_INET, SOCK_STREAM,
  IPPROTO_TCP)` to `(AF_INET, SOCK_DGRAM, IPPROTO_UDP)`;

### Actual changes

The following additional changes needed to be made:

- Change of method name (as for ddd-01-conn-blocking);

- Use of ALPN (as for ddd-01-conn-blocking);

- The API to construct a `BIO_s_dgram_pair` ended up being named
  `BIO_new_bio_dgram_pair` rather than `BIO_new_dgram_pair`;

- Use of `SSL_net_read_desired` and `SSL_net_write_desired` (as for
  ddd-02-conn-nonblocking).

ddd-06-mem-uv
-------------

This demo is the most elaborate of the set. It uses a real-world asynchronous
I/O reactor, namely libuv (the engine used by Node.js). In doing so it seeks to
demonstrate and prove the viability of our API design with a real-world
asynchronous I/O system. It operates wholly in non-blocking mode and uses memory
buffers on either side of the QUIC stack to feed data to and from the
application and the network.

### Originally planned changes

- Change of method (as for ddd-01-conn-blocking);

- Various changes to use of libuv needed to switch to using UDP;

- Additional use of libuv to configure a timer event;

- Call to `BIO_new_bio_pair` is changed to `BIO_new_dgram_pair`
  (as for ddd-05-mem-nonblocking);

- Some reordering of code required by the design of libuv.

### Actual changes

The following additional changes needed to be made:

- Change of method name (as for ddd-01-conn-blocking);

- Use of ALPN (as for ddd-01-conn-blocking);

- `BIO_new_dgram_pair` renamed to `BIO_new_bio_dgram_pair` (as for
  ddd-05-mem-nonblocking);

- `SSL_get_timeout` replaced with `SSL_get_event_timeout` (as for
  ddd-02-conn-nonblocking);

- `SSL_pump` renamed to `SSL_handle_events` (as for ddd-02-conn-nonblocking);

- Fixes to use of libuv based on a corrected understanding
  of its operation, and changes that necessarily ensue.

Conclusions
-----------

The DDD process has successfully delivered on the objective of delivering a QUIC
API which can be used with only minimal API changes. The additional changes on
top of those originally planned which were required to successfully execute the
demos using QUIC were highly limited in scope and mostly constituted only minor
changes. The sum total of the changes required for each demo (both planned and
additional), as denoted in each DDD demo file under `#ifdef USE_QUIC` guards,
are both minimal and limited in scope.

Minimal and limited are distinct criteria. If inexorable technical
requirements dictate, an enormous set of changes to an application could be
considered minimal. The changes required to representative applications, as
demonstrated by the DDD demos, are not merely minimal but also limited.

For example, while the extent of these necessary changes varies by the
sophistication of each demo and the kind of application usage pattern it
represents, some demos in particular demonstrate exceptionally small changesets;
for example, ddd-01-conn-blocking and ddd-02-conn-nonblocking-threads, with
ddd-01-conn-blocking literally being enabled by a single line change assuming
ALPN is already configured.

This report concludes the DDD process for the single-stream QUIC client API
design process, which sought to validate our API design and API ease of use for
existing applications seeking to adopt QUIC.