W3C home > Mailing lists > Public > public-ortc@w3.org > October 2017

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

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 10 Oct 2017 01:37:54 +0000
Message-ID: <CAJrXDUFGLX5KiGwueYckBjPas-TGvvx6nt8dYJq9DRoKjaUefw@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-ortc@w3.org" <public-ortc@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:40:01 UTC