What should I expect?
I am seeing ~350 from a vendor provided mpls cloud to a site in
Sukhrali Chowk, Gurgaon, Haryana, India
Thanks,
Joe
Where are you running your tests from? USA (east or west coast)? Europe? Elsewhere in Asia?
jms
Heya,
What should I expect?
I am seeing ~350 from a vendor provided mpls cloud to a site in
Sukhrali Chowk, Gurgaon, Haryana, India
We just did a video conference between Boston and New Delhi, via NYC, and
we were seeing around 250ms. However, VSNL was QoS'ing our traffic across
their backbone, so I'd expect normal traffic to take a bit longer. When
we originally investigated this, we were expecting to see around 300ms to
350ms.
Eric 
Disregard my previous post. I completely overlooked the subject that said "NY to New Delhi" *smacks forehead*.
Rule 1: Don't post before caffeine kicks in.
Rule 2: You do NOT talk about Fight Club.
So... my 'idiot moment' for the day behind me, 350ms may be a little bit high, but not totally unreasonable/unexpected.
jms
His subject says New York.
Justin M. Streiner wrote:
What should I expect?
I am seeing ~350 from a vendor provided mpls cloud to a site in
Sukhrali Chowk, Gurgaon, Haryana, IndiaWhere are you running your tests from? USA (east or west coast)? Europe? Elsewhere in Asia?
jms
As per subject header, test are performed from NY (well actually from NJ over a cross connect to NY, which adds about 4ms)
Thanks,
Joe
If you can provide an IP close to your destination, those of us in NY can run some quick tests for you.
Rob
Joe Maimon wrote:
hrm, qos doesn't necessarily mean longer RTT, it means preference in
(tight/busy/hot) paths, right? So... if VNSL's network along your path is
oc-48 with only 1mbps of traffic on it and you are taking only 1mbps more
... probably there isn't any change, yes? If it's a 1mbps path and you are
taking 1mbps then... other folks get starved out and potentially get
longer RTT.
(just trying to clarify the QOS boogie-man)
Seems not-unreasonable. I remember getting about 150ms or 250ms from
London to Gurgaon depending on whether we were on the straight-across
cable or the round-the-bottom cable. (Sorry, both my geography and my
cable-names are hazy).
Going east from NY, you'd add 70 or 80ms to that - and a quick look
suggests routes going west instead. (Test from home to .IN NS goes London
-> NY -> West Coast -> Singtel -> India, for ~370ms)
It's starting to head a bit towards walkie-talkie mode for VoIP, but not
too bad other than that...
Regards,
Tim.
What should I expect?
I am seeing ~350 from a vendor provided mpls cloud to a site in
Sukhrali Chowk, Gurgaon, Haryana, India
Seems not-unreasonable. I remember getting about 150ms or 250ms from
London to Gurgaon depending on whether we were on the straight-across
cable or the round-the-bottom cable. (Sorry, both my geography and my
cable-names are hazy).
The best recent data I have is from Bangalore to Tyco Road in Virginia through VSNL and Cogent.
Here is a sample (this goes through San Jose) :
Mon Mar 5 05:26:21 EST 2007
from Bangalore through the VSNL network
--- 63.105.122.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 285.495/319.649/395.330/38.576 ms
370 ms seems a little high but not unreasonable.
Regards
Marshall Eubanks
Thus spake "Tim Franklin" <tim@pelican.org>
Going east from NY, you'd add 70 or 80ms to that - and a quick
look suggests routes going west instead. (Test from home to .IN
NS goes London -> NY -> West Coast -> Singtel -> India, for
~370ms)It's starting to head a bit towards walkie-talkie mode for VoIP,
but not too bad other than that...
You'd be surprised what people are willing to accept when the alternatives are worse. I had a customer install VSAT in India just so they could use IP phones -- and their only gateway was in the US. Apparently the audio quality and reliability of the PTT was so bad that they were willing to _stand in line_ to use the two IP phones there to make calls, even with the walkie-talkie effect in full force. It was cheaper too, despite the outrageous cost of VSAT bandwidth.
US telcos and engineers tend to overestimate the importance of audio quality and reliability on VoIP; we have an entire generation of people now who have been trained by wireless carriers to _expect_ to pay through the nose for bad quality. VoIP across the Internet, even with no QoS at all, looks great in comparison because it's cheaper and sounds better.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
Depends entirely on your provider's path.... as some (less than useful) data points, from Cambridge MA to Bangalore I reliably get ~400ms on the public path and 240ms over a vendor-provided MPLS cloud.
Seems pretty damned reasonable to me considering the shortest distance between these two locations is a little less than 14,000 kilometers. Given the speed of light through glass, a convoluted fiber path, quite a few O/E - E/O conversions (EDFAs will only get you so far), and several switches, a 350ms RTT is decent.
Removing the gear and assuming an impossibly direct fiber path, would still give an RTT of about 140ms.
Gian Anthony Constantine
What does traceroute show? I was doing some looking glass tests
recently to some places in Asia and it looked -- from host names and
differential RTTs -- like there might have been a satellite hop
involved.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Steven M. Bellovin wrote:
What should I expect?
I am seeing ~350 from a vendor provided mpls cloud to a site in
Sukhrali Chowk, Gurgaon, Haryana, India
Thanks,
JoeWhat does traceroute show?
traceroute shows me the three hops of the mpls cloud.