Re: [w3c/ortc] RTCQuicTransport: Addition of createStream and onstream (#783)

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