- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Thu, 2 Jan 2014 21:53:44 +0100
- To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
- Cc: public-webrtc@w3.org
On Jan 2, 2014, at 9:31 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote: > On 2014-01-02 19:21, Michael Tuexen wrote: >> On Jan 2, 2014, at 1:36 PM, piranna@gmail.com wrote: >> >>> For example, highly coupled realtime tasks like P2P video distribution. You would be interested in have a timeout to don't send info out of time, but also have a max number of retransmits to don't waste bandwidth and try another source. >> The source would apply the PR-SCTP policy, right? How does the source know that messages >> are abandoned? The socket API for SCTP can provide this information, but how do you know >> this in the JS API. Any idea? Who would change another source, since it can't be the source. >> >> Currently SCTP uses an enumeration of policies. To do the above, we would need to >> extend it to handle logical ands and ors of policies. That would required some >> changes to >> https://tools.ietf.org/search/draft-ietf-tsvwg-sctp-prpolicies-00 >> >> What do others think? > I think the application can do the combination, by asking the channel to use the retry limit and the application having a timeout when it looks at the transmit queue, and if it has not moved the application can give up. > > There is sufficient complication in the protocols and APIs to handle the current policies, and we are lacking information in the API description for what happens in different failure and abandoning situations. > > When I have analyzed the data channel, I have come to the conclusion that the application needs to handle its own sequence number and sequence number checking. It first sounds as overkill, but I think it is not. The reliable and semi-reliable channel types may break by reaching the retransmission limit of SCTP, and the logical action of the application is to reconnect and continue. If detection of loss is of importance, then a sequence number that spans over a break and reconnect Hmmm. Interesting. SCTP gives up when it thinks the peer can't be reached anymore. With tuning the parameters, it will try pretty hard. Why do you think retrying the connection makes things easier? Doesn't ICE do also connectivity checks? Why should ICE report that the peer is reachable, but SCTP can't? Best regards Michael > seems needed. > Or, is there any built-in support for that? > > Gunnar > > > Best regards Michael >>> Send from my Samsung Galaxy Note II >>> >>> El 02/01/2014 09:36, "Harald Alvestrand" <harald@alvestrand.no> escribió: >>> On 12/30/2013 12:09 AM, piranna@gmail.com wrote: >>> >>>>> for some use cases... >>>> Any concrete example? >>>> >>> Application-based fine-grain control of the transmissions. >>> >>> When asked for a concrete example, please give a concrete example of an application that needs it. >>> >>> It's always possible to send in unreliable mode and implement your own mechanisms for reliability; any extension to the spec needs to be backed with an use case that makes it clear why it's worth changing. >>> >>> >> > > >
Received on Thursday, 2 January 2014 20:54:10 UTC