- From: Peter Thatcher <pthatcher@google.com>
- Date: Tue, 10 Oct 2017 01:37:54 +0000
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-ortc@w3.org" <public-ortc@w3.org>
Received on Tuesday, 10 October 2017 01:38:28 UTC
On Mon, Oct 9, 2017 at 1:54 PM Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > Peter said: > > > > “QUIC does have unreliable transport if you're willing to many streams > (one message per stream), which I think is a fine approach as long as it's > performant enough.” > > > > [BA] Are you assuming that the underlying QUIC implementation provides > control over maximum retransmits or packet lifetime? If a message spans > several packets and one or more are lost, an unreliable RTCDataChannel > would want to avoid retransmits. > One can cancel a stream after a certain amount of time. So if you don't want something retransmitted more than Xms, cancel it after Xms. Granted, some control over how many times a given byte is retransmitted may be nice, and perhaps we could allow that some day. But I don't know if that really needs any protocol changes. In implantation could simply not retransmit, right? > > > “I don't see why that is not straightforward. We've already implemented a > prototype of this twice, and both times it was easy and a small amount of > code.” > > > > [BA] Agree that implementation should be straightforward. Was more > concerned about dependencies on IETF standardization. >
Received on Tuesday, 10 October 2017 01:38:28 UTC