dslreports logo
    All Forums Hot Topics Gallery


how-to block ads

Search Topic:
share rss forum feed


Piscataway, NJ

[OOL] Reporting peering partners path slowdown

Hi all,
I tried through Optimum Customer Service reporting slowdown on upload through Lightpath.net peering to Cogentco.com and Level3 handoff. The person did not investigate beyond my connection even through I sent evidence of drops on those nodes. I know there is some kind of "CoS/thottling" or drops through the path since I tested to two nodes going though similar path ISP nodes (see »www.speedtest.net Aurora, IL as one destination). If I test to other ISPs on speedtest.net in the Chicago area, I may or may not see similar issue depending on path out of lightpath.net so I know it is path issue since the ISP nodes that are the similar are Lighpath and Cogentco to two InterNAP destinations. Since I deal with ISPs all around the world, I have little more experience than average home user to know of either CoS/thottling or drop packets without have all for the tools at my disposal but home users support normally seems to be only investigate up to residental node in most cases.

What mechanism is available to get to ISP higher tier support based on my observation since this always is one of the problems with reporting peering ISP issue with any vendor and seems worst for residential users who may be reported possible actual peering issue.

NOTE: I also have ISP Cogent as one of my other business ISP support mechanism and InterNAP but Cablevision does not seem to have similar mechanism in place for residental users. It would be different if I was not willing to help and make the time to make sure similar COS/throttling is being observed


Ronkonkoma, NY
You can try direct forum here if you aren't getting what you need over the phone. Can you post the traceroutes & pings here to show this slowdown? That is required for any escalation of this nature. Also is it all day, or just intermittent?


Piscataway, NJ
The upload to the destination always shows less than 500KB/sec while the download to the same location shows over 1.7MB/sec anytime and occasional slower during workday. I compare the same transfer via cellular ISPs (AT&T and FreedomPOP (aka Clearwire/Sprint)) and those ISPs transfer show over 500KB/sec for download/upload to the same destination. A speedtest to Aurora, IL node shows less ~25mbps download/~6mbps upload which seems to reflect my sftp/ftp transfer to my destination going through similar ISPs path but few different nodes on InterNAP side. Similar speedtest test to area Chicago, IL nodes show ultra 50 on download but the uploads are showing similar =8mbps.

NOTE: I make sure the NYC/NJ speedtest optimum and other area ISP destination nodes shows ~50mbps download/~20mbps upload throughput on residential Cablevision modem or behind my routers before testing toward Chicago area nodes.

Here is a traceroute to »www.speedtest.net Aurora, IL site:

Tracing route to over a maximum of 30 hops

1 6 ms 3 ms 5 ms cp.local.tld []
2 5 ms 5 ms 6 ms MYSHARE []
3 20 ms 21 ms 14 ms
4 211 ms 14 ms 13 ms
5 16 ms 14 ms 14 ms ool-4353f909.dyn.optonline.net []
6 14 ms 70 ms 14 ms
7 21 ms 17 ms 17 ms
8 * 18 ms * te3-4.ccr01.ewr02.atlas.cogentco.com []
9 18 ms 23 ms 17 ms be2327.mpd22.jfk02.atlas.cogentco.com []
10 37 ms 37 ms 37 ms be2117.ccr42.ord01.atlas.cogentco.com []
11 36 ms 35 ms 36 ms be2003.ccr21.ord03.atlas.cogentco.com []
12 37 ms 55 ms 37 ms
13 39 ms 38 ms 38 ms border6.po2-bbnet2.chg.pnap.net []
14 43 ms 42 ms 48 ms blast-12.border6.chg.pnap.net []
15 49 ms 42 ms 41 ms gi03.core1.blastcomm.com []
16 42 ms 42 ms 41 ms core1.rooftop1.blastcomm.com []
17 41 ms 43 ms 54 ms

Trace complete.


Matamoras, PA
I find it slightly amusing that the traceroute looks a bit like a UPS Air shipment. No wonder you're experiencing a slowdown they're flying your packets on jets! EWR (Newark) to JFK (NY) to ORD (Chicago)


Ronkonkoma, NY
·Optimum Online
reply to flash123
~40 ms latency to IL, especially crossing 2 peers to get there, is fine. That trace doesn't show an issue. Hop 8 is very likely only ICMP drops since the packet loss doesn't carry to future hops: it's not possible for hop 8 to have packet loss and hops 9-17 to be unaffected. I can't speak for anything with issues to other servers than this destination in the above trace with the statement, but that doesn't show an issue.


Suffern, NY
reply to andrewc2
said by andrewc2:

I find it slightly amusing that the traceroute looks a bit like a UPS Air shipment. No wonder you're experiencing a slowdown they're flying your packets on jets! EWR (Newark) to JFK (NY) to ORD (Chicago)

I get a laugh out of your description since it once happened to me. I ordered something from a South NJ mail order company to be shipped by FedEx to me in Suffern NY (on the NY/NJ border off Route 17). The tracking audi trail had the package go by truck to Newark Airport, get placed on a plane to Atlanta, placed on another plane in Atlanta to go back to Newark, and finally placed on another truck heading north for delivery by my local FedEx location. The misrouting of EWR->ATL->EWR delayed delivery by one day. Why the package could not have been transfered from the incoming South NJ truck to the Northbound truck at EWR instead of being placed on a plane to ATL only to then be returned to EWR, I do not know.

This reminds me of the shipping time schedule on the UPS site where a package being shipped by truck that is dropped off on Monday will be delivered on Friday but one being dropped off on Thursday will be delivered the next Wednesday. Apparently the site implies that they pull their trucks to the side of the road at 11:59 PM on Friday and only start them up at 12:01AM Monday since there is no other reason why a shipment that is on the road over a weekend adds two extra days to the delivery time. I can see a delay if it is sitting at a depot over the weekend awaiting a Monday delivery but the schedule shows that the truck is on the road not sitting at a depot awaiting delivery.


Piscataway, NJ
reply to frdrizzt
NOTE: As I found out with in path devices like LEC attenuater on the fiber that should not have been in place, not seeing drops when traceroute runs does not always mean packets are not occasionally being drop or delayed. If the upload is slower in both speedtest sites and my sftp destination on path going toward these various Chicago nodes on holiday weekend, there is something along the way "toward" the destination that is not seen on coming "from" the destination. Also traceroute does not always reflect upstream packet lost from previous node depending on if the device may or may not dropping on per "session/connection" packet. Each traceroute packet is "new session/connection" even if the routing tables on the OS are stable based BGP or whatever routing algorithm. I seen this happen on Windows, Checkpoint firewalls and load balances. One to several persons cannot communication but others are.

I have been burnt before with LEC attenuator in path that should not have been in place. We saw little or no packets drops or duplicate ACKs (NOTE: the necessary ACKs were seen in most if not all of these cases) but one could see the delay in one direction but traceroute was not showing evidence of delay or packets drops but we were seeing the transfer slowness in one direction. This is after we had the metroethernet vendor support "LEC" come out to test with their fiber communications tools and it tested successfully. Only when they came out a 2nd time, the technician notice their attenuator was in place that should not have been there. The vendor, who was customer of record, did iperf testing before and after LEC tested successfully and could see what we were seeing and could not find the issue. Hence the 2nd requester to the metroethernet vendor support team and the LEC technician finding the issue. Too many years in this business to ask someone not to rule out layer-1 and layer-2 communications is working within specifications even if the upper level protocols are not showing dropped packets before saying it is the end devices. The problem is most ISPs are not going to put fiber testing tools (layer-1) in path before connecting switches/routers to know they have problem. They assume the end devices or their tools will have mechanism to know In our case, there were no errors seen on the switches or customer of record tools in both cities.

This issue is looking very similar to my above mention metroethernet experience that have similar latency as mention in this post from East Coast to Central USA. At least in that case we were only dealing with one metroethernet vendor support and their technicians in each city on this matter. On the Internet, this takes on whole another level of prove this is not being seen by others or we have no evidence that this is only your problem.

My evidence shows a lot of "TCP window full" on wireshark that is not seen on ISP cellular path test. So something is delaying the packets that one does not see it when using alternate ISPs (cellular vendors). The end devices are the same, only the source ISP path are different and not the destination.