Comcast blijkt p2p-verkeer wel structureel te knijpen

De Amerikaanse kabelproviders Comcast en Cox Communications blokkeren zowel in de piek- als daluren stelselmatig Bittorrent-verkeer, zo blijkt uit een onderzoek van het in Duitsland gevestigde Max Planck Institute for Software Systems.

De onderzoekers gebruikten de zelf ontwikkelde Glasnost-tool vanuit 8175 verschillende locaties om het netwerkverkeer in kaart te brengen. Wereldwijd werd slechts bij 7,7 procent van de onderzochte hosts torrentverkeer afgeknepen of geblokkeerd, waarvan 87,8 procent uit de VS afkomstig was. Alle hosts uit de VS die te maken hadden met actieve p2p-throttling bleken op kabelnetwerken te zijn aangesloten, waarbij Comcast en Cox Communications grootaandeelhouder waren in het blokkeren van torrentverkeer.

Uit de gepubliceerde onderzoeksgegevens blijkt verder dat beide isp's zowel in de spitsuren als in de daluren p2p-verbindingen blokkeren. In Nederland en België zijn gedurende het onderzoek, dat liep tussen 18 maart en 15 mei, geen providers gevonden die actief bittorrentverbindingen afknepen.

In een reactie op het Duitse onderzoek stelt Comcast dat het geen p2p-verkeer blokkeert, maar alleen 'netwerkmanagement' toepast om opstoppingen op zijn kabelnetwerk tegen te gaan. Ook zou Comcast actief samenwerken met bedrijven uit de p2p-gemeenschap en werken aan een p2p-richtlijn.

Uit eerder onderzoek van Associated Press blijkt echter dat Comcast uitwisselprotocollen als Bittorrent en Gnutella bewust saboteert door vervalste datapakketjes naar zowel de zender als de ontvanger te versturen, waarin gesuggereerd wordt dat de andere computer de verbinding heeft verbroken. Met de nu vrijgegeven Duitse onderzoeksgegevens blijken de Amerikaanse isp's deze bewust gekozen politiek nog steeds aan te hangen. Inmiddels wordt de p2p-blokkade van Comcast door de FCC onder de loep genomen.

Reacties (29)

[DavidAxe]

I.p.v. het P2P verkeer te knijpen is het verstandiger om netwerk verkeer af te handelen op basis van prioriteit (packet-shaping). Als het p2p verkeer dan als low-prio verkeer wordt gekenmerkt heeft zowel de downloader als de overige gebruikers nergens last van. Op deze manier blijft de gehele netwerk bandbreedte voor p2p verkeer bruikbaar, maar krijgt ander verkeer voorrang. Ik doe dit thuis al jaren (op mijn upstream) en kan zo prima online gamen terwijl er wordt gedownload via bittorrent (uiteraard zijn er op deze schaal dan wel wat zwaardere/complexere systeempjes nodig dan mijn P3-servertje :-)

[kcRogue]

Telenet knijpt in de piekuren ook torrentverkeer af tot ongeveer 60 KB/s. Raar dat dit niet ontdekt is.

[n4m3l355]

Misschien dat dit niet het geval is en dat telenet gebruik maakt van overbevolkte UBRs die tentijde van de spits daadwerkelijk problemen ondervinden. Met name gebruikers die een 20mbit lijn afnemen zullen dit snel ondervinen. Dit heeft echter niets met 'netwerkmanagement' te maken.
Overigens wordt het wel vaker beweert dat ISP´s in NL BT trottelen echter tot op heden is er nooit concreet bewijs tevoorschijn gekomen. En persoonlijk heb ik meer vertrouwen in een onderzoek van het MaxPlanck instituut dan wat eindgebruikers.

Dat terzijde, hopelijk dat de FCC hier toch wel iets aan doet. Amerikaanse ISPs proberen aan alle kanten geld te besparen op toch wel al dure lijnen. Of het nou trottling is of men gaat proberen Google voor traffic te laten betalen, allemaal net zo schandalig imo.

[Niemand_Anders]

Ik denk dat er even een goed onderscheid moet worden gemaakt tussen knijpen (shaping) en packet mangling (TCP RST packet flags terug sturen naar source).

De meeste providers doen aan QoS shaping ofwel http/smtp verkeer krijgt prioriteit ten opzicht van p2p verkeer, maar indien er geen http verkeer is dan p2p de volledige bandbreedte gebruikte. Bij de meeste providers zal voip de hoogste prioriteit krijgen, terwijl p2p de minste. He is de meeste eerlijke manier om de beschikbare bandbreedte te verdelen onder gebruikers.

Echter Comcast doet niet aan shaping shaping zoals hier boven beschreven. Zij sturen bewerkte packets terug naar de source, waarna deze denkt dat er een TCP peer reset is geweest. Op dat moment moet de de source weer opnieuw de TCP handshake uitvoeren met de target. Bij shaping dropped de router enkele packets. Op basis van het fragmentid kan de target achterhalen of deze een packet mist of dat deze in de verkeerde volgorde is aangekomen. Als deze een packet mist, zal de target bij de source opnieuw het betreffende packet opvragen.

[Blokker_1999]

nog nooit meegemaakt.

[analog_]

tadaa let vooral op het klokje.

[Anoniem: 93798]

ja & nee, ik weet van mensen die bij Telenet werken dat er wel afgeknepen wordt maar dit zou niet altijd het geval zijn, enkel wanneer het netwerk te zwaar belast zou zijn

[Reactie gewijzigd door Anoniem: 93798 op 30 juli 2024 04:02]

[MAX3400]

"Het netwerk"?

Ik neem aan de route van een bepaald postcodegebied naar een centraal punt (zoals een backend-switch bij de ISP)? Kan me namelijk niet voorstellen dat iemand die helemaaaaal in het westen woont en heel veel download, dat dan iemand die helemaaaal in het oosten woont daar last van zou hebben (ja, theoretisch wel maar praktisch bijna onmogelijk).

[HyperBart]

[mierenneukermodus]
Als we met een hele groep op dat moment allemaal aan het trekken zijn is dat veel ja, ook al mogen we maar X aantal GB's afhalen, als we ze allemaal binnentrekken, of zelfs nog maar een deel op een piekmoment, kan ik geloven dat he tmoeilijk gaat, iemand heeft hier zelfs een mooie tekst over geschreven over verhoudingen enzo. Zoek het nog wel even op...

[Reactie gewijzigd door HyperBart op 30 juli 2024 04:02]

[DenniZ]

Dat heeft chello ook even geprobeerd, en dus connecten we nu gewoon via SSL

[Reactie gewijzigd door DenniZ op 30 juli 2024 04:02]

[Floor]

Goh, hoezo heeft chello dat ook geprobeerd? Iets meer onderbouwing ipv een lege kreet de wereld in te slingeren.

[dcell]

Chello knijpt in bepaalde gebieden tijdens piekuren het usenet-verkeer over port 119

[n4m3l355]

Chello knijpt niets, tijdens de piekuren is net zoals Telenet de ubr overbevolkt en trekt deze het gewoon niet. Klaag regelmatig bij hun en met een beetje geluk splitsen ze de ubr en dan draait het stukke beter.
Overigens ook SSL verbindingen werken niet. Heden ten dagen zijn routers uitstekend in staat ondanks dat het verkeer zelf ge-encrypt is, aan het gedrag van het verkeer te kunnen zien wat het voorsteld en kan men nog steeds deze bewerken. Indien men dit zou doen, maar zoals ik al aangaf, doet men dit niet. Dit is nooit bewezen en MaxPlanck erkent dit alleen maar.

[Vincent7]

Dat weet ik niet zo zeker.

Soms als ik een torrent op start, dan download de torrent zoals normaal. Maar al het overige verkeer (http. ftp) wordt dan ERNSTIG vertraagd. Ik kan dan niet meer normaal surfen. Zet ik de torrent uit, dan gaat alles weer normaal en kan ik bijv via http ook gewoon snel downloaden. Tijdstip op de dag maakt niet zoveel uit naar ervaring.

Chello Classic + uTorrent

[mashell]

@Vincent7
Trekt je torrent niet gewoon je verbinding vol? Dan heb je niet zo'n goede client want die zou ook moeten weten dat http verkeer gewoon belangrijker is (want daar zit iemand echt op te wachten).

[Reactie gewijzigd door mashell op 30 juli 2024 04:02]

[Anoniem: 229839]

Denk dat je eens naar je instellingen moet kijken. Je kan dit in uTorrent gewoon aangeven.

[roy-t]

Doh, ja dat is op je eigen computer en dat komt omdat uTorrent je netwerk voltrekt en het aantal connecties dat je pc kan leggen volmaakt.

Heeft niets te maken met je provider maar gewoon met het feit dat je je internet opgebruikt door uTorrent.

[blorf]

Niet mijn utorrent of pc maar mijn sweex router klapte er altijd uit bij teveel connecties. De Zyxel die ik nu heb heeft daar geen last meer van. Kwaliteitsprobleem dus.

[Jordi]

Chello UPC internet knijpt niets... Wat raar. Eweka biedt sinds kort ook een SSL news server. Leg mij dan eens even uit hoe het dan kan dat Eweka non-SSL 's avonds instort naar 800kB/s, waar Eweka SSL lekker doordownloadt met 2.9MB/s op datzelfde tijdstip, terwijl niet-UPC klanten ook 's avonds gewoon doordownloaden zonder SSL. Dat is dus niet UPC volgens jou. Knijp ik dat zelf soms?

[graey]

@Home hier, eweka, geen SSL, en savonds/snachts dezelfde hoge snelheden als overdag. Dus wat je zegt lijkt te kloppen, tenzij UPC 's avonds gewoon drukker is en in totaal minder aankan.

[Anoniem: 247804]

Vandaar dat ze het zelf toegeven dat men Usenet verkeer knijpt..............SSL werkt wel degelijk bij UPC , een verschil van 10% bandbreedte hebben in de piekuren over een "normale" verbinding of 100% verbinding hebben over SSL is voor mij bewijs genoeg.....

[DenniZ]

UPC knijpt wel degelijk usenet en torrent verkeer tijdens piekuren. Ik download nu usenet en torrent via SSL en dan gaat het gewoon volle snelheid.

[Spacecowboy]

Prima. Dan gaan we connecten via SSL, en op een andere port. Willen ze daar wat aan doen, dan zullen ze zo ongeveer _al_ het verkeer moeten gaan throttelen.

Overigens snap ik die providers niet. Wel snell verbindigen aanbieden, maar als mensen er daadwerkelijk gebruik van gaan maken, gaan ze moeilijk doen. Of breidt de capaciteit van je netwerk uit, en mekker niet, of biedt gewoon die snelle verbindingen niet aan...

[weeraanmelden]

Even een complete leken vraag;
Als ze bovenop het torrent verkeer, zelf ook nog pakketjes versturen, dan wordt het netwerk toch dubbel belast
En dan hebben ze zichzelf er toch mee ?

[Bloodshot]

Niet helemaal. Comcast stuurt slechts 1 pakketje waarmee de torrent-verkeersstroom gesaboteerd wordt en dus stopt totdat de sessie weer opnieuw wordt opgezet.

[Anoniem: 44812]

Chello zelfde verhaal. Tijdens piekuren usenet 60kb/s, SSL aan en hoppa, 2850kb/s.

[Anoniem: 44812]

Voor de mensen die zeggen dat Chello niet knijpt en met andere wijsneus verhalen komen: Chello knijpt dus 100% wel.