Hi Bernd,

uh, I started a big discussion here ;)

2013/2/5 Bernd SPIESS bernd.spiess@essgroup.at:

hi stephan this is the reason why it is important to really really pick carefully your ip-access or ip-transit provider. ip is not a matter of price/mbit as you can see here

from that point you are completely right.

we as service providers can choose. also I did. I have multiple ISP's @home (yess...), and also in all datacenters.

bu see customer side: - they can choose, too - but they don't care - they choose by price - or because basis link is already there

effectively: - imagine you offer a partners service in sitzerland - and the access is slow for customers - effectively cablecom customers - reason is cablecom ('s peering policy) - but they don't care

so effectively technical this is not my problem here. it is a problem from customers chosen ISP

but again: tell this (just a guess) 1.5 milllion cablecom internet customers

no chance ;)

the only solution: - most cablecom customers must be unhappy and cancel contract - then they may change peering policy

but effectively they will cancel "the other side". because they don't care.

cheers, stephan

ps: got no feedback by upc at all

hi stephan

this is the reason why it is important to really really pick carefully your ip-access or ip-transit provider. ip is not a matter of price/mbit as you can see here -

study peering connect, peering policy and peering reality, for the ip carrier of your choice, carefully in all markets, which are important for you.

in general it is not unusual that you have ip networks which are focused on routing primary e.G. via usa, amsterdam or scandinavia - depending on where their headquarter is running -

if the given names belongs to a category which you want to blacklist is your decision - i don´t want to comment this here...

in general it is high likely that smaller national isp´s/carriers or even regional players with an eye and feeling for peering points in the own and neighboring countries came out with a much better performance than big-tier1 - especially if these ones are involved in playing peering politics ...

for some more information just search fredys blog on cablecom issues ...

bernd spiess i3b/ascus/xpirio/essgroup (AS39912)

Von: swinog-bounces@lists.swinog.chmailto:swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Gregory Agerba Gesendet: Dienstag, 05. Februar 2013 17:21 An: Stephan Wolf Cc: swinog@swinog.chmailto:swinog@swinog.ch Betreff: Re: [swinog] Cablecom Home to London via USA

Do you mean UPC is routing Cogent through USA? Basically, UPC doesn't peer with Cogent and have it delivered by their upstreams. This is called hair pinning and it is probably one of the very few major network that has such issue with UPC.

Gregory

On 5 February 2013 17:11, Stephan Wolf <swinog-ch@hightowernet.demailto:swinog-ch@hightowernet.de> wrote: hello,

since longer I have seen, that UPC is routing Cablecom Home connetions via US to London:

Tracing route to 82.129.64.250 over a maximum of 30 hops

2 46 ms 68 ms 52 ms 77-56-176-1.dclient.hispeed.chhttp://77-56-176-1.dclient.hispeed.ch [77.56.176.1] 3 58 ms 58 ms 43 ms 217-168-58-101.static.cablecom.chhttp://217-168-58-101.static.cablecom.ch [217.168.58.101] 4 139 ms 140 ms 145 ms 84.116.211.22 5 149 ms 145 ms 140 ms 84.116.204.225 6 163 ms 171 ms 171 ms fr-par02a-rd1-gi-15-0-0.aorta.nethttp://fr-par02a-rd1-gi-15-0-0.aorta.net [84.116.130.213] 7 147 ms 155 ms 163 ms 84-116-130-61.aorta.nethttp://84-116-130-61.aorta.net [84.116.130.61] 8 167 ms 135 ms 165 ms 84.116.134.66 9 203 ms 233 ms 179 ms te-4-1.car3.Washington1.Level3.nethttp://te-4-1.car3.Washington1.Level3.net [4.79.168.201] 10 147 ms 149 ms 145 ms ae-2-70.edge3.Washington4.Level3.nethttp://ae-2-70.edge3.Washington4.Level3.net [4.69.149.82] 11 152 ms 144 ms 147 ms Cogent-level3-1x10G.washington.Level3.nethttp://Cogent-level3-1x10G.washington.Level3.net [4.68.63.174] 12 158 ms 149 ms 171 ms te0-5-0-2.mpd22.dca01.atlas.cogentco.comhttp://te0-5-0-2.mpd22.dca01.atlas.cogentco.com [154.54.2.41] 13 167 ms 150 ms 143 ms te0-2-0-2.mpd22.jfk02.atlas.cogentco.comhttp://te0-2-0-2.mpd22.jfk02.atlas.cogentco.com [154.54.5.49] 14 243 ms 254 ms 246 ms te0-2-0-2.mpd22.lon13.atlas.cogentco.comhttp://te0-2-0-2.mpd22.lon13.atlas.cogentco.com [154.54.42.54] 15 218 ms 223 ms 237 ms te0-3-0-6.ccr22.lon01.atlas.cogentco.comhttp://te0-3-0-6.ccr22.lon01.atlas.cogentco.com [154.54.74.61] 16 253 ms 240 ms 232 ms te2-1.ccr01.lon18.atlas.cogentco.comhttp://te2-1.ccr01.lon18.atlas.cogentco.com [154.54.61.214] 17 231 ms 246 ms 251 ms 149.14.8.34 18 227 ms 241 ms 230 ms 82.129.64.250

which causes high latencies

via all other providers in CH which we have tried out, incl. and swissix, we have much better connections / less latency. also all our ISP's in germany have good connections

only UPC lames - that sucks ;-(

may someone of cablecom can check this, and contact me offlist ?

thanks in advance stephan

_______________________________________________ swinog mailing list swinog@lists.swinog.chmailto:swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

3 58 ms 58 ms 43 ms 217-168-58-101.static.cablecom.ch[217.168.58.101] 4 139 ms 140 ms 145 ms 84.116.211.22 I'd say here's where the problem begins and it still UPC network I think.

sorry - no - as the handover takes part in washington you have twice the atlantic in between... it´s a problem of peering/transiting in usa and not a upc internal problem in ch.

it is the responsibility of the first network handing over in europe on the way "up" and it is the responsibility of the second network handing over also in europe on the way "down". (zurich, amsterdam or london would be suited in this case)

as this is not the the case here you should tell them to fix that, or choose another provider who does good ip housekeeping.

bernd

On 2013-02-05 19:31 , Andreas Fink wrote:

side note: I was testing LTE in Basel. Speed is lower than 3G (like 3-5M/sec) I wondered why as my friends in Finland get like 40M/s

LTE is not deployed yet for real in Switzerland...

Note also that for instance

What spring to my mind however is that the speed test tools do in fact measure speed with local providers around the corner. And as far as I know, swisscom doesn't peer on SwissIX with them so it might very likley be a similar ping-pong through somewhere else in europe or USA which is potentially ruining the speed. Of course it could simply be not enough capacity inside the mobile network.

Did you try a traceroute?

From my experience Swisscom is doing great peering with most

destinations that I use, be those local or remote (eg the US). (the only thing one could say is that some goes over Geneva, but that is apparently where their DSL handoff happens)

My point is: PEERING PAYS OFF. No matter how "evli" your competitor might look like, both save money and gain speed. Even ISP's in other parts of the world have started to realize that its stupid to send off traffic across continents just because they don't like the competitor.

You are missing the important point about peering: http://www.youtube.com/watch?v=PUYdi43qXHc

Oh and of course if you 'cut off' your competitor that might just be a business case for a customer to go to you or them, next to them not being tier-1 enough....

Also, do calculate into the equation the cost of the interfaces needed to have traffic transfer at one or the other location.

In the end though it is a penis game...

Greets, Jeroen

Just some thoughts...

study peering connect, peering policy and peering reality, for the ip carrier of your choice, carefully in all markets, which are important for you.

Yes, but this changes daily. If you are single-homed, brace and hope everything keeps "as is" when things work. Good example: Swisscom was primary transit was Level(3) for ages and suddenly changed and brought a new stringent peering policy based on ratios. It probably changed a lot the perception when the traffic moved from AS3356 to AS1299 almost in one day.

I'd say here's where the problem begins and it still UPC network I think.

There is no "problem" between UPC and Cogent. This is meant to be so, because UPC does have a wide footprint and Cogent too and they have conflicting interests. UPC is known to narrow-minded peering policy. UPC does have operations in a lot of countries (AT, BE, CH, CZ, DE, HU, IE, NL, PL, RO, SK) and more to come, they have a lot of eyeballs and can afford that... the winner here is the one who pays the least for his transit, or the one who has settlement-free peering with Level(3).

it is the responsibility of the first network handing over in europe on

the

way "up" and it is the responsibility of the second network handing over also in europe on the way "down". (zurich, amsterdam or london would be suited in this case)

Correct. Any multihomed network can decide how they want to route. They control the way, the flow are sent out, but not the way they are received. Using BGP protocol, it is possible for anybody to influence this and have the last word, unless depeering gets involved.

From my experience Swisscom is doing great peering with most destinations that I use, be those local or remote (eg the US). (the only thing one could say is that some goes over Geneva, but that is apparently where their DSL handoff happens)

Not sure they do. Especially with the changes that occured lately. Their "ratio" peering policy, or paid peering policy will definitely cause collateral damages. They have already treated to depeer some medium-size network but have not yet done it. At least for the networks I am aware of. When money is at stake it seems the good-faith wins ;-)

My point is: PEERING PAYS OFF. No matter how "evli" your competitor might look like, both save money and gain speed. Even ISP's in other parts of the world have started to realize that its stupid to send off traffic across continents just because they don't like the competitor.

Your point is very questionable. While peering is a good way to address route diversification, it also tends to be used to shift "cheaply" all traffic, ending up with oversubscribed links, higher latency, jitters, and an overall bad quality. Too many networks see peering as the way to get masses of bandwidth for cheap, while ending up with suboptimal network quality of service. Add the hazardous BGP alogrithm for route selection and you got all the ingredients of a "swinish" network.

Most people who tends to say this lack

Gregory

On 5 February 2013 20:39, Fabian Wenk fabian@wenks.ch wrote:

Hello Jeroen

On 05.02.2013 19:56, Jeroen Massar wrote:

...

You are missing the important point about peering: http://www.youtube.com/watch?**v=PUYdi43qXHchttp://www.youtube.com/watch?v=PUYdi43qXHc

And this shows just an other problem of this world, which also matches the title of the Video "Meja - A'll Bout The Money":

"This video contains content from SME, who has blocked it in your country on copyright grounds. - Sorry about that."

bye Fabian

______________________________**_________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-**bin/mailman/listinfo/swinoghttp://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Hello Jeroen

On 06.02.2013 08:43, Jeroen Massar wrote:

On 2013-02-05 20:39 , Fabian Wenk wrote:

...

On 05.02.2013 19:56, Jeroen Massar wrote:

...

You are missing the important point about peering: http://www.youtube.com/watch?v=PUYdi43qXHc

And this shows just an other problem of this world, which also matches the title of the Video "Meja - A'll Bout The Money":

"This video contains content from SME, who has blocked it in your country on copyright grounds. - Sorry about that."

Long live geoIP not working yet for IPv6 ;)

I did connect with IPv6, and I just tried again, with IPv4 and IPv6 and I only get the above message, see [1]. :( The IPvFox Add-on [2] is a nice help.

[1] http://www.wenks.ch/fabian/YouTube-All_Bout_The_Money.png [2] https://addons.mozilla.org/firefox/addon/ipvfox/

PS: No need to use "reply all", reply only to the list is perfect, as I do filter e-mails based on the "List-Id" header line.

bye Fabian