Re: RTCStatsType value for datachannel stata

On 01/06/2015 01:32 PM, Michael Tuexen wrote:
> On 06 Jan 2015, at 07:13, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> Den 06. jan. 2015 00:14, skrev Singh Varun:
>>> Hi Harald,
>>>
>>> Response inline.
>>>
>>>> On 05 Jan 2015, at 23:40, Harald Alvestrand <harald@alvestrand.no> wrote:
>>>>
>>>> The current RTCStatsType is defined like this:
>>>>
>>>> enum RTCStatsType {
>>>>    "inboundrtp",
>>>>    "outboundrtp",
>>>>    "session",
>>>>    "track",
>>>>    "transport",
>>>>    "candidatepair",
>>>>    "localcandidate",
>>>>    "remotecandidate"
>>>> };
>>>>
>>>> There are no values for the datachannel stats.
>>>>
>>>> To make this symmetric with RTP, I suggest we add "inbounddata" and "outbounddata".
>>>>
>>> I presume that the stats currently in RTCDataChannelStats will then be split to inbound and outbound?
>>
>> On second consideration, that doesn't make sense. The reason RTP is
>> split is that RTP is unidirectional, while datachannel is bidirectional.
>>
>> Second proposal:
>> The string should be "datachannel". No split.
> Are there counters needed for abandoned messages? Should these counters
> be different for messages which have never been sent or for which at least
> one part was sent once?

I am approaching this from the standpoint of "let's do what's obvious
first, and then see what we need".

We might choose to instrument the SCTP layer separately (counting
packets not messages, and account for retransmits), or we might choose
to extend this structure.

I'm thinking "what would an application do differently" - an application
using a partially reliable channel may want to keep an eye on the loss
rate, so that it knows when the loss rate increases to where sending is
not useful any more. (Which ends of a connection, if any, knows that
messages have been lost?)

But I can't quite imagine why the application should care about whether
or not messages have been partially sent - the receiver doesn't have
them, and that's usually all the application cares about.

Received on Tuesday, 6 January 2015 14:01:17 UTC