From 95826e3e2ed1d1fccaa7a20311de8c226aed1bb7 Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Mon, 4 Nov 2024 16:31:19 +0000 Subject: [PATCH] Indicate send blocking in data_moved events Fixes #132 (if merged). It struck me that its the "data_moved" action that can be blocked, so rather than add a separate event, just add an optional field to an existing event. This helps ensure we can represent both stream and datagram data with all relevant fields. --- draft-ietf-quic-qlog-quic-events.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/draft-ietf-quic-qlog-quic-events.md b/draft-ietf-quic-qlog-quic-events.md index 4a6f2c65..c1c09112 100644 --- a/draft-ietf-quic-qlog-quic-events.md +++ b/draft-ietf-quic-qlog-quic-events.md @@ -1200,6 +1200,12 @@ processed first and afterwards the application layer reads from the streams with newly available data). This can help identify bottlenecks, flow control issues, or scheduling problems. +The `blocked_reason` field supports optional logging of information related to +stream writes getting blocked, either in full or in part. For example, if an +application intended to write data to a stream but was blocked from sending +anything due to congestion control, it can log the `congestion_control` reason +and omit the length field. + The `additional_info` field supports optional logging of information related to the stream state. For example, an application layer that moves data into transport and simultaneously ends the stream, can log `fin_set`. As @@ -1222,6 +1228,8 @@ QUICStreamDataMoved = { ? from: $DataLocation ? to: $DataLocation + ? blocked_reason: $BlockedReason + ? additional_info: $DataMovedAdditionalInfo ? raw: RawInfo @@ -1233,6 +1241,15 @@ $DataLocation /= "application" / "transport" / "network" +$BlockedReason /= "scheduling" / + "pacing" / + "amplification_protection" / + "congestion_control" / + "connection_flow_control" / + "stream_flow_control" / + "stream_id" / + "application" + $DataMovedAdditionalInfo /= "fin_set" / "stream_reset" ~~~ @@ -1259,6 +1276,12 @@ are processed first and afterwards the application layer reads all Datagrams at once). This can help identify bottlenecks, flow control issues, or scheduling problems. +The `blocked_reason` field supports optional logging of information related to +stream writes getting blocked, either in full or in part. For example, if an +application intended to write data to a stream but was blocked from sending +anything due to congestion control, it can log the `congestion_control` reason +and omit the length field. + This event is only for data in QUIC Datagram Frames. For data in QUIC streams, see the `stream_data_moved` event defined in {{quic-streamdatamoved}}. @@ -1270,6 +1293,8 @@ QUICDatagramDataMoved = { ? to: $DataLocation ? raw: RawInfo + ? blocked_reason: $BlockedReason + * $$quic-datagramdatamoved-extension } ~~~