[fetch] Add flag to indicate delay-tolerant Request, to enable request coalescing. (#184)

Some requests initiated both by the browser and the application are _delay tolerant_ (for relatively small values of "delay") - e.g. beacons, polling for updates, background sync requests, error reports, etc.

I think we should allow both the browser and applications to signal this when initializing the Request, via an additional flag. When such flag is present, the browser can coalesce network access and improve energy + network efficiency... Waking up the radio incurs a lot of overhead regardless of transfer size (due to timeout logic in the controller that keeps the radio active for some period of time), and coalescing multiple requests to fire at once would help amortize that cost and reduce overall energy footprint.

Implementing this kind of coalescing functionality in app-space is hard / impossible: it requires explicit coordination between all actors that initiate fetches (third party scripts, iframes, plus other browser processes, etc); there isn't sufficient information to infer whether radio is active or not.

---

In terms of implementation, the browser can do the following:
- If radio is already active then dispatch request immediately
- If radio is not active, append request to buffer
  - Whichever happens soonest: 
     - Start X second timer, which, if invoked takes all requests in buffer and dispatches them.
     - If network interface becomes active (e.g. another process wakes it up), then take all requests in buffer and dispatch them + cancel timer.
     - If a non-coalesced request needs to be sent, queue it and all requests in the buffer + cancel timer.

In other words, delay-tolerant requests would be sent immediately within at most X seconds from being queued, and sooner if network interface becomes - or is, already - active.

Nothing needs to change in terms of processing on the client: the promise would get resolved when response is received; rejected if request fails. The extra "delay" due to coalescing would look as if there is a long RTT to the server.

In terms of consumers that could leverage this: Beacon API, Reporting API, background sync, and application code that's emitting delay tolerant requests.



---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/184