1210160 - webRTC Data Channel Protocol Listener API for devtools webRTC inspector

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[Axel Kratel]

Devtools needs an API to enable listening to webRTC data channel network traffic. The listener should be below the application API layer. We want to provide developers access to the network layer. 

The analog in WebSocket for this bug is 1203802 https://bugzilla.mozilla.org/show_bug.cgi?id=1203802, which provides a frame listener API. This API provides frame specific data that is not available via the application API. The webRTC data channel API should be similar.

Comment 1

[Axel Kratel]

Randell, can you take a look at this API requirement? See the API that Andreas implemented, it allows us to inspect the actual webSocket frames. I took a look at SCTP and it's a bit challenging to determine the frame equivalents in SCTP. SCTP seems like a transport protocol that is much lower level than webSocket. 

Could you tell us what the WS frame equivalent is? 

Thanks.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

So: there is no framing, to avoid unneeded overhead.  All packets are all data; the type of packet is determined by the SCTP PPID field (not in the payload), and the sequence number (also not in the data).  That's at the raw protocol level.  At the send() and onmessage level there's no framing, period.

You want to look at the two DataChannel drafts for the rtcweb Working Group in the IETF, especially the bae DataChannel draft (as opposed to the DataChannel setup draft).

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Randell, if I understand correctly one message sent through RTCDataChannel: i.e. channel.send(data); - can span multiple packets, correct?

I think there are two options:

1) having a listener that allows intercepting every transferred packet and getting all meta data and the payload for it. Axel, I guess this is what you would prefer?

2) having a listener that allows intercepting every transferred message plus meta data and the payload.


In any case, I believe that the tooling should ultimately be able to visualize all meta data for a message (message type, channel type, priority, label, protocol, etc.). Also, the tool should be able to intercept *all* messages including the handshake (DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK). It would be also great to have a reference to the initial upgrade HTTP request.

Finally, the tool needs to also visualize failures.
What kind of errors can potentially happen?

Honza

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Jan Honza Odvarko [:Honza] from comment #3)
> Randell, if I understand correctly one message sent through RTCDataChannel:
> i.e. channel.send(data); - can span multiple packets, correct?
> 
> I think there are two options:
> 
> 1) having a listener that allows intercepting every transferred packet and
> getting all meta data and the payload for it. Axel, I guess this is what you
> would prefer?

You can dump every SCTP packet (after decryption) with NSPR_LOG_MODULES=sctp:4 and decode them into a wireshark trace with "alias log2pcap 'grep "SCTP_PACKET" !:1 | text2pcap -D -n -l 248 -t "%H:%M:%S." - !:2'" (in tcsh!! not bash)

> 2) having a listener that allows intercepting every transferred message plus
> meta data and the payload.

For application developers (as opposed to protocol-stack developers, this is where the value is, and where I suggest we put our effort.

Protocol developers (of which there should be almost none - mostly us, Chrome, and the SCTP maintainers) would use the above NSPR logging.  If there's a real advantage to having SCTP-packet-level diagnostics in-browser (I'm not even sure *I* have a use for those...), we could modify the debug_printf() hook in DataChannel.cpp to report the packets to a listener as well as dump to a debug file.  Note then you'll need wireshark-level parsing of SCTP, and update it as needed.  We could add probes for the DataChannel setup packets (OPEN, ACK) of course.

> In any case, I believe that the tooling should ultimately be able to
> visualize all meta data for a message (message type, channel type, priority,
> label, protocol, etc.). Also, the tool should be able to intercept *all*
> messages including the handshake (DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK).
> It would be also great to have a reference to the initial upgrade HTTP
> request.

There is no "upgrade HTTP request"for DataChannels, unlike WebSockets, this runs over a DTLS connection created by the WebRTC/mtransport ICE stack.

> Finally, the tool needs to also visualize failures.
> What kind of errors can potentially happen?

Mostly just connection failures.  Lossy connections may have messages missing, and if you allow it, messages may be delivered out-of-order (and note that the messages presented to the application have no framing with a sequence number; applications (if they care; not all do) using out-of-order connections must do so themselves.  A Lossy (no retries) out-of-order connection is ~= UDP, and appears very much like it.  As with UDP, the tool will not be able to tell you if there's a message missing or out-of-order in this case.

Comment 5

[Axel Kratel]

Randell, can you answer some of these questions:

The maximum size SCTP packet (MTU) is 1416 bytes. That is orders of magnitude smaller than the frames on WS. RFC 6455 which specifies an 18,446,744,073,709,551,615 bytes (maximum value of a 64-bit unsigned value) limit. So when you send a message via the application API on a webRTC channel, the message will be broken up into many packets. If there is no frame concept in SCTP, then how does the other end know when the message is received, especially if the connection is left in lossy UDP like mode?

Currently there is a 2GB limit on WS messages, not frames in Firefox. What is the limit on WebRTC? Is it the same as the MTU for SCTP?

If we only instrument at the application level. if a larger message is transmitted, how can the developer be informed that the network is still active and transmitting even if the app API hasn't fired a receive message yet?

How does the unreliable mode affect large message transmissions?

What signaling below the messaging API should be instrumented that might be relevant to an application developer? 

Is it possible to get a deeper error reporting that includes lower level protocol information if inspecting the network via webRTC inspector?

Thanks for clarification.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Axel Kratel from comment #5)
> Randell, can you answer some of these questions:
> 
> The maximum size SCTP packet (MTU) is 1416 bytes. That is orders of
> magnitude smaller than the frames on WS. RFC 6455 which specifies an
> 18,446,744,073,709,551,615 bytes (maximum value of a 64-bit unsigned value)
> limit. So when you send a message via the application API on a webRTC
> channel, the message will be broken up into many packets. If there is no
> frame concept in SCTP, then how does the other end know when the message is
> received, especially if the connection is left in lossy UDP like mode?

*DataChannels* has no framing (it's all bare datagrams).  SCTP has structure, but just like we're not adding code for debugging TCP, I think it would be a mistake (and a waste of time/resources) to put in code to debug SCTP itself -- and simply confusing for 99.9% of devs who work with DataChannels.

> Currently there is a 2GB limit on WS messages, not frames in Firefox. What
> is the limit on WebRTC? Is it the same as the MTU for SCTP?

Originally there was to be no limit (like WebSockets).  After much discussion, it was decided to declare the maximum message size a side is willing to receive with a=max-message-size:NNNNN.  The default is 64K.  We do not yet support max-message-size, and do support arbitrarily-large messages (equivalent to max-message-size:0). I've transferred 500MB blobs with a single send() call in testing - but that uses (deprecated) chunking via PPID values.  When we remove that (soon, probably in 44), we'll be limited to no more than the SCTP buffersize per message, and likely more like 1/2 of that (or around 128K or less).

> If we only instrument at the application level. if a larger message is
> transmitted, how can the developer be informed that the network is still
> active and transmitting even if the app API hasn't fired a receive message
> yet?

Given the max-message-size issue (and that Chrome limits max-message-size to ~128K IIRC, but doesn't put the parameter in SDP either yet), applications generally aren't going to be able to assume transfer of more than 64K safely (and right now >16K per message will cause problems in Firefox->Chrome).

There's no easy way to find out from the stack if it's getting ready to deliver data for a stream, though maybe there's some debug interface to do so.  Given the relatively low max-message-size limits, I don't see much need for this.

> How does the unreliable mode affect large message transmissions?

It makes them a very bad idea.  If any of the packets making up a large unreliable transfer are lost, the entire message is lost.  Applications aren't stopped from trying to do this, but unreliable transfers of >16K are ill-advised, and I'd try to stay to no more than a couple of packets/message if possible.
 
> What signaling below the messaging API should be instrumented that might be
> relevant to an application developer? 

The only thing below the application layer I can think of would be OPEN/ACK, listing open channels, and connection health.

> Is it possible to get a deeper error reporting that includes lower level
> protocol information if inspecting the network via webRTC inspector?

With a lot of work you could duplicate Wireshark-for-SCTP, and be able to see individual missing packets, SACKs, etc.  I see minimal to no benefit to this.  I've barely had any need to ever dump SCTP to wireshark, and in those rare instances the post-mortem dump is fine - and devs aren't debugging SCTP or even the DataChannels implementation.

> Thanks for clarification.

np.

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.