Re: RTCDataChannel characteristics and failures

On 2014-01-03 11:39, Michael Tuexen wrote:
> 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?
It is totally up to the conversing user. And with no pressure to 
complete messages to get them sent, some users might take the habit to 
make end of line seldomely while others will do it regularly as in 
messging. It is just no guarantee.
> Then one would need to
> app level acking to avoid retransmitting the hole conversation over and over.
Yes using your thought of transmitting a gradually growing message 
something like that would be needed.
>> 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...
Yes, waiting up to around 0.9 seconds in case something is missing. If 
still missing, insert a character in the text showing that there might 
be a loss here. The character is Unicode "Replacement character"
This is when using the T.140 presentation protocol for real-time text 
that is defined as the real-time text codec used on top of the RFC 4103 
RTP Payload commonly used in SIP and some other multimedia protocols.

There is another real-time text standard now, XEP-0301 for the XMPP 
environment. It is intended to provide opportunity for more lively text 
conversations together with XMPP messaging.  It has other ways to 
achieve robustness.  It has a refresh mechanism performed every 10 
seconds, similar to what you thought about for every sample.

It will be of interest to provide interoperability with these two 
environments from WebRTC, and it would be good to not be forced to 
specify any new thick applications layer.

Gunnar
>
> 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 13:41:04 UTC