[105524] in North American Network Operators' Group
Re: Possible explanations for a large hop in latency
daemon@ATHENA.MIT.EDU (Robert Richardson)
Thu Jun 26 21:20:00 2008
Date: Thu, 26 Jun 2008 18:19:48 -0700
From: "Robert Richardson" <bobrmr@gmail.com>
To: "John T. Yocum" <john@fluidhosting.com>
In-Reply-To: <48643DC5.1040208@fluidhosting.com>
Cc: nanog list <nanog@merit.edu>
Errors-To: nanog-bounces@nanog.org
They probably don't propagate TTL w/in their MPLS core. Depending on how
they have MPLS implemented, you may only see 2 hops on the network; the
ingress and egress routers. If the ingress router was in NYC and the egress
in Seattle, you could understandably expect a large jump in RTT.
Not an ATT customer but do know other providers run their MPLS core's this
way...
-Robert
On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum <john@fluidhosting.com>
wrote:
> The explanation I got, was that the latency seen at the first hop was
> actually a reply from the last hop in the path across their MPLS network.
> Hence, all the following hops had very similar latency.
>
> Personally, I thought it was rather strange for them to do that. And, I've
> never seen that occur on any other network.
>
> Perhaps someone from ATT would like to chime in.
>
> --John
>
>
> Frank Bulk - iNAME wrote:
>
>> Did that satisfy you? I guess with MPLS they could tag the traffic and
>> send
>> it around the country twice and I wouldn't see it at L3.
>>
>> Frank
>>
>> -----Original Message-----
>> From: John T. Yocum [mailto:john@fluidhosting.com] Sent: Thursday, June
>> 26, 2008 7:04 PM
>> To: frnkblk@iname.com
>> Cc: nanog list
>> Subject: Re: Possible explanations for a large hop in latency
>>
>> When I asked ATT about the sudden latency jump I see in traceroutes,
>> they told me it was due to how their MPLS network is setup.
>>
>> --John
>>
>> Frank Bulk wrote:
>>
>>> Our upstream provider has a connection to AT&T (12.88.71.13) where I
>>> relatively consistently measure with a RTT of 15 msec, but the next hop
>>> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending
>>>
>> that
>>
>>> traffic over a cable modem or to Europe and back, I can't see a reason
>>> why
>>> there is a consistent ~70 msec jump in RTT. Hops farther along the route
>>> are just a few msec more each hop, so it doesn't appear that
>>> 12.122.112.22
>>> has some kind of ICMP rate-limiting.
>>>
>>> Is this a real performance issue, or is there some logical explanation?
>>>
>>> Frank
>>>
>>>
>>>
>>
>>
>
>
