Supporting uncapped outgoingMaxBufferedDatagrams is burdensome #806

Supporting outgoingMaxBufferedDatagrams larger than the UA's network buffer seems counterproductive.

The spec says the datagram send queue in underlying sinks can "be optimized to be in another process for max throughput."

But in the same breath, it lets websites set the size of this queue to 4294967295.

This forces the UA to buffer needlessly in the content process when it only needed to wave through enough datagrams to saturate its IPC.

Firefox example

Neqo (the networking code in Gecko's parent process) caps bytes it will buffer parent-side per-sink at 256 KB.

Say outgoingMaxBufferedDatagrams = 4000 and you write 4000 datagrams at once:

To be compliant, the underlying sink would have to waive through and temporarily store all 4000 chunks into sink memory content-side immediately, before beginning to IPC over a subset (say ~256) to the parent until empty:

WritableStream [0] -> sink (content-side [3744] -> IPC -> parent-side [256]) -> network

But Firefox does something different: internally it signals back pressure over IPC anyway, so it just signals that up by withholding resolving the sink promise:

WritableStream [3744] -> sink (content-side [0] -> IPC -> parent-side [256]) -> network

This seems more robust—let the WritableStream buffer instead—and simplifies implementation of the sink queue.

Unfortunately, the difference is JS observable.

Proposal

I see a couple of ways to change the spec:

1. Put an observable UA cap on outgoingMaxBufferedDatagrams values, OR
2. Modify sendDatagrams algorithm to add a (byte-based?) cap there

The latter would allow for a byte-based cap, which might help implementers.

Thoughts?