- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Thu, 9 Jan 2014 15:38:35 +0100
- To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
- Cc: Web-rtc <public-webrtc@w3.org>
On Jan 9, 2014, at 1:21 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: > On 2014-01-09 11:39, Michael Tuexen wrote: >> On Jan 9, 2014, at 7:06 AM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: >> >>> I sent the mail below some time ago. Some good related discussions appeared, but no response on my main proposal to add some detail in the API description about characteristics and failures of RTCDataChannels. >>> ---------------------------------------------Repeated proposal--------------------------------------------------------------------------------------------- >>> I would like to see a more detailed description of the characteristics and failure handling of the RTCDataChannel. >>> >>> e.g. in section 5.2, >>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel >>> there is this paragraph: >>> >>> "A RTCDataChannel can be configured to operate in different reliability modes. A reliable channel ensures that the data is delivered at the other peer through retransmissions. An unreliable channel is configured to either limit the number of retransmissions (maxRetransmits) or set a time during which retransmissions are allowed (maxRetransmitTime). These properties can not be used simultaneously and an attempt to do so will result in an error. Not setting any of these properties results in a reliable channel." >> I just realise that maxRetransmitTime, since this time does not limit the time spent >> on retransmissions, but it limits the lifetime of the message. So a name lime >> maxLifeTime or so makes more sense. >> >> You also asked for allowing to limit the lifetime and the number of retransmissions. > Well. I did not, but it was discussed. I do not want to cause more complexity, but rather that the intended functionality and API is fully described. Understood. However, getting the API right might be a good thing. Supporting a combined policy seems doable, at least from the perspective of standardising it in the IETF and implementing it in SCTP. > > I see a risk that the term "reliable channel" and no evident info about failure situations will lead to designs with bad behaving data communications because failure situations will be overlooked. And you have now informed us that 15 seconds of bad network connection will cause a broken channel and undefined knowledge about what was transferred. If that is documented clearly in the API, there is a chance that we can see well behaving applications. >> If that should supported, we need to add a corresponding policy to >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-00.txt >> It would be great to get some feedback soon... >>> 1. The second sentence needs modification. No data transmission can be totally "ensured". >>> I suggest to change to: >>> >>> "In a reliable channel efforts are made to deliver data at the other peer through extensive retransmissions and feedback." >>> >>> 2. In order to support the judgement when a developer want to use the unreliable variants, there need to be a description about approximately how extensive the retransmissions are for the reliable channel. This is hard to describe exactly, because it depends on many factors, such as roundtrip delays, activities in other RTCDataChannels etc, but here is a proposal to continue with a new sentence after the one dealt with in 1): >>> >>> "In reliable channels, retransmissions are made up to between 5 and 10 times if needed, spread over a time that can extend to at least 30 seconds and sometimes many minutes depending on the roundtrip delays of the channel and other factors. If the transmission failures are persistent after the maximum retransmissions, the channel's underlying transport is closed. Both peers are informed about the state change, but the state change can occur at different moments in time for the peers." >>> >>> 3. The information about the unreliable types should have some brief information about what happens when they fail to transmit. Proposal to add last in this paragraph: >>> >>> "If the limit is reached and the transmission is still not acknowledged, the transmission of the current data is abandoned, and transmission is initiated of next queued data item if available." >>> >>> (if that is what happens) >> Other stuff might already being transferred. So there is not necessary this strict >> sequencing. >>> 4. More general information about failures should be provided. Proposal to add one more sentence in the same paragraph: >>> >>> "The status of the channel is also monitored through heartbeats, and lack of a number of heartbeats from the peer, or closing of other channels in the PeerDataConnection will cause the channel to be teared down." >> Channels are not monitored. The STUN connection is and the SCTP association is. >>> 5. Details in the API description. >>> The indications about the functionality described above and suggested to the paragraph in 5.2, then needs to be detailed in the API descriptions elsewhere in chapter 5. >> Best regards >> Michael > Who drafts something in the API description and get it in? You Michael? I'm not a member of W3C, just an observer... I'm authoring documents in the IETF, which are SCTP related (and implemented the stuff in the SCTP stack). Best regards Michael > > I have tried to contribute, but as seen in the above discussion, the wording is not good yet, and there are other parts with more exact failure reason coding etc needed. > > Thanks, > Gunnar >>> >>> Some of the characteristics need to be agreed with the draft-ietf-rtcweb-data-channel and the underlying SCTP. >>> >>> >>> Regards >>> >>> Gunnar Hellström > > >
Received on Thursday, 9 January 2014 14:38:59 UTC