Peter 'Happy' Thomas (happypete) wrote,
Peter 'Happy' Thomas

An e-mail I just sent--and copied to our entire systems team and [another clueless idiot at a large networking provider] (the e-mail prompting my rant is at the bottom)

Dear [a member of our systems team]:

I'm tired of pulling punches with these idiots. Since [a large networking provider] has proven repeatedly over the last year that they are dumber than bricks and incapable of troubleshooting network problems for themselves, let me break it down for them.

As packet size increases, packet loss increases dramatically.

ICMP ECHO/ECHO REPLY TEST (a.k.a. "ping") from 10.0.10.xx to
Packet size (bytes) loss % avg. latency (ms)
1400 7
1500 13
1600 17
1700 92 79

I isolated the LAN's latency and loss from the LAN by pinging from 10.0.10.xx to (the [a large networking provider] router). At a packet size of 1700 there is 3% loss and 2ms average latency on the LAN. The other 89% and 77 ms is between the [a large networking provider] managed end-points and

What this means in practice is that "default" pings will look perfectly normal--but as packets get bigger, the performance drops off dramatically.

Now, there's a couple of things to be aware of--one, as we exceed ~ 1500 bytes we'll begin to have Ethernet frame fragmentation on the LAN. That is already factored into the LAN latency (and is obviously not a significant factor).

Now, what does [the above] mean in terms of instantaneous network utilization, since I know that has been brought up as a strawman issue by [a large networking provider]? Nodes construct echo replies by reversing the source and destination headers, setting the code to zero, and re-computing the checksum. Therefore two 1700 byte are approximately 3400 bytes on the network. If those 3400 bytes were to be transmitted over the course of 79 ms we would see 344.3 kilobits in a second of non-stop echo responses and replies. That's about 22% of a T-1. (I'm excluding fragmentation overhead, network management, and other traffic from that figure--but I'm also excluding processing delays &c. that would make that true instantaneous figure lower). For one thing, the default ping client sends out one ping per second--putting us more at _ 1.8% _ of a T-1's total bandwidth from the 1700 byte ping test over time.

Can we please now put to rest FOREVER the ridiculous idea [a large networking provider] seems to have that nothing is wrong with their implementation of our network and get them down to finding and fixing their problem(s)? Thanks much.

Fed up and going to bed,


p.s. [a large networking provider] also seems to have missed the "for a PPTP VPN" part of our static NAT request for the BFS-local PPTP VPN on [an IP address], because they are not passing GRE and therefore VPN connections fail after authentication.
Peter L. Thomas, Technical Director
High Performance Technologies, inc. (
Office: 973-442-6436 x246, Cell: 703-615-7806, Fax: 973-442-6402
E-mail: [my work e-mail address]

-----Original Message-----
From: [a member of our systems team]
Sent: Wednesday, November 17, 2004 3:24 PM
To: Thomas, Peter
Subject: FW: ([a trouble ticket number]) Latency Issue.

Can you provide these?

-----Original Message-----
From: ProductSupport-Dedicated@[a large networking provider].com [mailto:ProductSupport-Dedicated@[a large networking provider].com]
Sent: Wednesday, November 17, 2004 3:21 PM
To: [a member of our systems team]
Subject: ([a trobule ticket number]) Latency Issue.

[a member of our systems team],

I am not seeing any latency issues at this site at this time. Please provide more information so that I can troubleshoot this issue further; ping results with source and destination as well as traceroute results.

Thank you,

[another clueless idiot at a large networking provider]

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.