is it possible you can look into routing issues i found? this is how you can get a 1up on telus ;)

[msantore22]

to shaw staff,

how are you today? I am writing today because i found possible routing issues that affect latency in certain online games, and i am wondering if they can fixed?

I discovered that some east coast routes to chicago specifically , decide to go through seattle before going to chicago, instead of  going through winnipeg to chicago like it should. both these tracerts initiated from edmonton. and this results in higher than expected latency. while other routes to chicago go through winnipeg without problems. routes to chicago that go through winnipeg provide 20 ms of lower latency and this could potentially keep a customer from changing over to telus.

i've been doing extensive research into ping times. from many different routing tables. and looking glass softwares. currently telus is winning by a small margin in ping tests to los angeles, (yes its true i checked their looking glass software)  but fixing these routes to chicago could potentially allow shaw to have a higher advantage, and another reason for customers to keep the service. 


here is the first tracert to an ip in chicago, the server wasnt pingable, but the initial routes should give you an idea of why going through seattle is bad:

Tracing route to 24.105.34.114 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms OpenWrt.lan [192.168.1.1]
2 8 ms 15 ms 9 ms 96.52.128.1
3 13 ms 13 ms 11 ms rc2ar-be117-1.ed.shawcable.net [64.59.186.161]
4 10 ms 8 ms 9 ms rc2we-be7.ed.shawcable.net [66.163.70.129]
5 14 ms 12 ms 17 ms rc3no-be6.cg.shawcable.net [66.163.64.69]
6 28 ms 27 ms 28 ms rc2wt-be100.wa.shawcable.net [66.163.75.233]
7 60 ms 29 ms 73 ms rc6wt-tge0-10-0-11.wa.shawcable.net [66.163.68.70]
8 95 ms 65 ms 62 ms ae1-br02-eqse2.as57976.net [137.221.73.35]
9 * * * Request timed out.
10 60 ms 59 ms 65 ms et-0-0-1-pe01-eqch2.as57976.net [137.221.69.51]
11 64 ms 60 ms 62 ms chi-eqch2-ia-bons-01.as57976.net [137.221.66.9]
12 58 ms 60 ms 63 ms 24.105.62.147
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.



now if you look at these proper routes to chicago, where i have a vpn server there, i get significant lower ping(20 ms lower) ,

Tracing route to 45.76.16.99.vultr.com [45.76.16.99]
over a maximum of 30 hops:

1 17 ms <1 ms <1 ms OpenWrt.lan [192.168.1.1]
2 8 ms 8 ms 7 ms 96.52.128.1
3 9 ms 9 ms 7 ms rc2ar-be117-1.ed.shawcable.net [64.59.186.161]
4 23 ms 23 ms 23 ms rc3sc-be1.wp.shawcable.net [66.163.70.77]
5 39 ms 38 ms 39 ms rc4ec-be25-1.il.shawcable.net [66.163.75.134]
6 65 ms 40 ms 46 ms 20473.chi.equinix.com [208.115.137.46]
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 40 ms 40 ms 38 ms 45.76.16.99.vultr.com [45.76.16.99]

Trace complete.

both tests were completed on shaw's network....

why do i get different routes to the same city? to me it sounds as simple as just saying hey look for edmonton routes to as57976 please go through winnipeg, otherwise  if down, go through vancouver. im sure someone can fix that?

i feel like shaw could do better you know?

i used to get 40ms to that ip first tracert 2 years ago. someone changed the routes, i am asking for the routes to be changed back.

thanks for your time

[g-idk]

Hi @msantore22 ,  I don't work for Shaw or am I a techy, but I'd recommend since this is peer to peer discussion forum and not always visited by Shaw Support,  that you send your suggestion/issues directly to Shaw by scrolling down to the bottom of this page after reading this and under the heading About Us you will find near the bottom Your Voice click on that link to fill out a form for them to read and get a response from Shaw.  Wish I could help you with fixing the issue but you wrote such a well worded statement , that it would be a shame if Shaw never saw it.  Good Luck Stay Safe. 

[mdk]

@msantore22 -- here is the first tracert to an ip in Chicago:

 3 11 ms rc2ar-be117-1.ed.shawcable.net [64.59.186.161]
 4   9 ms rc2we-be7.ed.shawcable.net [66.163.70.129]
 5 17 ms rc3no-be6.cg.shawcable.net [66.163.64.69]
 6 28 ms rc2wt-be100.wa.shawcable.net [66.163.75.233]
 7 73 ms rc6wt-tge0-10-0-11.wa.shawcable.net [66.163.68.70]
 8 62 ms ae1-br02-eqse2.as57976.net [137.221.73.35]
 9 * * * Request timed out.
10 65 ms et-0-0-1-pe01-eqch2.as57976.net [137.221.69.51]
11 62 ms chi-eqch2-ia-bons-01.as57976.net [137.221.66.9]

Thus, Edmonton -> Calgary -> Vancouver (under an "wa" alias) -> Washington State -> Seattle -> Chicago

Here is a trace to another IP-address in Chicago, namely www.uchicago.edu

Tracing route to wsee2.elb.uchicago.edu [34.225.113.202]

  4    21 ms  rc1bb-be20.vc.shawcable.net [66.163.75.245]
  5    13 ms  rc1st-be25.vc.shawcable.net [66.163.69.198]
  6    25 ms  rc3no-be11-1.cg.shawcable.net [66.163.72.69]
  7    46 ms  rc2nr-be110-1.wp.shawcable.net [66.163.76.58]
  8    67 ms  rc3fs-be25.mt.shawcable.net [66.163.76.22]

Thus, Vancouver -> Calgary -> Winnipeg -> Montreal, before crossing into the USA.

Routing-tables in each router on the Internet define the routes for the packets, and contain information about which segments are "high-capacity" and which segments have a lesser capacity.

So, from Vancouver, some routes stay within Shaw's network in Canada, and some routes immediately go south to Seattle, and then across the USA.

The Internet is a "mesh" of routes, like the multiple roads between Edmonton and Camrose. Some roads, like the #2 highway, have higher speed-limits than the minor roads, and have more lanes in each direction. Some roads, like Calgary to Banff, may have multiple lanes going "uphill" into the Rockies, where a single lane goes "downhill" on the same segment of Highway #1. Commercial truckers use the "slow-lane" for slowly going uphill.

I don't know the capacity of Shaw's Edmonton -> Vancouver segment, as compared to their Edmonton -> Montreal segments, but they could be very different, and that difference would be reflected in the routing-tables.

It would be nice if Blizzard were to "co-locate" their game-servers just one hop "away" from an Internet "backbone" node, to reduce the latency, as compared to the latency between their currently-closest backbone-node and their service-provider's data centre.

[msantore22]

I appriecate your reply,

for the sake of argument though, that host name and ip address "wsee2.elb.uchicago.edu [34.225.113.202]"

are located in Virginia, Ashburn,
https://check-host.net/ip-info?host=34.225.113.202
https://check-host.net/ip-info?host=wsee2.elb.uchicago.edu

thats definitely, not chicago,

i would still like to see shaw reply about these possible route issues to chicago

[mdk]

@msantore22 -- that is definitely not chicago, 

You are correct. The U. of Chicago is using one of the AMAZON Elastic Cloud data-centres, in Auburn, Virginia.

Here's a traceroute to "Columbia College", in Chicago:

Tracing route to www.colum.edu [216.146.221.38]

  4    12 ms  rc1bb-be20.vc.shawcable.net [66.163.75.245]
  5    32 ms  rc3so-be6-1.cg.shawcable.net [66.163.78.37]
  6    63 ms  rc4ec-be13.il.shawcable.net [66.163.65.18]
  7    58 ms  rc3ec-be6-1.il.shawcable.net [66.163.65.69]

and here is one to DePaul University, also in/near Chicago

Tracing route to www.l.depaul.edu [216.220.184.50]

  5    11 ms  rc1wt-be40.wa.shawcable.net [66.163.68.18]
  6    12 ms  six.tr-cps.internet2.edu [206.81.80.77]

That "Internet 2" network is a high-speed network for educational institutions in the USA, interconnected to the Canarie research network in Canada.

> I would still like to see Shaw reply about these possible route issues to Chicago

As @g-idk wrote, this is a peer-to-peer discussion forum, not a path to Shaw Support.  So, it is doubtful that the few self-identified Shaw employees on this forum will see this discussion thread.

The routing-tables are the routing tables, for better or for worse.  I imagine that they already are "optimal", given the network capacity of the segments between each pair of routers.

P.S. Please check the Canarie Weather Report for real-time reports on the "load" on each segment within their network.

[mdk]

>>> Please check the Canarie Weather Report for real-time reports on the "load" on each segment within their network.

When I do, I see an anomaly:

Zero. Either a broken connection, or some problem with reporting of the data.

I wonder if all the washed-out roads in B.C., due to the "atmospheric rivers", have made it physically impossible for repair crews to get to a location that has a "break" ?