DataChannel/SCTP Testing

[Sean-Der]

@lgrahl @enobufs @tuexen would be much better at this then me.

Do you guys have an opinion on what the most common bugs/things you could see going wrong would be? The goal is to have some stuff to establish basic conformance between implementations (Go, C and Python) right now are the three stacks I know of.

thanks!

[ivelin]

Great initiative. I'd be happy to share experience in browser/python interop during this project: https://webrtchacks.com/private-home-surveillance-with-the-webrtc-datachannel/

@Sean-Der As mentioned offline, it would be great to socialize a community project for a cross language p2p version of [http fetch/request <-> WebRTC DC <-> http2-proxy] for IoT access use cases.

I believe @steely-glint would be interested in that as well in relation to the pi.pe product.

[lgrahl]

Probably forgot a lot but these are some common issues I've encountered in the wild:

• The message integrity violation/EOR issue
  • Ensure that only complete messages are being handed out
  • Don't forget that this can also happen for DCEP messages with long label and protocol values.
  • Note: For those using usrsctp, handling multiple chunks is mandatory even if you use atomic mode
  • Hello Chrome team, you still haven't fixed this. (Oh, and you're still not supporting Blob... this bug is so old, it already has to go to primary school.)
• Aborting messages split into multiple packets due to packet loss (pc.createDataChannel('foo', { maxRetransmits: 0 }))
  • Ensure that the partial message is not being handed out
  • Ensure that the reassembly buffer has been cleared (if existing)
• Data channel reuse
  • Both sides have to reset their outgoing stream and wait until the other side has reset the incoming stream
• Reaching the maximum amount of channels
  • Note: This is a negotiated property
  • Handle it properly but don't crash the association
• Do not reorder messages
  • Sending/receiving in browsers allows to use text and two representations of binary. If you're not careful, this may lead to reordering.
• Shutdown of SCTP associations
  • Pretty much no one uses it but @jlaine does in aiortc and could reproducibly crash Firefox with it
• Out-of-band negotiated channels exist
  • Include them in your tests
• Performance test your data channels
  • Increase window sizes to sane values so connections with a larger RTT are still reasonably fast
  • For usrsctp, there is a whole thread on this issue. For example, there is usrsctp_sysctl_set_sctp_max_chunks_on_queue. Increase it!
  • In reliable/ordered as well as in unreliable/unordered and partial reliable modes.
• You can still be the first to ship message interleaving :heart:

[ivelin]

Looping in @jlaine the author of aiortc for his input on interop ideas.

[jlaine]

@lgrahl is pretty thorough in his test suite so I don't really have any additional ones right now.

However I'd like to mention the very neat work @marten-seemann has done for QUIC interop testing:

• specify a simple interface implementations must honour telling them what scenario we are running
• get each implementation to provide a docker image
• automatically run the implementations against each other to produce an interop matrix

https://github.com/marten-seemann/quic-interop-runner

[steely-glint]

Stepping back a bit from SCTP to the whole stack.

This raises the question - do we test each layer independently? Or do we test the layers in situ within the rtcweb stack?

Personally I'd assumed we'd do in-situ testing - certainly of SCTP since it is a long way up - but I'm open to persuasion.