Configurable transport layer SACKs (for node-datachannel)

[reececomo]

Summary

When sending packets @ 60Hz from Chrome, our Geckos.io server is responding at the transport layer ~40Hz, at about 107 bytes each.

• Presumably these are SCTP SACKs (see libdatachannel/sctptransport.cpp#L135).
• As we're going for unordered, unreliable - is it possible to reduce that rate (or eliminate entirely)?
• Chrome also responds to server sends, but at roughly half the receive rate. i.e. 30 SACKs @ 60Hz, or 15 SACKs @ 30Hz. Also 107 bytes each.

Configuring delayedSackTime?

There's a comment in node-datachannel with settings to increase the SACK delay window via delayedSackTime=, see https://github.com/murat-dogan/node-datachannel/issues/34#issuecomment-819276519 - although I'm a little out of my depth here. Based on the comments in libdatachannel it looks like they've increased the default delay from 200ms to 20ms.

Example chrome://webrtc-internals/ output:

[reececomo]

Edit: See https://github.com/geckosio/geckos.io/issues/247#issuecomment-1916540179, probably don't do this.

Turns out its as easy as setting:

import * as NodeDataChannel from "node-datachannel";

// Force SCTP settings.
NodeDataChannel.setSctpSettings({
  delayedSackTime: 1_000,
});

In this example the server is sending at about ~29Hz:

Before:

The default SACK setting from libdatachannel adds a slight transport layer overhead of ~10 additional packets per second per client (39-43 recvs per second):

After:

Setting delayedSackTime arbitrarily high appears to drop that to a negligible amount. Here is the same connection running (28-31 recvs per second):

[reececomo]

Edit: After hastily rolling this out to staging server I can now see, in fact, under real world conditions this absolutely wrecks net performance.

See the netgraphs below, latency variance / jitter goes to through the roof.

This could be because we're running a separate reliable datachannel on the same connection (SCTP settings apply to all channels), and that channels buffering frames block the main thread, etc.

Not going to spend too much time on this, just going to revert for now and assume libnodechannel knew what they were doing when they set their defaults 😆

[jebarpg]

What tool were you using for the second network stream image? @reececomo

[reececomo]

No tool unfortunately - it's just a lil debugging overlay we added 🙈

Stats log from the netcode wrapper into gameserverConnection.stats, and then are just dumped with PIXI.Graphics and PIXI.BitmapText into an overlay.