Re: RTCDataChannel characteristics and failures

On 2014-01-03 10:34, Michael Tuexen wrote:
>> A factor limiting the likelihood of success is that you rely on both the forward transmission and the feedback transmission to work in order to regard the transmission successful. So, you can get stuck retrying even if the receiver got the data.
>> >I know you said that it might not be the path limit of 5 retries that should be used but possibly imore towards the 10 Association retries. But that also increases the stall time during retransmissions so that at least the real-time text data I am thinking of would be severely stale when the channel finally succeeded or broke.
> This is the normal tradeoff. However, I'm not sure if this is relevant at all. According to
> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-00
> we will teardown the peer connection after 15 seconds.
Interesting. Yes, that changes a lot.
But that draft needs a congestion considerations section. It starts 
intensive retransmissions at the moment that it suspects network 
problems. I think that is the opposite to what you are expected to do.
Anyway, assuming that a mechanism with that goal will be in place, you 
are right. The risks for stalling more than 15 seconds are much lower.
But it also means that SCTP will rarely get an opportunity to retransmit 
more than 4 times, because it is well behaved and doubles the interval 
between retries to 1, 2, 4, 8 seconds. And 4 retries with a requirement 
that also the feedback must be received is just medium reliability.



>> >
>> >Already the 5 retries could span over 30 to 60 seconds on rapid networks, so I do not think it is realistic to extend the retry number over 5.
>> >
>> >It of course all depends on what packet loss rate you need to calculate with, if you have a type of communication that need to work also in catastrophy situations.
>> >
>> >My brief calculations indicate that in a bad situation with 15% packet loss, and the reliable channel used for rea-time text time sampled and transmitted at 300 ms intervals would experience more than 10 seconds stalling once per minute and break of the channel after 30 seconds stalling for retries would happen with a mean interval of 11 minutes.
>> >
>> >What else can an application do than reconnect and offer the user to continue?
>> >
>> >At up to about 3 % packet loss it seems to perform excellently and can really be called reliable.
>> >
>> >A first action would be to include information in the API about how various kinds of failures are signaled.
>> >
>> >And for the application of real-time text we still need to consider all the alternatives discussed about a year ago:
>> >RTP
>> >Reliable data channel
>> >Semi-reliable data channel with a timeout that the user can accept and reconnection for continuing.
>> >Unreliable data channel and forward error correction applied.
>> >Transmission external to webrtc, through WebSocket or so and proper action against long stalling in failure situations.
> I'm not familiar with real time text. But for me it looks like you create messages (lines of text)
> which you want to transmit reliably, but the messages (each line of text) changes over the time
> it is written. So you have multiple generations of a message and a newer generation of the message
> replaces any older one.
The goal is to have a more live text conversation than messaging. Get 
away with the waiting periods for new messages to be completed and keep 
the conversation going. The receiver can read the text while it is typed.
Traditionally we do it with time sampling, just like audio or video but 
with longer sampling times. Usually 300 ms, but 700 is also specified.
So we send what has been typed during each such sampling interval with 
quite good robustness.

It could be possible to do it the way you describe, but then there is a 
risk that the transmission each time gets larger and larger. Users can 
keep on typing quite long without ending a message and we would need to 
force artificial end of messages to guarantee that the amount of 
transmitted data does not become overwhelming.

Usually, when using time sampled text, there is just 1-5 characters of 
text payload per transmission. With your scheme we have the risk of 
sending 1000 characters three times a second just in case something goes 
wrong in the transmission.

The most implemented standard for real-time text makes use of RTP, and 
transmits everything three times with 300 ms intervals. So it is forward 
error correction with two generations of redundancy.

> This sounds like another PR-SCTP policy, where you send each message
> with an ID and any message within the SCTP stack with the same ID would be abandoned. That
> way you would only try to send the latest version of each line of text.
> The receiver would always display the latest information it has.
>
> Wouldn't that work?
Interesting thought.

Regards
Gunnar
>
> Best regards
> Michael
>> >
>> >
>> >A first action would be to include information in the API about how various kinds of failures are signaled, as I have made an initial proposal earlier in this thread.
>> >
>> >Regards,
>> >
>> >Gunnar
>> >
>> >
>> >
>>> >>
>>> >>Best regards
>>> >>Michael
>>>> >>>

Received on Friday, 3 January 2014 10:27:31 UTC