STUN hack could help admins choose between 'net links

RFC identifies handy spot for RTT, packet loss metrics

Hammer, spanner and screw

A proposal at the Internet Engineering Task Force suggests network admins can use the venerable STUN protocol to help them pick the best path across IP networks.

STUN – Session Traversal Utilities for NAT – is well-known as a handy tool for setting up things like voice-over-IP (VoIP) sessions between users hidden behind firewalls.

RFC 7982, here, suggests the same protocol only needs minor tweaks to gather network path information like round-trip time (RTT) and packet loss.

As the RFC states, paths are often chosen with a static configuration, which might harm the user experience.

All that's needed, the RFC suggests, is to create a STUN attribute it calls “TRANSACTION_TRANSMIT_COUNTER” (TTC). So nothing breaks, a STUN implementation that doesn't yet support the attribute can ignore it.

To use the TTC, the RFC says a client would insert the attribute in a STUN request, along with the number of times the request will be retransmitted with the same transaction ID.

The server can then echo the requests back to the client, to determine RTT; and if the server indicates how many retransmissions it's echoed the STUN request, the client can get an idea about packet loss (and, in some cases, which direction the packet loss happened in).

The RFC notes that its authors don't consider it a “comprehensive mechanism” for measuring link state (particularly for packet loss, since that can happen in many points in the network), but easy rule-of-thumb hacks are very useful tools for sysadmins.

The RFC was authored with contributions from Cisco and, but let's please remember that RFCs are individual work and the fact that employees contribute does not imply vendor endorsement. ®

Biting the hand that feeds IT © 1998–2017