- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Fri, 11 Nov 2011 13:36:55 -0500
- To: public-webrtc@w3.org
On 11/11/2011 1:07 PM, Vincent Scheib wrote: > May I ask for clarification on unreliable? See inline: > > On Mon, Oct 31, 2011 at 12:50 AM, Justin Uberti <juberti@google.com > > In reliable mode, in-order delivery of messaging is guaranteed, which > > implies head-of-line blocking. In unreliable mode, messages may > > arrive out > > of order. In either mode, notifications of message delivery are > > communicated to the application via a callback; in unreliable mode, > > failures (defined as an elapsing of 2 RTT without an acknowledgement) are > > communicated through the same callback. > > In unreliable mode I understand not all messages will be received. > However, what will happen with out of order packets? This recent > documentation from Ericsson Labs concerns me: > https://labs.ericsson.com/apis/web-real-time-communication/documentation#Peer-to-Peer_data > "This data channel is unreliable (as UDP is used for transport) and > packets received out of order are discarded." In unreliable mode, I would strongly disagree with that. Out-of-order packets should be flagged to the application (if by no other means than by providing a sequence #, or by the application being responsible for adding sequence numbers to its own data packets), but the application should decide if they're important or processable. I've had connections *at work* that could get >1% OOO packets on RTP, for *years*, and was running videophone calls from this network all the time. (Some sort of weird router-and-bonded-T1 issue the provider never resolved.) If the app wants to discard them, fine. I would be *ok* (though mildly concerned) with an app asking the system to discard them for it. > It seems preferable for applications to have control over what packets > should be dropped. E.g. Experienced multiplayer game developers have > raised concern over this. > https://twitter.com/#!/azaferakis/status/135030240018841602 "They are > making a severe mistake by automatically discarding out of order > packets" "I agree, it should be up to the application to decide what to > do with out of order packets" etc. Yup. My draft-jesup-rtcweb-data-01 says we'll do unreliable channels, but does NOT say anything about discarding OOO packets; in fact I believe it touches on the application getting the option for OOO delivery, as well as partial-reliability (bounded retries), both of which are properties of SCTP that we could expose. -- Randell Jesup randell-ietf@jesup.org
Received on Friday, 11 November 2011 18:38:16 UTC