[32827] in North American Network Operators' Group
RE: Packet Loss
daemon@ATHENA.MIT.EDU (Karyn Ulriksen)
Thu Dec 14 14:04:50 2000
Message-ID: <0127E258EE29D3118A0F00609765B44847CF77@dhcp-gateway.sitestream.net>
From: Karyn Ulriksen <kulriksen@publichost.com>
To: nanog@merit.edu
Date: Thu, 14 Dec 2000 10:18:31 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1252"
Errors-To: owner-nanog-outgoing@merit.edu
Isn't there something in RFC 1149 or RFC 2549 about this? Maybe another
update to these RFC will be required.
K
Reference:
http://www.valkaryn.net/rfc/1149.txt
http://www.valkaryn.net/rfc/2549.txt
> -----Original Message-----
> From: Tony Rall [mailto:trall@almaden.ibm.com]
> Sent: Thursday, December 14, 2000 9:50 AM
> To: nanog@merit.edu
> Subject: Re: Packet Loss
>
>
>
>
> > I'll speculate that it occurs when packets destined for a
> destination do
> > not get there. Most people see it via dropped ping packets..
>
> What ping really tells you is that either the packets from A
> to B are being
> lost or those from B to A are being lost. From the
> information that ping
> presents there is no way to know which direction (and the
> routing may well
> be asymmetric) is choking, nor if the problem is at one of
> the end points.
>
> While I really like to use pings (with at least 100 samples)
> for testing
> round trip packet loss, there are situations where it will
> give incorrect
> results. If the packet loss is data, packet size, or
> protocol dependent,
> ping probably won't tell you about the performance to be
> expected for the
> application that you're really interested in. On top of
> that, some systems
> will filter or throttle ICMP - this really distorts the results.
>
> Tony Rall
>
>
