prop340: clarify SENDME window accounting

1 files changed, 26 insertions, 0 deletions

diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 2407f99..f760e0e 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -286,6 +286,32 @@ Any increase in maximum length for any other message type requires a new
 EXTEND2 messages to be 2000 bytes long, we need to add a new proposal
 saying so, and reserving a new subprotocol version.)
 
+### `SENDME` window accounting
+
+`SENDME` windows count relay *cells* rather than relay *messages*.
+
+A cell counts towards the circuit's `SENDME` window if it contains any part of
+any message that would normally count towards `SENDME` windows (currently only
+`DATA`).
+
+A cell counts towards the `SENDME` window of every stream that it contains
+part of a message for, whose command counts towards `SENDME` windows.
+
+Examples:
+
+* A cell containing a `SENDME` message and a `RESOLVE` message currently
+  wouldn't count towards any windows, since neither of those commands currently
+  counts towards windows.
+* A cell containing a `SENDME` message and a `DATA` message would count towards
+  the circuit window and the `DATA` message's stream's window.
+* A cell containing two `DATA` messages, for different streams, would count
+  towards the circuit-level window and both stream-level windows.
+* A cell containing two `DATA` messages for the *same* stream counts
+  *once* towards the circuit-level and stream-level windows.
+* If `DATAGRAM` messages (proposal 339) are implemented, and count towards
+  windows, then every cell containing a fragment of a `DATAGRAM` message counts
+  towards windows.
+
 # Appendix: Example cells
 
 Here is an example of the simplest case: one message, sent in one relay cell: