{"action":"created","issue":{"url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/83","repository_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket","labels_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/83/labels{/name}","comments_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/83/comments","events_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/83/events","html_url":"https://github.com/ReactiveSocket/reactivesocket/issues/83","id":130863542,"number":83,"title":"Stream Byte Flow Control","user":{"login":"benjchristensen","id":813492,"avatar_url":"https://avatars.githubusercontent.com/u/813492?v=3","gravatar_id":"","url":"https://api.github.com/users/benjchristensen","html_url":"https://github.com/benjchristensen","followers_url":"https://api.github.com/users/benjchristensen/followers","following_url":"https://api.github.com/users/benjchristensen/following{/other_user}","gists_url":"https://api.github.com/users/benjchristensen/gists{/gist_id}","starred_url":"https://api.github.com/users/benjchristensen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjchristensen/subscriptions","organizations_url":"https://api.github.com/users/benjchristensen/orgs","repos_url":"https://api.github.com/users/benjchristensen/repos","events_url":"https://api.github.com/users/benjchristensen/events{/privacy}","received_events_url":"https://api.github.com/users/benjchristensen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2016-02-03T00:18:45Z","updated_at":"2016-02-03T17:01:12Z","closed_at":null,"body":"ReactiveSocket already support 2 types of flow control mechanisms:\r\n\r\n- REQUEST_N for application level management of number of items being sent on a stream\r\n- LEASE for a Responder to control the number of requests it can receive\r\n\r\nThere is a potential deficiency if large messages are sent that REQUEST_N will not necessary address.\r\n\r\nFor example, if a large image is sent, it could head-of-line block all other streams, since the image is considered a single item, but could be very large. \r\n\r\nAn implementation can correctly use small fragment sizes in the protocol to ensure it interleaves correctly, but nothing about the protocol currently ensures this is in fact how an implementation will behave. Also, even with fragmentation, nothing will stop that stream from sending everything. \r\n\r\nSo, should we consider modifying the protocol to support the following two improvements?\r\n\r\n1) Default fragmentation size that is generally optimal for public internet (and can be changed if something is better suited in other environments)\r\n2) Byte level credit based flow control like HTTP/2 (https://httpwg.github.io/specs/rfc7540.html#WINDOW_UPDATE) per stream\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/comments/179346413","html_url":"https://github.com/ReactiveSocket/reactivesocket/issues/83#issuecomment-179346413","issue_url":"https://api.github.com/repos/ReactiveSocket/reactivesocket/issues/83","id":179346413,"user":{"login":"tmontgomery","id":1979352,"avatar_url":"https://avatars.githubusercontent.com/u/1979352?v=3","gravatar_id":"","url":"https://api.github.com/users/tmontgomery","html_url":"https://github.com/tmontgomery","followers_url":"https://api.github.com/users/tmontgomery/followers","following_url":"https://api.github.com/users/tmontgomery/following{/other_user}","gists_url":"https://api.github.com/users/tmontgomery/gists{/gist_id}","starred_url":"https://api.github.com/users/tmontgomery/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tmontgomery/subscriptions","organizations_url":"https://api.github.com/users/tmontgomery/orgs","repos_url":"https://api.github.com/users/tmontgomery/repos","events_url":"https://api.github.com/users/tmontgomery/events{/privacy}","received_events_url":"https://api.github.com/users/tmontgomery/received_events","type":"User","site_admin":false},"created_at":"2016-02-03T17:01:11Z","updated_at":"2016-02-03T17:01:11Z","body":"Congestion control, not flow control, is needed to not overflow the network buffering on a hop-by-hop basis. This level of clarity is not what HTTP/2 (or anything built on top of TCP) has and why TCP provides congestion control."}}