Re: RTCStatsType value for datachannel stata

On 06 Jan 2015, at 15:00, Harald Alvestrand <harald@alvestrand.no> wrote:

> 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.
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06#section-4.3
gives you two numbers:
* the number of user messages which are abandoned and for which no
  part has even been on the wire. So you can be sure that it wasn't received.
* the number of user messages which are abandoned and for which at
  least one part has been on the wire.
If you focus on the case of non-fragmented user messages the first counter
gives you the messages which stayed longer in the queue than their lifetime
allows. For messages covered by the second counter you don't know if
they were received or not.

Please note that the first counter only makes sense for the time based
policy, but it gives you a picture about the queuing time in you send queue.

Best regards
Michael
> 
> 
> 
>

Received on Tuesday, 6 January 2015 17:33:06 UTC