- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Jan 2019 22:13:16 +0000
- To: public-webrtc-logs@w3.org
Can we also agree that given that the maximum value supported by SCTP for `a_rwnd` is 4Gib, choosing a 1MiB value in Firefox is an arbitrary decision (probably driven by the sctp stack used) and that nothing prevents other datachannels implementations to use much higher values and implement it as described? (not saying that we should ignore the cost of firefox to migrate to the proposed solution, which should be also taken in consideration of course) For me 2) is a no go too. But there is a 4) option, that mixes 1), considering current API as unsuitable and your stream API. Please, let me explain: Let's consider that we define the JS app as the ULP sctp stack, then the `a_rwnd` will define the maximum amount of data that the browser is willing to have allocated in memory in the different layers, buffers and event queues. The obvious conclusion is that `max-message-size` must be lower than the `a_rwnd`. Given that both values are know by the sender, it is sender's responsibility to calculate the total size of the messages being sent by ndata and do not send more messages in parallel if the total size would exceed the `a_rwnd`. That will prevent deadlocks. As a consequence, current API will only be suitable for "small" messages (which shouldn't be a problem given current Chrome's maximum message size of 65KiB). For larger messages, both the sender and receiver must use your stream API, that will not take into account the `max-message-size` (it will have no limit in size). As the sender will not know which API will be used by the receiver, this messages should use a new `PPID`, that will allow to cleanly deliver a different type on the event for the stream types. There is also no need for a different back-pressure per datachannel for the streams api, as the `a_rwnd` will be increased when the data is actually poped-up, and the only way it can be drained is if the js app is not actually poping data from it (in one or several datachannels, in which case halting the sctp association is the good behavior imho). Obviously, data should not be buffered if no-one is listening for the stream events, and `a_rwnd` increased immediately. As a bonus, this will solve what to do with string messages for the stream api (only binary data would be supported), will not break status-quo and provide "API compatibility" as everyone is chunking data into small messages to support chrome already. -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458322900 using your GitHub account
Received on Monday, 28 January 2019 22:13:17 UTC