What does a "transport" consider as "payload"?

[henbos]

The RTCTransportStats object's 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

[henbos]

Question/discussion for @vr000m @alvestrand

[fippo]

The RTCTransportStats object's bytesSent is said to be:

very odd. I'd expect this to be usable to calculate the actual bitrate (w/o ip overhead). This would include any STUN packets sent or received. I think that is what Chrome currently does, try this:

1. go to https://webrtc.github.io/samples/src/content/peerconnection/pc1/
2. make a call, have webrtc-internals open
3. paste pc1.getSenders().forEach(s => s.track.stop())
4. observe candidate pair stats increase.

So if it's UDP, this would refer to the number of UDP datagrams?

Yes.

Same as the number of IP packets?

That is rather hard to compare to UDP and may not even be available? If an RTP packet is sent over RTP-over-tcp I'd expect this to increase by 1, no matter how many different ip packets it gets split into.

[fippo]

related, I assume RTP packets are encrypted here when bytes are counted (i.e. for non-gcm that is 10 bytes more usually) but they are not for RTCSentRtpStreamStats (et al).

[jan-ivar]

As written, it looks to me like the intent may have been a mere aggregate of all rtp stream stats (payload without headers) over that transport. I don't have a strong opinion about whether that's what we want, but that's how I read it FWIW.

[jan-ivar]

At minimum, I think we should include data channel payload. Unsure about the rest.

[fippo]

but that means the "transport" has to know about rtp payload or datachannel payload. Which violates layers

[alvestrand]

ICE candidate pair stats should have all those bytes (including headers and STUN packets); that layer shouldn't differentiate. ICE Transport stats should include what's payload for the ICE transport - which includes RTP headers + payload and SCTP headers + payload, but not ICE/TCP/UDP overhead, since that's generated by the ICETransport. We added a separate "header bytes" counter - the sum of header bytes + payload bytes should equal the ICE candidate pair byte count summed across all ICE candidate pairs.

[jan-ivar]

ICE Transport stats should include what's payload for the ICE transport - which includes RTP headers

We might want to clarify "not including headers or padding" then.

[fippo]

Now that makes sense. I assumed that the transport stats were describing what goes over the wire but they aren't actually. What goes over the wire is counted by the candidate-pair stats.

https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatepairstats-bytessent (and others) should not copy-paste from https://w3c.github.io/webrtc-stats/#dom-rtctransportstats-bytessent then.

Does the transport count DTLS bytes?

[vr000m]

There are no DTLS payload for RTP packet and ICE are also now excluded. hence No.

[alvestrand]

a simple model is that candidate pair stats are slices of the transport stats. so before ICE restart, sum(candidate pair stats) = transport stats.

[alvestrand]

the other model is that candidate pair stats include higher level headers, so that sum(candidate pair stats) > transport stats.