The problem with UDP is that there is no explicit feedback-loop
or congestion control frobs -- this is generally kicked up the
protocol stack for the application itself to figure out.
UDP is designed that way: push traffic into the network as fast
as the network can take it, and expect the application to provide
for delay/loss/adaptation of jitter, buffering, etc.
So to answer your question, I think it really depends on how
the application itself handles UDP traffic, adapts to any sort
of RTT measurements, delay/jitter, etc.
-----Urspr�ngliche Nachricht-----
Von: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] Im
Auftrag von Fergie
Gesendet: Dienstag, 7. M�rz 2006 18:16
An: gstammw@gmx.net
Cc: nanog@nanog.org
Betreff: UDP Badness [Was: Re: How to measure network
quality&performance for voip&gameservers (udp packetloss,
delay, jitter,...)]
[...]
So to answer your question, I think it really depends on how
the application itself handles UDP traffic, adapts to any
sort of RTT measurements, delay/jitter, etc.
- ferg
Hello Fergie,
You are right - but there must be some sort of tool that can generate udp
packets at a specified rate (or bandwidth) and measure if they are arriving
in order, if there is loss and what the jitter is or something like that.
Does anyone know some kind of tool?
I regularly use iperf to stress test various network components. In TCP mode it will show you how fast a tcp stack can negotiate to, in UDP mode it can throw packets at a fixed rate and the server can tell you how many it got.
There is also NDT, http://e2epi.internet2.edu/ndt/, but that requires a kernel with the web100 patches to instrument the kernel network stack.
-David Nolan
Network Software Designer
Computing Services
Carnegie Mellon University
Unfortunately not. Iperf has suited me fine where I don’t require professional (pricey) testers.
The fact that it is console based I usually see as a plus.
Unfortunately not. Iperf has suited me fine where I don't require
professional (pricey) testers.
The fact that it is console based I usually see as a plus.
Last I checked I got the time from Iperf, even if it was indirectly.
A tool that shows which hop in the network that has problems forwarding
certain traffic ? Awesome, I want one of those.
The CAIDA tools taxonomy is a good place to start
shopping for a tool like this: http://www.caida.org/tools/taxonomy/performance.xml
Then do some googling on the names which interest
you to see what people are saying about them.
Packetloss, delay and jitter are IP characteristics,
not UDP. In any network that allows IP packets to
be lost or to be buffered, there will be delay and
jitter.
On behalf of every network operator on the planet, I would like to take
this opportunity to encourage every person who implements a traceroute or
traceroute like program to ALWAYS DISPLAY THE SOURCE ADDRESS IN THE OUTPUT
OF THE PROGRAM!@#$%^&
Very few things in life suck more than asymmetric paths + wannabe network
engineers armed with a noc phone number list and traceroute, mtr, or those
wonderful visual traceroute programs that they insist on taking 6MB bmp
screenshots of and sticking into word documents so they can email that as
an attachment.
You will not learn hatred until that MMO you host implements a 'Report network problem' button that does a traceroute, and automatically emails it and a canned message to your NOC mailbox. Ultima Online did this, back in my nocling days. Like monkeys expecting a reward, those little bastards pounded on that button until the lag stopped.
It gave the west coast sucking sound that was Mae-West an entirely different flavor. We could monitoring peering conditions based solely on mailbox volume.
--matt@snark.net------------------------------------------<darwin><
The only thing necessary for the triumph
of evil is for good men to do nothing. - Edmund Burke
Not to try and troubleshoot your 5 year old ticket or anything, but their
ingress traceroute shows what looks like Baltimore to San Francisco to
mae-west to a sjc based server (probably someone honoring meds :P), and
the outbound traceroute used to troubleshoot it coming out of VA and going
over mae-east. Nothing in that traceroute proves that AboveNet was or was
not having issues at mae west.
While the output from traceroute is simple, obtaining meaningful data from
it about what is actually wrong requires an operator with expertise and
years of experience. Jumping to conclusions about what is or isn't wrong
based on traceroute is probably one of the largest failings of noc people
in general.
But thanks for reminding us of the crappy crappy networking that went on 5
years ago.
(sorry, couldn't resist)