Information Technology News.


STUN tool can help network admins choose between various connection paths

Share on Twitter.

Sponsered ad: Get a Linux Enterprise server with 92 Gigs of RAM, 16 CPUs and 8 TB of storage at our liquidation sale. Only one left in stock.

Sponsered ad: Order the best SMTP service for your business. Guaranteed or your money back.

September 27, 2016

A new concept proposed at the IETF (Internet Engineering Task Force) would suggest that network administrators could utilize the old but still popular STUN (Session Traversal Utilities for NAT) protocol to help them choose the best connection paths across various IP networks, both private and public.

The concept isn't new but it can still be easily implemented. STUN is well-known as a practical tool that gets the job done for setting up networking services such as voice-over-IP (VoIP) sessions between users hidden behind firewalls, among many other examples.

To be sure, RFC 7982 suggests the same protocol only needs minor adjustments to gather network path information like round-trip time (RTT), packet loss and other useful network data in the day-to-day chores of any network admin professional.

As the RFC states, connection paths are often chosen with a static configuration, although some use DHCP. All that's needed is to create a STUN attribute it calls “TRANSACTION_TRANSMIT_COUNTER” (TTC).

So there's nothing that breaks. For example, a STUN implementation that doesn't yet support the attribute can also ignore it.

To use the TTC, the RFC suggests 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 its RTT. If the server indicates how many retransmissions it's echoed in the STUN request, the client can get an idea about packet loss and, in some cases, which direction the packet loss happened in.

It's a clever way of designing an added layer of 'intelligence' in the overall working of either a private or public network.

Furthermore, the RFC states 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 rather easy rule-of-thumb adjustments that can be useful features for busy network admins.

The RFC was authored with a few contributions from Cisco and callstats.io, but it's important to keep in mind that RFCs are mostly individual endeavors and the fact that employees contribute them doesn't necessarily imply vendor endorsement from Cisco or any other reputable networking equipment maker.

Source: The Internet Engineering Task Force.


Sponsered ad: Get a Linux Enterprise server with 92 Gigs of RAM, 16 CPUs and 8 TB of storage at our liquidation sale. Only one left in stock.

Sponsered ad: Order the best SMTP service for your business. Guaranteed or your money back.

Share on Twitter.

IT News Archives | Site Search | Advertise on IT Direction | Contact | Home

All logos, trade marks or service marks on this site are the property of their respective owners.

Sponsored by Sure Mail™, Avantex and
by Montreal Server Colocation.

       © IT Direction. All rights reserved.