Online.net - bandwith problems / peering politics

Microlinux

@joepie91 said:

@Microlinux said:

@hawc said:
I think this whole "double standards" setup is horrific.

Then there is the whole thing where it's not a "double standard" - but rather a differentiation of product lines. Am I mis-understanding something?

Yes. It was applied retroactively, and not explained clearly in the product marketing.

Neither of which makes a double standard.

To avoid "applied retroactively", you typically sign a contract. You adapt to the world, not the other way around.

Nihim

@Amitz said:
And what's the outcome? Anything useful coming from them?

Waiting for their reply. I am not expecting much since usually mtrs / iperfs come clean, unless there is something really broken?

Spacedust

See this:

https://status.online.net/index.php?do=details&task_id=681

and this:

https://status.online.net/index.php?do=details&task_id=682

C0mpass

I'm not having any issues. Dedibox XC Sata

$ iperf -c iperf.ovh.net

Client connecting to iperf.ovh.net, TCP port 5001

TCP window size: 85.0 KByte (default)

[ 3] local 163.172.221.93 port 36528 connected with 188.165.12.136 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 2.12 GBytes 1.82 Gbits/sec

Lee

@myhken said:
So much fuzz about an network error...people getting rid of servers etc, all for nothing. LOL

sigh...

myhken

@Lee said:
sigh...

Yeah Yeah, I know. But I had to rub it in little...

hawkjohn7

i'm not getting slow bandwidth with my dedibox XC 2016 DC2.

om2ganteng@ssd:~/Downloads/Re Zero$ vnstat -l
Monitoring enp0s20f0...    (press CTRL-C to stop)

   rx:     8.57 Mbit/s 16469 p/s          tx:     1.10 Gbit/s 93471 p/s

Lee

The message that a few people I know have been getting is that they are testing, it is not affecting everyone. Once they make a final decision it will be communicated out to all those affected.

When that happens it is not clear. The bottom line is that have realized the cheaper boxes are purchased by people who make more use of the limits offered and they can't soak it up for the price charged.

Nihim

@Amitz

they replied along the lines of: yo better now?

and it does seem so - so far. Will try to poke for more details.

ps: for context this was for a scaleway machine.

PirateHitman

Apparently they 'fixed' it

https://status.online.net/index.php?do=details&task_id=682

Spacedust

I wish they add Telia link to AMS-1. However my current server in France has way lower ping now !

It dropped from 46 ms to 35 ms

gustavargas

Yesterday I had very slow speeds from Chile to my VPS in Scaleway, maybe related?

tommy

@gustavargas,@Nihim how do you test ? your server

On my scaleway most of the time I got ~ 6 MB/s to Singapore, ~ 3MB/s to my home, to tim4vps 11 MB/s

Nihim

I realised the problem after I saw several connections to different places that I know their usual speed drop from 50-90% in speed. If that's what you meant.

Spacedust

Typical route from DC2 to UPC Poland:

traceroute to 83.144.97.50 (83.144.97.50), 30 hops max, 60 byte packets 1 163-172-24-1.rev.poneytelecom.eu (163.172.24.1) 0.319 ms 0.507 ms 0.490 ms 2 a9k1-49-s45-1.dc3.poneytelecom.eu (195.154.1.108) 0.947 ms 195.154.2.8 (195.154.2.8) 0.830 ms 195.154.2.38 (195.154.2.38) 1.061 ms 3 be4752.rcr21.b039311-0.par04.atlas.cogentco.com (149.6.165.65) 1.206 ms be4751.rcr21.b022890-0.par04.atlas.cogentco.com (149.6.164.41) 2.212 ms 2.433 ms 4 be2144.ccr21.par04.atlas.cogentco.com (154.54.39.37) 1.220 ms 1.450 ms 1.417 ms 5 be12308.ccr41.par01.atlas.cogentco.com (130.117.49.41) 1.222 ms 1.448 ms 1.438 ms 6 be2746.ccr41.jfk02.atlas.cogentco.com (154.54.29.117) 73.905 ms 72.480 ms 72.386 ms 7 be2324.ccr21.jfk04.atlas.cogentco.com (154.54.47.18) 72.826 ms be2325.ccr21.jfk04.atlas.cogentco.com (154.54.47.30) 72.357 ms 74.597 ms 8 telia.jfk04.atlas.cogentco.com (154.54.11.110) 85.500 ms 84.932 ms 87.221 ms 9 liberty-ic-302304-nyk-b3.c.telia.net (62.115.13.74) 77.438 ms 75.534 ms 75.269 ms 10 us-nyc01b-rd2-et-3-1-0-0.aorta.net (84.116.135.74) 118.061 ms 117.180 ms 117.568 ms 11 us-was03a-rd1-xe-1-0-0.aorta.net (84.116.130.162) 117.449 ms 116.938 ms 116.926 ms 12 nl-ams05a-rc2-lag-22-0.aorta.net (84.116.136.141) 118.776 ms 116.817 ms 116.789 ms 13 pl-waw04a-rc1-ae10-0.aorta.net (84.116.136.142) 125.885 ms 125.830 ms 126.033 ms 14 pl-waw17a-rd1-ae1-2114.aorta.net (84.116.252.58) 116.619 ms 116.831 ms 117.052 ms 15 pl-waw04a-rc1-ae17-2114.aorta.net (84.116.252.57) 139.542 ms pl-waw17a-rd2-ae0-2115.aorta.net (84.116.252.62) 117.476 ms pl-waw04a-rc1-ae17-2114.aorta.net (84.116.252.57) 139.472 ms 16 pl-waw02a-ra2-be-2-2151.aorta.net (84.116.252.206) 117.761 ms pl-waw26b-rc1-ae21-2185.aorta.net (84.116.137.101) 119.224 ms pl-waw02a-ra2-be-2-2151.aorta.net (84.116.252.206) 117.949 ms 17 84.116.252.1 (84.116.252.1) 117.775 ms pl-waw02a-ra1-be-2-2150.aorta.net (84.116.252.202) 117.563 ms 84.116.252.1 (84.116.252.1) 118.996 ms

It goes from Paris to JFK ?, then New York, Washington, Amsterdam, then Warsaw.

Spacedust

Ping to DC2 raised again from 34 to 38-40 ms. I'm switching to Amsterdam in a few days.

boernd

@Spacedust said:
Typical route from DC2 to UPC Poland:

Same to UPC germany (unitymedia) from my dedibox XC with basic bandwidth:

                                                        Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 163-172-29-1.rev.poneytelecom.eu               50.0%    49  388.1 415.4 327.0 544.5  72.2
 2. 195.154.1.146                                   0.0%    49    0.7   0.8   0.6   1.7   0.0
 3. be4752.rcr21.b039311-0.par04.atlas.cogentco.co  0.0%    49    1.8   1.5   1.2   3.5   0.3
 4. be2144.ccr21.par04.atlas.cogentco.com           0.0%    49    1.3   1.3   1.0   4.0   0.4
 5. be12309.ccr42.par01.atlas.cogentco.com          0.0%    49    1.7   1.3   1.1   1.8   0.0
 6. be2747.ccr42.jfk02.atlas.cogentco.com           0.0%    49   71.8  72.0  71.8  73.4   0.2
 7. be2325.ccr21.jfk04.atlas.cogentco.com           0.0%    48   72.3  72.5  72.2  75.6   0.4
 8. telia.jfk04.atlas.cogentco.com                  0.0%    48   85.2  85.6  85.2 102.7   2.5
 9. nyk-bb1-link.telia.net                          0.0%    48   89.4  96.1  84.9 172.0  23.2
10. ash-bb3-link.telia.net                          0.0%    48   85.9  85.6  85.3  86.0   0.0
    ash-bb3-link.telia.net
    ash-bb3-link.telia.net
    ash-bb3-link.telia.net
    prs-bb3-link.telia.net
    ash-bb3-link.telia.net
    ash-bb3-link.telia.net
    ash-bb3-link.telia.net
11. ash-b1-link.telia.net                           0.0%    48   86.5  84.4  78.3  94.8   3.5
    ash-b1-link.telia.net
    ash-b1-link.telia.net
    ash-b1-link.telia.net
    ash-b1-link.telia.net
    ash-b1-link.telia.net
    ash-b1-link.telia.net
12. liberty-ic-306029-ash-b1.c.telia.net            0.0%    48   97.6 100.5  97.2 142.1   8.8
13. us-was02a-rd2-ae10-0.aorta.net                  0.0%    48  100.2 100.3  99.7 104.8   0.9
14. ???
15. de-dus23e-rc1-ae19-0.aorta.net                  0.0%    48  100.9 107.6  99.4 133.7  11.0
16. 84.116.196.218                                  0.0%    48  109.3 106.3  99.5 129.8   8.3
17. 84.116.196.222                                  0.0%    48  196.7 107.5  99.4 196.7  18.0
18. ???
19. ip-178-201-XX-XXX.hsi08.unitymediagroup.de      0.0%    48  106.2 106.8 102.7 110.4   0.9

same target, but tested from a dedibox classic in DC2:

Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 195-154-97-1.rev.poneytelecom.eu 0.0% 4 0.6 0.6 0.6 0.6 0.0 2. a9k2-49e-s46-3.dc3.poneytelecom.eu 0.0% 4 0.8 0.7 0.6 0.8 0.0 3. prs-b8-link.telia.net 0.0% 4 0.9 1.6 0.9 3.6 1.2 4. prs-bb2-link.telia.net 0.0% 4 33.5 24.6 0.9 63.1 29.9 5. prs-b5-link.telia.net 0.0% 4 1.4 1.6 1.4 1.8 0.0 prs-b5-link.telia.net prs-b5-link.telia.net prs-b5-link.telia.net 6. upc-ic-305532-prs-b5.c.telia.net 0.0% 4 1.5 1.5 1.4 1.8 0.0 7. fr-par02b-rd1-ae7-0.aorta.net 0.0% 3 12.1 12.0 11.9 12.1 0.0 8. de-fra01b-rc1-ae22-0.aorta.net 0.0% 3 29.4 18.0 12.1 29.4 9.8 9. 84.116.133.101 50.0% 3 20.7 20.7 20.7 20.7 0.0 10. 84.116.196.225 0.0% 3 11.6 11.6 11.6 11.6 0.0 11. ??? 12. ip-178-201-XX-XXX.hsi08.unitymediagroup.de 0.0% 3 17.9

gustavargas

@tommy said:
@gustavargas,@Nihim how do you test ? your server

On my scaleway most of the time I got ~ 6 MB/s to Singapore, ~ 3MB/s to my home, to tim4vps 11 MB/s

Downloading a file and with speedtest.net mini haha

Razza

Spacedust said: It goes from Paris to JFK ?, then New York, Washington, Amsterdam, then Warsaw.

Not really a online issue, the issue is with Cogent Communications crap routing, if you do a traceroute on cogent's looking glass even from there warsaw location it still goes to the usa

1  gi0-4-0-18.111.ccr21.waw01.atlas.cogentco.com (130.117.254.209)  1.181 ms  1.180 ms
 2  be2252.ccr41.ham01.atlas.cogentco.com (154.54.60.253)  12.989 ms be2253.ccr42.ham01.atlas.cogentco.com (154.54.61.1)  13.075 ms
 3  be2816.ccr42.ams03.atlas.cogentco.com (154.54.38.209)  21.844 ms  21.811 ms
 4  be12194.ccr41.lon13.atlas.cogentco.com (154.54.56.93)  102.568 ms be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41)  99.448 ms
 5  be2983.ccr22.bos01.atlas.cogentco.com (154.54.1.178)  99.859 ms  99.883 ms
 6  be2094.ccr41.jfk02.atlas.cogentco.com (154.54.30.13)  99.811 ms be2096.ccr42.jfk02.atlas.cogentco.com (154.54.30.41)  96.121 ms

I understand why online.net is putting there cheap server's traffic via Cogent as its the cheapest off all the transit network provider (Cogent,Tata,Telia) they use.

William

Amitz said: I get your point, but he paid for something else when he ordered.

NO, he did not.

If you read the ToS the speed is in no way guaranteed and neither the French nor the EU has a law that says you need to provide an advertised speed to all locations (this does, to some extent, exist for end-user connections but mostly - like soon here in Croatia - only mandates you have to get at least N % of the promised speed, not any BW).

Essentially the laws - where existing - say you need to provide it outside of your own controlled network (and this is already carrier directed laws, not dedicated/colo/enduser) which is already done with a single AS hop in the middle. A 10G DECIX link and 1G transit does let you sell 10G unmetered perfectly legal, if you do not guarantee to where (or anything at all). Reputation wise, probably not ends as good though.

Now, if you pay 15EUR and try to push N Gbit to UPC, ONO or TPSA (or worse, DTAG) you will have a bad time if the only way to get there "cheaply" is still at 1EUR+/Mbit on 10G commit on 10G port (which is realistically just about 9G usable) and the "interconnect"/"peering" agreements mandate you need to have a POP in El Salvador, Pyongyang and Beijing with funky 1:999 bullshit ratios to get free peering.... there IS a reason why major university networks route to UPC via transit, and they get peering with anyone in Europe usually.

William

Razza said: Not really a online issue, the issue is with Cogent Communications crap routing, if you do a traceroute on cogent's looking glass even from there warsaw location it still goes to the usa

No, the issue is on both sides, in this case Telia has complains about Cogents traffic for Netflix or something similar IIRC, also the HE/Cogent case extends over the head of Telia (which has major shit going on with HE).

Cogent and Level3 have a well known dispute since many years on traffic ratios where (depending on year and the color of the sky) either side complains about the other selling too much to end-user/business networks, on rare times you can see a direct AMS interconnect pop up and in better times you had one in London and Fra also.

UPC is a major Level3 user and unlike Cogent Level3 can for now avoid (many reasons, all upfront money and influence) most issues to all networks which are not singlehomed to Cogent.

It's kind of the passive aggressive version of the Cogent/HE IPv6 peering split, just on IPv4 with actual real consequences.

Razza

William said: No, the issue is on both sides

I probably should have said the issue was both of them, didnt know Cogent had dispute with Level3 and HE too.

I already know Level3 was one of Liberty Global (UPC) main upstream.

Thanks for the insight into Cogent dispute's

sman

I guess the more important question to the OP is were you using all that bandwidth constantly? That might be part of the problem and they are singling you out. I think everyone reserves the right to change or cancel peoples service in their ToS.

btk99

@sman said:
I guess the more important question to the OP is were you using all that bandwidth constantly? That might be part of the problem and they are singling you out. I think everyone reserves the right to change or cancel peoples service in their ToS.

I did not use all the bandwith constantly. I am running a Web- / Mailserver with about 40 Users. For using my storage cloud there are sometimes peaks in the bandwith, but that are max. 100 mbit/s and in a month i dont have more than 300gb traffic.
Every night an incremental backup runs to an OVH server, but in total i dont need much traffic / bandwith. The Torrent seeders need much more i guess.
I was very disappointed, it seemed like the "normal" customers would have to accept the consequences (change of the peering conditions). But at least until now everything is ok for me - i guess they canceled all the tests and did not change anything permanently.

Spacedust

I'm using about 5-10 Mbps and now there is no routing to my server at all

boernd

@btk99 said:

i guess they canceled all the tests and did not change anything permanently.

They did, check the routing from a XC or SC to UPC/unitymedia/Liberty Global and check again from any other dedibox. 100ms latency vs 30ms.