search

quicwg / qlog

The IETF I-D documents for the qlog format
Other
83 stars 12 forks source link

Add a way to indicate sent-but-unacked data #186

Open rmarx opened 2 years ago

rmarx commented 2 years ago

Once data for a stream is sent in a packet, it has to remain in some form of retransmission buffer (either a separate buffer or as ranges in the main stream buffer or ...) until the data is ACKed as received, only then can it be discarded completely.

At this time, there is no way to track how much sent-but-unacked data is outstanding for a given stream.

The most organic way to do this seems to be to add a new target to the data_moved event. We currently have "user","application","transport","network", where we might regard "network" as being "sent but unacked", but then we still lack a "discarded" state.

Bikeshedding is possible on the name: "discarded", "resolved", "acknowledged", ... as conceptually we could even replace the "user" target with this one as well, and saying that indicates the data has left the "network protocol stack" (either on the sender or receiver side), terming it as "handled"/"resolved" would make sense there.

cc @LPardue

LPardue commented 2 years ago

There's two transitions here:

Send side: transport -> $foo Receive side: application -> $bar

$bar I think is sufficiently expressed by "user" in my opinion.

For $foo, it's a bit tricky because the current values are all entities, while you've proposed non-entity terms here. Some additional suggestions would be "null", "free", or "terminal" (as in terminal state, not a bash terminal).

The nice thing about modelling a discarding transition is that it can also be used for stream resets. Helps to understand the point in time a transport implementation actually frees any buffers, independent of the RESET_STREAM frame.

rmarx commented 6 months ago

This seems related (at least a bit) to https://github.com/quicwg/qlog/pull/396.

I'm not sure we still want to go down this road (also don't remember what first triggered opening this issue). As it is, it seems like this is something that can be done on a per-implementation basis if needed (using the mechanism I described above), which probably makes most sense since this is mostly for debugging internal memory management, which is unlikely to be the same across stacks (and unlikely to be able to properly use generalized tooling).

Proposal: close without action. What do you think @LPardue ?

rmarx commented 2 months ago

Some final thoughts on this @LPardue or I'll close with no action :)