Witam.

Jestem klientem firmy LubMAN UMCS, jednego z najstarszych lubelskich ISP
od dłuższego czasu. Do niedawna usługi tej firmy (niegdyś "sponsorowanej"
przez KBN) świadczone były na zadawalającym poziomie, nie licząc pewnych
potknięć z przeszłości. Ostatnimi jednak czasy zauważalna zaczyna być
ogromna zmiana w podejściu do klienta.

W tej chwili f-ma LubMAN UMCS posiada łącza do: TPSA (8 Mbps), IPartners
(5 Mbps), POL34 (34 Mbps minus PVC do ICM, TASK, IPartners). Na powyższych
łączach działa kilkuset klientów, głównie posiadających łącza 10 Mbps,
niektórzy 2 Mbps. Niecałe dwa lata temu klienci zostali zobligowani do wyboru
konkretnej opcji limitów pasma na łączach międzyoperatorskich, w zależności od
przepustowości koszt wahał się od 125 zł do 12000 zł. Zgodnie z umową
oznaczało to ustawienie limitów na przepustowość od 8,5 Mbps do 29 Mbps.

Około trzy miesiące temu zarząd LubMAN UMCS wprowadził limit na dolną granicę
przepustowości dla portów szybszych niż 512 kbps (99% łącz klienckich
w mieście). Oznaczało to podwyżkę ceny świadczonej usługi o 375 zł,
*bez* wzrostu jakości świadczonej usługi. Podwyższenie limitów większości
użytkownikom komercyjnym spowodowało jeszcze większe obciążenie łącz
międzyoperatorskich.

W tym momencie dochodzę do meritum sprawy. 1 stycznia zauwazyłem
znaczne spowolnienie większości usług na łączach między operatorskich.
Tak się złożyło, że kilka dni wcześniej pojawił się dodatkowy router
przez który zaczął być kierowany cały ruch komercyjnej części MANu.
Bez *żadnej* zapowiedzi, pasmo wszystkich komercyjnych klientów LubMAN UMCS
zostało dramatycznie okrojne dla wszystkich portów TCP za wyjątkiem:
21, 20, 22, 25, 53, 79, 80, 110, 443 oraz ICMP ECHO (ciekawe dlaczego? każdy
klient to przecież jeleń, pokażemy mu RTT, wszystko jest OK). Co ciekawe,
redukcji nie uległo pasmo przyznane tzw. AS-owi edukacyjnemu, czyli
w rzeczywistości akademikom, na których jedyny ruch to setki gigabajtów
warezu.

Krótki test ujawnił skalę limitów pasma:

# hping -c 10 -S -p 80 www.pol34.pl
HPING www.pol34.pl (fxp0 212.51.192.18): S set, 40 headers + 0 data bytes
[...]
--- www.pol34.pl hping statistic ---
10 packets tramitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 18.5/24.1/39.3 ms

# hping -c 10 -S -p 1 www.pol34.pl
HPING www.pol34.pl (fxp0 212.51.192.18): S set, 40 headers + 0 data bytes
[...]
--- www.pol34.pl hping statistic ---
10 packets tramitted, 9 packets received, 10% packet loss
round-trip min/avg/max = 106.1/384.2/876.3 ms

# ping www.pol34.pl
PING kujawiak.man.lodz.pl (212.51.192.18): 56 data bytes
[...]
--- kujawiak.man.lodz.pl ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max/stddev = 17.975/35.453/53.979/11.219 ms

Jak widać, różnica RTT między limitowanym portem/protokołem a nielimitowanym
jest ponad 10-cio krotna. To samo się tyczy transferów. Test został
przeprowadzony z wykorzystaniem aktywnego FTP i pasywnego FTP (aktywne
nie jest limitowane):

233851 bytes received in 5.71 seconds (39.97 KB/s)
638960 bytes received in 3.14 seconds (198.58 KB/s)

Na poniższych outputach traceroute widać również dokładne miejsce,
w którym następuje limitowanie pasma:

traceroute to .lublin.pl (212.182.x.x), 64 hops max, 40 byte packets
1 62.233.130.245 (62.233.130.245) 17.947 ms 16.656 ms 3.707 ms (0% loss)
2 atm3-2-582-lub-pb1-lub-cr1.devs.futuro.pl (62.233.128.209) 4.737 ms 5.198 ms
19.401 ms (0% loss)
3 atm5-1-0-4-lub-cr1-lub-br1.devs.futuro.pl (62.233.128.29) 13.932 ms 26.079 ms
14.479 ms (0% loss)
4 janus.man.lublin.pl (212.182.95.65) 172.186 ms 10.418 ms 224.895 ms (0% loss)
5 shrike.man.lublin.pl (212.182.118.174) 32.160 ms 7.431 ms 7.466 ms (0% loss)
6 ciri.man.lublin.pl (212.182.63.133) 182.005 ms 423.087 ms * (33% loss)

W przypadku AS-a akademickiego sprawa wygląda zupełnie inaczej:

traceroute to .am.lublin.pl (212.182.x.x), 64 hops max, 40 byte packets
1 62.233.130.245 (62.233.130.245) 16.235 ms 5.153 ms 3.783 ms (0% loss)
2 atm3-2-582-lub-pb1-lub-cr1.devs.futuro.pl (62.233.128.209) 5.506 ms 4.637 ms
6.852 ms (0% loss)
3 atm5-1-0-4-lub-cr1-lub-br1.devs.futuro.pl (62.233.128.29) 6.179 ms 5.035 ms
6.272 ms (0% loss)
4 janus.man.lublin.pl (212.182.95.65) 24.739 ms 11.111 ms 10.918 ms (0% loss)
5 triss.man.lublin.pl (212.182.56.81) 14.701 ms 14.666 ms 10.838 ms (0% loss)
6 eskulap.am.lublin.pl (212.182.57.10) 17.015 ms 9.002 ms 7.565 ms (0% loss)

W ten oto sposób, f-ma LubMAN UMCS skutecznie ograniczyła możliwość
korzystania z pewnych usług, do których klient ma prawo. Chodzi tu
przede wszystkim o ledwie działające streamingi Real, gry sieciowe,
wszelkiej maści file sharery, możliwość korzystania z zewnętrznych
proxy, do których klient może mieć wykupiony dostęp, a także inne
aplikacje.

Wbrew zamysłowi jednak, nie spowodowało to zmniejszenia obciążenia
na łączach międzyoperatorskich. Jak pokazuje MRTG w POZMANie,
ruch na odcinku Lublin-Warszawa w dalszym ciągu zajmuje prawie całe
34 Mbps:

http://noc.man.poznan.pl/noc/index/statistics/public
znePOL34?page=ShowConnection&id=1042&node1=1006&node
2=1017

Jak nietrudno się domyślić, znakomita większość powyższego to misternie
przepychane warezy przez nielimitowanych niczym mieszkańców licznych
akademików.

W chwili obecnej, użytkownicy LubMANu zostali pozostawieni w sytuacji
bez wyjścia. Koszty zestawienia traktu światłowodowego w przypadku
wielu firm były na tyle wysokie (> 10000 zł), że nie mogą sobie one
pozwolić finansowo na rychłą zmianę ISP i ponoszenie dodatkowych kosztów,
natomiast poziom świadczonych usług (w cenie niewiele niższej od wyklinanego
POLPAKu) jest nie do przyjęcia. Bez komentarza pozostawiam też fakt braku
weekendowo-nocnych dyżurów, powodujący, że czas reakcji na awarie jest
niemiłosiernie długi.

Po przeżyciu całej tej historii na myśl przychodzą mi jedynie słowa:
nie taki POLPAK zły, jakim go malują...