- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Jan 2019 18:14:39 +0000
- To: public-webrtc-logs@w3.org
wouldn't that be a different issue? SCTP already has a congestion control (better or worse) that provides back pressure on sender side, causing buffering on sender. El vie., 25 ene. 2019 18:34, Bernard Aboba <notifications@github.com> escribió: > Per data channel flow control won't necessarily solve the problem if there > is also association flow control. We are learning this in QUIC where flow > control of a file transfer on one stream can impact real-time data on > another stream (or potentially DATAGRAM traffic as well). If the > application can't keep up on one stream then that stream can be flow > controlled but this also may consume much of the per-association buffer > limit, resulting in flow control on other streams even if their per-stream > limit is not reached. But the alternative - filling the event queue with > file transfer messages - also affects the timeliness of delivery of real > time data, and potentially in a worse manner if there is no back pressure > on the file transfer. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457652220>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ABBW8yXF0vnffEJuU7bGemqOocSHM60Tks5vG0AlgaJpZM4aS7_J> > . > -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457667394 using your GitHub account
Received on Friday, 25 January 2019 18:14:41 UTC