Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 7 reacties

De Canadian Radio-Television and Telecommunications Commission heeft geweigerd om in een spoedprocedure de grote provider Bell Canada te verbieden om p2p-verkeer te vertragen op lijnen die aan kleinere providers zijn verhuurd.

Bell Canada logoBell Canada knijpt al sinds vorig jaar het p2p-verkeer op zijn lijnen af, met als argument dat dit noodzakelijk is om het overige verkeer voldoende bandbreedte te bieden. Een paar maanden geleden heeft Bell deze praktijk uitgebreid naar lijnen die zijn verhuurd aan kleinere providers. Die waren hier zeer verontwaardigd over, omdat ze de belofte van ongelimiteerde toegang aan hun klanten nu niet meer konden waarmaken. Ze verdachten bovendien Bell ervan de maatregel te hebben doorgevoerd om concurrentie op het gebied van p2p-verkeer onmogelijk te maken.

De Canadian Association of Internet Providers heeft daarom aan de toezichthouder CRTC gevraagd om Bell Canada onmiddellijk te verbieden om p2p-verkeer nog langer te vertragen. De CRTC oordeelde woensdag dat de zaak niet dringend genoeg is voor een spoedprocedure. Volgens de commissie hebben de providers onvoldoende aangetoond dat ze 'onherstelbare schade' lijden door de praktijken van Bell. Mocht het afknijpen van p2p-verkeer onrechtmatig blijken te zijn, dan kunnen de providers altijd nog een vergoeding van Bell krijgen.

De beslissing betekent niet dat de CTRC het vertragen van p2p-verkeer goedkeurt, maar alleen dat de zaak niet dringend genoeg is voor een spoedprocedure. In een normale procedure, die er ongetwijfeld wel zal komen, kan de handelwijze van Bell nog wel degelijk onrechtmatig bevonden worden.

Moderatie-faq Wijzig weergave

Reacties (7)

Het is natuurlijk maar net hoe zo'n contract tussen Bell en een kleine ISP in elkaar zit. Als er sprake is van het verhuren van 'ruwe' bandbreedte dan hebben de ISP's een punt. Waarschijnlijk heeft Bell wel een of andere clausule opgenomen die ze in staat stelt om dit te mogen doen.

Dit blijft natuurlijk een lastig punt. Als ik even op buienradar wil kijken om te zien of ik droog op de plaats van bestemming ga komen wil ik voorrang voor HTTP verkeer. Als ik mijn mail ophaal heeft POP3 prioriteit en als ik aan het FTP'en ben...

Ik kan me heel goed voorstellen dat een grote provider aan shaping doet, zeker als een bepaald protocol zo sterk gebruikt wordt dat de rest in de verdrukking komt. Het zou wel fijn zijn als elke ISP (en de andere betrokken partijen) daar gewoon open over zouden communiceren. De manier waarop het Internet in elkaar zit maakt het echter lastig om alstijd te weten langs welke lijnen de communicatie loopt en wat er dus precies wel of niet geshaped wordt.
Ik kan me heel goed voorstellen dat een grote provider aan shaping doet, zeker als een bepaald protocol zo sterk gebruikt wordt dat de rest in de verdrukking komt.
In principe heb je op een bepaalde lijn een oversubscriptie factoor. Bij hele dure lijnen is dat 1:1 (bandbreedte volledig gegarandeerd in het hele netwerk), zakelijk komt vaak 1:4 voor (25% van de bandbreedte gegarandeerd in het achterliggende netwerk) en voor consumenten lijnen is 1:10-1:50 gebruikelijk. Hoe goedkoper je ABO, hoe groter de oversubscriptie vaak is.

Wat ze IMHO moeten doen is je de gegarandeerde bandbreedte altijd leveren en zich verder niet bemoeien met wat je in die gegarandeerde bandbreedte doet. Als gebruiker wil ik zelf bepalen of ik binnen mijn overeengeomen bandbreedte prio geef aan P2P, HTTP, FTP of wat dan ook. Al het verkeer dat ik boven de garantie in de burstruimte genereer mogen ze dan afknijpen, ongeacht wat het is.

Het probleem zit er echter vaak in dat sommige ISP's de som van de gegarandeerde bandbreedtes op hun cores/peering/uplinks niet kunnen halen. World Offline (geen schrijffout) was daar vroeger het ultieme voorbeeld van. Ze verkopen wel extra lijnen maar upgraden hun core, hun peering of hun uplinks te langzaam om dat bij te benen. En dat proberen ze dan met afknijpen van bepaalde verkeersstromen op te lossen. Feitelijk komen ze dus hun contracten gewoon niet na.

Gelukkig zijn er zat providers die hun zaakjes wel goed voor elkaar hebben. Als je echter als kleine ISP volledig afhankelijk bent van het netwerk van een grote ISP die teveel bandbreedte verkocht heeft dan heb je een probleem.
Ik kan me heel goed voorstellen dat een grote provider aan shaping doet, zeker als een bepaald protocol zo sterk gebruikt wordt dat de rest in de verdrukking komt.
In de eerste plaats lijkt het me overigens helemaal niet onredelijk dat een protocol dat slechts 5% van het verkeer vormt, ook slechts 5% van de netwerkcapaciteit gebruikt. Een onderscheid tussen protocollen die voornamelijk voor real-time applicaties gebruikt worden en pakketjes die wel even kunnen wachten, ligt wat gevoeliger, maar het is een misvatting dat een protocol als http verdrukt zou worden doordat er te veel p2p-verkeer is. Als alle klanten massaal gegevens uitwisselen middels torrents en daarmee de lijnen bezetten, dan zal mijn http-verkeer inderdaad moeizamer verlopen, maar dat geldt voor mijn p2p-verkeer net zo goed.

Het onderliggende probleem is dat de ISP blijkbaar niet voldoende capaciteit in huis heeft om alle data moeiteloos door te geven. Met shaping kun je het ene pakketje voorrang bieden ten opzichte van een ander pakketje, maar de totale hoeveelheid data verandert daarbij niet. Traffic shaping lost dit probleem dus ook niet op.
Met shaping kun je het ene pakketje voorrang bieden ten opzichte van een ander pakketje, maar de totale hoeveelheid data verandert daarbij niet. Traffic shaping lost dit probleem dus ook niet op.
Klopt, en als er sprak is van excessief gebruik van een bepaald protocol waarvan je vrijwel zeker weet dat er geen sprake is van enige real time toepassing dan vind ik het helemaal niet erg dat die pakketjes iets later aankomen. Ik vergelijk het graag met een scheduler in een OS. Voor interactieve applicaties heb ik graag dat ze een wat hogere prioriteit hebben dan een achtergrond proces dat toch volledig autonoom loopt.

Ik denk (maar dat is natuurlijk pure speculatie want ik ken de contracten niet) dat er vrij weinig gezegd wordt over specifieke protocollen in dit soort contracten. Kan natuurlijk ook moeilijk, want morgen kan er opeens iets opduiken dat heel snel mateloos populair wordt. Hier zal dus waarschijnlijk de rechter of toezichthouder een uitspraak moeten doen over de redelijkheid van deze maatregel van Bell.
Met shaping kun je het ene pakketje voorrang bieden ten opzichte van een ander pakketje, maar de totale hoeveelheid data verandert daarbij niet. Traffic shaping lost dit probleem dus ook niet op.
Dat hangt ervan af hoe je je shaping inricht. Als je shaping alleen gebaseerd is op prioriteiten in de queues van je routers dan heb je bijna gelijk, maar ook daarbij gaan verkeersstromen van bijvoorbeeld P@P opdrogen als de pakketten maar lang genoeg in de queue blijven hangen.

Producten als Packeteer kunnen veel verder gaan. Door technieken als ack pacing, TCP windows aanpassen en dergelijke kun je wel degelijk de hoeveelheid aangeboden verkeer terugdringen. Je kunt de bron applicatie laten denken dat de bandbreedte op is waardoor hij minder verkeer aanbiedt. TCP is namelijk gebouwd om zich dynamisch aan te passen op de aanwezige hoeveelheid bandbreedte. Daarvan kun je gebruik (zo je wilt misbruik) maken om bepaalde verkeersstromen meer bandbreedte te geven dan anderen.

Uiteindelijk zullen mensen minder data uitwisselen als het structureel langzamer gaat.
In de eerste plaats lijkt het me overigens helemaal niet onredelijk dat een protocol dat slechts 5% van het verkeer vormt, ook slechts 5% van de netwerkcapaciteit gebruikt.
P2P is geen protocol op zich hoor, dus ik snap niet helemaal hoe jij aan 5% komt.
Ik vraag me trouwens toch af hoe ze dat verkeer eruit kunnen filteren. Waarschijnlijk wordt er gekeken naar welke poortnummers er gebruikt wordt.
Ik kan me moeilijk voorstellen dat dit in de clausule is opgenomen, waarom zouden ze anders een klacht indienen als ze toch bij voorbaat weten dat het een verloren zaak is? Naar alle waarschijnlijkheid is de situatie of onduidelijk omschreven of helemaal niet omschreven en probeert men via een klacht Bellcast te motiveren om mbv de klacht het knijpen van de lijn tegen te gaan. Ik acht de kans dan ook reŽel aanwezig dat dit een succes wordt maar dat Bellcast vanwege zijn afmetingen het op een langslepende rechtzaak laat komen waar de kleine ISPs geen kans in maken door de kosten. En tegen de tijd dat ze gelijk krijgen over een x aantal jaar krijgen ze misschien hun gelijk maar zijn tegen die tijd de klanten allang naar een andere ISP overgesprongen vanwege het voordeel wat ze eerst hadden neit meer aanwezig is. En bereikt Bellcast uiteindelijk zijn doel het verwerven van klanten die vertrokken waren vanwege het knijpen in de eerste instantie bij Bellcast zelf.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True