Re: RTCDataChannel characteristics and failures

On Jan 3, 2014, at 11:26 AM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:

> 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.
Yes, it does retransmit every 500ms without exponential backoff....
> 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.
Correct.
> 
> 
> 
>>> >
>>> >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.
So in real time text there are no boundaries like lines? Then one would need to
app level acking to avoid retransmitting the hole conversation over and over.
> 
> 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.
And what happens if you loose all three? Then you are missing some text, right? Are you blocking the
the characters which are send after that for 900ms? That would make it an unreliable, ordered channel
of characters...

Best regards
Michael
> 
>> 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:40:04 UTC