atomicWrite clarification needed

[jesup]

A few issues with atomicWrite:

1. It's unspecified whether QUIC framing overhead (5-17 bytes I think) would be included in the quota available calculation (though by implication it is). We may want to be more explicit here. We also could assume worse-case in an implementation (17 I think).
2. "could not be sent in its entirety within the flow control window that is current at the time of sending" -- so if there are extant write()s (or atomicWrites) that have not actually been sent yet, do we have to either a) include those in the quota available calculation, or b) wait until they are sent, then check quota? If a), this may impact point 1 since calculating the QUIC overhead if there's multiple packets of data queued may be hard. I'm assuming b).

[jan-ivar]

On 1, the spec only concerns itself with what's required for the promise to resolve: sufficient quota to not be an obstacle. I think we trust browsers to make this calculation (count all framing necessary to work). Unless there's a webcompat issue?

On 2, both a and b count all queued writes, so either seems fine. There's no separate queue for atomic chunks: ...