{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webrtc-quic/issues/7","repository_url":"https://api.github.com/repos/w3c/webrtc-quic","labels_url":"https://api.github.com/repos/w3c/webrtc-quic/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webrtc-quic/issues/7/comments","events_url":"https://api.github.com/repos/w3c/webrtc-quic/issues/7/events","html_url":"https://github.com/w3c/webrtc-quic/issues/7","id":318996860,"number":7,"title":"setTargetBufferedAmount & receive window","user":{"login":"shampson","id":6474514,"avatar_url":"https://avatars3.githubusercontent.com/u/6474514?v=4","gravatar_id":"","url":"https://api.github.com/users/shampson","html_url":"https://github.com/shampson","followers_url":"https://api.github.com/users/shampson/followers","following_url":"https://api.github.com/users/shampson/following{/other_user}","gists_url":"https://api.github.com/users/shampson/gists{/gist_id}","starred_url":"https://api.github.com/users/shampson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shampson/subscriptions","organizations_url":"https://api.github.com/users/shampson/orgs","repos_url":"https://api.github.com/users/shampson/repos","events_url":"https://api.github.com/users/shampson/events{/privacy}","received_events_url":"https://api.github.com/users/shampson/received_events","type":"User","site_admin":false},"labels":[{"id":918703889,"url":"https://api.github.com/repos/w3c/webrtc-quic/labels/PR%20exists","name":"PR exists","color":"fcaeb0","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-04-30T18:56:43Z","updated_at":"2018-05-03T21:58:42Z","closed_at":null,"author_association":"NONE","body":"**Steps 5/6 of setTargetBufferedAmount:**\r\n_5. If amount is greater than or equal to stream's [[ReadBufferedAmount]] slot, set stream's maximum receive window to amount._\r\n_6. ...then set the maximum receive window to amount._\r\n\r\nI discussed this with Peter about the [[TargetReadBufferedAmount]], and we concluded:\r\n\r\n- The target read buffered amount shouldn't directly set the backpressure window size. It's more for the app to be able to fill a the read buffer up to a given amount with data while it's busy doing something else.\r\n- It smooths out how data is read in to JavaScript. Without it there would be problems if data came in faster than it could be processed\r\n- We don't want to set the receive window size directly to be the [[TargetReadBufferedAmount]]. The targetReadBufferedAmount attribute should represent the target number of bytes in the receive buffer _in addition to the receive window_. This allows protocol level control of the receive window separate from the application.\r\n\r\nChanges I propose:\r\n\r\n- Update definition of targetReadBufferedAmount \"represents the target number of bytes in the read buffer\" --> \"represents the target number of bytes in the receive buffer in addition to the receive window\"\r\n  - Update this in setTargetReadBuffered amount as well\r\n- Clarify how setTargetBufferedAmount is for smoothness\r\n- Remove setTargetBufferedAmount steps 5/6\r\n- Do we want [[TargetReadBufferedAmount]] to default to 0? It currently defaults to the maximum read buffer size."},"comment":{"url":"https://api.github.com/repos/w3c/webrtc-quic/issues/comments/386450056","html_url":"https://github.com/w3c/webrtc-quic/issues/7#issuecomment-386450056","issue_url":"https://api.github.com/repos/w3c/webrtc-quic/issues/7","id":386450056,"user":{"login":"taylor-b","id":14118599,"avatar_url":"https://avatars3.githubusercontent.com/u/14118599?v=4","gravatar_id":"","url":"https://api.github.com/users/taylor-b","html_url":"https://github.com/taylor-b","followers_url":"https://api.github.com/users/taylor-b/followers","following_url":"https://api.github.com/users/taylor-b/following{/other_user}","gists_url":"https://api.github.com/users/taylor-b/gists{/gist_id}","starred_url":"https://api.github.com/users/taylor-b/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/taylor-b/subscriptions","organizations_url":"https://api.github.com/users/taylor-b/orgs","repos_url":"https://api.github.com/users/taylor-b/repos","events_url":"https://api.github.com/users/taylor-b/events{/privacy}","received_events_url":"https://api.github.com/users/taylor-b/received_events","type":"User","site_admin":false},"created_at":"2018-05-03T21:58:42Z","updated_at":"2018-05-03T21:58:42Z","author_association":"NONE","body":"Stepping back a bit: what are some specific use cases for this API? I understand it's for applying backpressure, but when would an application want this? The memory required to buffer data isn't really a concern. So is this API expected to be mainly used to limit latency for any request/response based protocol?\r\n\r\nFor example: Suppose an application knows it can process 100 requests/second, it wants to guarantee a response within 2 seconds, and knows each request is around 1000 bytes. It could then set `targetReadBufferedAmount` to 100 * 2 * 1000 = 200000, such that even if the buffer is filled, it can generate a response in time. On the originating sender's side, if the receiver's buffer is full, the sender will not be able to write, so instead of sending a request it will just discard it.\r\n\r\nThe problem with directly setting the \"[receive window](https://cs.chromium.org/chromium/src/net/quic/core/quic_flow_controller.h?l=176&rcl=4d96f549921aee8c95064ca88a5dd16e6334aa3a)\" size (defined as \"maximum amount of unconsumed + in-flight bytes\") is that it can create a bottleneck, depending on the round trip time. Suppose the RTT is 5 seconds in the above example; this would only allow 40 requests per second to be sent due to the additional data in flight. So to deal with this, maybe the application would want to set `targetReadBufferedAmount` to `max(rtt, latency_sla) * request_size * requests_per_second` (500000 in this case). Or do something similar.\r\n\r\nSeth's suggestion is to instead say `targetReadBufferedAmount` \"represents the target number of bytes in the receive buffer in addition to the receive window\". So, `RTCQuicStream` would immediately consume and buffer up to `targetReadBufferedAmount` bytes from the underlying QUIC stream, and then rely on the QUIC flow controller to [automatically increase](https://cs.chromium.org/chromium/src/net/quic/core/quic_flow_controller.cc?l=114&rcl=a1b71cc69d7b36a9d87980a091d2d79ee4b966ea) the receive window size based on RTT. The downside is that this means less application control; the QUIC implementation may end up increasing the receive window to a size larger than the application would have wanted, possibly resulting in well over `targetReadBufferedAmount` bytes being buffered.\r\n\r\nSo... with that in mind, I'm somewhat leaning towards saying `targetReadBufferedAmount` **does** directly control the receive window. More control here seems like a good thing. Though this may depend on what use cases the API is intended for, which is why I ask."}}
{"actor":{"display_login":"taylor-b"}}