- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Oct 2019 14:11:57 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-stats: == What does a "transport" consider as "payload"? == The RTCTransportStats object's [bytesSent](https://w3c.github.io/webrtc-stats/#dom-rtctransportstats-bytessent) is said to be: > Represents the total number of bytes received on this PeerConnection, i.e., not including headers or padding. There's also packetsSent: > Represents the total number of packets sent over this transport. I would think that a transport's packet would refer to whatever the transport-layer's conception of a packet is. So if it's UDP, this would refer to the number of UDP datagrams? Same as the number of IP packets? A transport is used to send multiple things: RTP, SCTP, etc. Surely, from the transport's point of view, all of this is payload? - Does RTP header/padding bytes count towards "transport.bytesSent" since this is arguably transport-payload, or do we strip upper-layer protocol's notions of headers from the transport's bytesSent? - Related: Would it be possible to send multiple RTP packets over a single transport-layer packet? Or would summing up all the ssrc's packetsSent counters always sum up to be equal to the transport's packetsSent counter (in an RTP-only use case)? I don't know what the spec is trying to say here, and I also don't know what current implementations are doing. This needs to be clarified. Related discussions: An argument was made that it would be useful to have total counters include as much as the overhead as possible as well, so that it would be possible e.g. to compare TCP/UDP/DTLS/RTP stacks to "RTP-over-QUIC" or other NV transports Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/507 using your GitHub account
Received on Wednesday, 2 October 2019 14:11:59 UTC