'Toenemend p2p-gebruik maakt tcp-fup noodzakelijk'

Tijdens een bijeenkomst van de IETF in Vancouver heeft een medewerker van British Telecom een voorstel gelanceerd om de beschikbare bandbreedte op internet eerlijker te verdelen.

In de draft, geschreven door onder andere BT-medewerker Bob Briscoe, wordt de huidige verdeling van de bandbreedte nader bekeken en worden enkele ideeën geschetst voor een 'eerlijker' verdeelsleutel. Tcp, een van de basisprotocollen voor datatransport over internet, probeert momenteel al het verkeer zo snel mogelijk te versturen. Wanneer een router door een overvloed aan binnenkomende datapakketjes overbelast raakt, wordt middels het tcp-protocol de snelheid verlaagd. Hierbij wordt elke sessie in min of meer gelijke mate vertraagd, zodat elke deelnemer een 'eerlijk' deel van de beschikbare bandbreedte krijgt toegewezen.

Het probleem zit volgens Briscoe echter in het verschil tussen interactieve applicaties, zoals een webbrowser, en niet interactieve software voor het versturen en ontvangen van grote hoeveelheden data, zoals Bittorrent. Terwijl een gebruiker van een webbrowser slechts zo nu en dan data verstuurt en ontvangt, proberen p2p-programma's juist de beschikbare bandbreedte continu ten volle te benutten. Een torrentapplicatie heeft veertig tot honderd tcp-sessies tegelijkertijd geopend, terwijl een browser niet veel verder komt dan vijf sessies. Een p2p-applicatie genereert niet alleen veel meer dataverkeer, ook bezet deze een veel groter aantal tcp-sessies. Briscoe stelt dat hierdoor de 'eerlijkheid' van het tcp-protocol in de knel komt: een gewone surfer krijgt te weinig bandbreedte toegewezen voor het bekijken van een filmpje in zijn browser, terwijl de downloader comfortabel achterover kan leunen, zo schrijft Ars Technica.

Volgens de Brit heeft het verhogen van de bandbreedte door een isp weinig voordelen voor gebruikers die alleen surfen en hun e-mail lezen: de snelheid van de verbinding stijgt voor hen nauwelijks, terwijl de kosten voor de flat fee-abonnementen door alle gebruikers opgehoest moeten worden. Briscoe stelt zelfs dat snelheidsverhogingen slecht kunnen uitpakken voor een isp, omdat het bedrijven door de gestegen kosten voor dataverkeer minder winstgevend kan maken. Daarnaast blijkt het uiterst lastig en omstreden als een isp probeert het dataverkeer met behulp van deep packet inspection te analyseren en te manipuleren. Onlangs nog werd provider Comcast publiekelijk aan de schandpaal genageld en zelfs aangeklaagd, omdat de isp Bittorrent-verkeer zou afknijpen.

Ondanks de voorstellen van de Brit is het maar de vraag of er ooit aan het tcp-mechanisme gesleuteld gaat worden, om zo p2p-applicaties zich 'netter' te laten gedragen. Grootste struikelblok zou de vraag zijn wat precies een eerlijker verdeelsleutel zou zijn voor een fair use policy voor tcp. Daarnaast zouden weinig eindgebruikers staan te trappelen om hun tcp-instellingen zo aan te passen dat de snelheid in p2p-applicaties drastisch terugloopt.

Reacties (139)

[BartS12]

Hmm, is het wel zo dat een onderscheid maken tussen 'high priority' (=streaming video, websites), en "low priority" (=p2p e.d.) automatisch betekent dat je p2p-downloads veel trager binnenkomen?

P2P maakt kennelijk een groot deel van het totale dataverkeer uit. Dat betekent dat er dus relatief heel weinig 'high priority' verkeer is. Zo af en toe een enkel pakketje 'high priority' er door heen - waar de p2p dan op zou moeten wachten - maak overall toch weinig uit?

Het is net een soort overweg. De auto's mogen bijna altijd gewoon doorrijden, en dat levert nauwelijks hinder op. Een enkele keer moet je die trein effe voorrang verlenen, maar hoeveel later kom je nou op je bestemming aan?

Pas als er relatief veel treinen (=high priority verkeer) zijn, wordt het langzaam vervelend. Zolang het in onbalans is, maakt het toch weinig uit.

[Jaco69]

Nee natuurlijk niet.
Alleen als er ergens een bottleneck is dan is er verschil te merken.

Het high priority verkeer krijgt dan voorang en merkt minder vertraging dan zonder onderschijd.

Omdat het P2P verkeer toch het meest van alle verkeer is merkt het weinig van die paar procent die voorang boven P2P krijgt.

(Zie nu pas dat je je vraag zelf beantwoord )

[RedLizard]

En hoe is het hier beschreven voorstel anders dan het bestaande Type of Service-veld in de IP header? Hierin kan de verzender van een pakket opgeven welk type verkeer het betreft:

Verkeer waarvoor de totale doorvoersnelheid van belang is (p2p), of
Verkeer waarvoor een lage latency van belang is (voip), of
Verkeer waarvoor de betrouwbaarheid van belang is (geen voorbeeld voorhanden).

De provider kan pakketjes prioriteit geven op basis van dit veld, geen deep packet inspection nodig.

[Soultaker]

Het TOS-veld wordt juist wel voor dit soort dingen gebruikt (in de praktijk meestal alleen binnen één administratief domein, maar toch). Het probleem is echter: hoe krijg je een geldige waarde daarin? Dat kun je niet aan de eindgebruiker (de klant van de ISP) overlaten, want die kan het niet (bijna geen enkel besturingssysteem heeft hier out-of-the-box support voor; Windows zeker niet). Als de klant het wel kan, welke reden heeft 'ie dan om zijn eigen traffic vrijwillig een lagere prioriteit te geven?

In de praktijk willen dus alle gebruikers de hoogste prioriteit voor zichzelf en dan werkt het systeem niet meer. Als een ISP verschillende datastromen anders wil behandelen, zullen ze dus zelf de verschillende stromen moeten classifiiceren en daar is die deep packet inspection voor nodig. BitTorrent-traffic is niet op basis van poortnummer of iets dergelijks te identificeren (er worden algemene TCP-verbindingen op willekeurige poorten gebruikt) dus moet je ingewikkelde dingen doen met het parsen van BitTorrent packets en het bijhouden van klassificaties per TCP-stream.

[Olaf van der Spek]

Als de klant het wel kan, welke reden heeft 'ie dan om zijn eigen traffic vrijwillig een lagere prioriteit te geven?

Een datalimiet instellen voor high-priority traffic.

[RedLizard]

(bijna geen enkel besturingssysteem heeft hier out-of-the-box support voor; Windows zeker niet)

Ik weet in ieder geval dat POSIX (en dus praktisch alle unix-achtigen) en Windows er ondersteuning voor hebben. Zoek op setsockopt en IP_TOS.

[Spacecowboy]

In mijn optiek is dit een beetje raar gezeur. Jarenlang hebben providers breedband verbindingen verkocht onder het mom van "supersnel downloaden". Nu heeft iedereen, zoals de providers willen, een 8Mbit verbinding, en komen ze er opeens achter dat mensen (te?) veel downloaden. Wat hadden ze dan verwacht? Iedereen neemt 8Mbit af om af en toe te mailen ofzo? Kom op, ik neem het om gewoon zo snel mogelijk data heen en weer te kunnen pompen. Als providers weten dat ze de bandbreedte eigenlijk niet kunnen garanderen, waarom bieden ze dan die diensten aan? Zet dan gewoon iedereen op de snelheid die daadwerkelijk door het netwerk gehaald kan worden.

[yiNXs]

Ik kan het wel begrijpen. Als je als provider zo'n snelle verbinding biedt, dan is het in principe bedoeld voor als je eens lekker snel een filmpje of een game wil binnen halen. Maar je hebt nou eenmaal ook van die dwangmatige verzamelaars die bang zijn dat ze iets zullen missen en terrabytes per maand binnenslepen aan een doorlopende stroom data, of ze er nou wat mee doen of niet. De meeste providers hebben nou eenmaal een fair-use policy. Continu downloaden op hoge snelheid is bij een fair-use policy dus volgens de regel asociaal bandbreedte gebruik. Als gamer vind ik het een beetje zonde dat ik met een slechte latency moet zitten omdat een grote groep downloaders een oncontroleerbare verzameldwang hebben. Ik deel daarom dus zeker ze mening/zorgen van de ISP's. Er mag best een prioriteiten systeem / QoS gebruikt worden wat mij betreft. Fair use = Fair use.

[Spacecowboy]

Feitenlijk hebben de providers dus minder bandbreedte dan dat ze verkopen (overboeking). Prima dat ze dat doen, maar ga mij dan niet opzadelen met het gezeur. Verdeel dan gewoon de daadwerkelijk aanwezige bandbreedte, en geef iedereen 2Mbit, of wat er dan ook aanwezig is...

[sirono]

we hebben het helemaal niet over het afknijpen van bt.
het gaat primair om het versnellen van ander verkeer zodat je lekker snel kunt browsen

laten we wel wezen, 2 uur meer of minder bij je p2pdownload merk je nauwelijks.
maar 10 seconden langer wachten op een website merk je wel en erger je je aan!

[3DDude]

helemaal wel als ik volle bak kan downloaden is die dvd namelijk met anderhalf a 2 uur binnen en kan mijn computer 2 uur eerder uit das toch wel stroombesparing

[barfieldmv]

Maar als je daardoor een paar honderd mensen 10 secondes laat wachten op hun pages is de stroom besparing negatief maw iedereen is gebaad bij sneller internet en niemand wil zijn verbinding knijpen

[iKiddo]

Dit is gedoemd om te mislukken. Stel je hebt een flag in het pakket die aangeeft of het een interactief pakketje is of niet. Dan gaat iedereen voor alle pakketten die flag aanzetten, omdat het internet op alle aspecten sneller gaat lopen...

Volgens de Brit heeft het verhogen van de bandbreedte door een isp weinig voordelen voor gebruikers die alleen surfen en hun e-mail lezen: de snelheid van de verbinding stijgt voor hen nauwelijks

Wat een flut redenering. Het argument tegen dit soort maatregelen is niet om de bandbreedte van je abbo te verhogen, maar de bandbreedte van de ISP. Als de ISP genoeg bandbreedte heeft voor al zijn klanten, zal er zich nooit een situatie hoeven voordoen waar pakketjes voorrang nodig hebben.

[Reactie gewijzigd door iKiddo op 26 juli 2024 10:15]

[AndrewF]

Volgens mij bestaat hier al een oplossing voor: Quality of Service (QoS)

Quality of Service can provide different priority to different users or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program or the internet service provider policy. Quality of Service guarantees are important if the network capacity is limited, especially for real-time streaming multimedia applications, for example voice over IP and IP-TV, since these often require fixed bit rate and are delay sensitive.

Enkele jaren geleden keek ik al naar QoS om te gebruik op het thuis netwerk.

[Reactie gewijzigd door AndrewF op 26 juli 2024 10:15]

[Verwijderd]

Het probleem is niet dat QoS mogelijk is, maar dat het niet correct gebruikt wordt (of zal worden). De problematiek rond Comcast geeft aan dat gebruikers niet willen dat de provider zich met QoS bemoeit, maar tegelijk kan dit niet bij gebruikers zelf neergelegd worden omdat daar altijd mensen (of applicaties!) tussen zitten die zichzelf zoveel mogelijk bandbreedte toeeigenen.

Genoeg bandbreedte in de backbone lijkt een makkelijke oplossing, maar als je er van uit gaat dat standaard netwerkverbindingen voor consumenten een overboeking van 1:25 hebben, betekent dit dat alle backbone netwerken met een factor 25 opgeschaald moeten worden (bovenop de normale 'groei' van snelheden) en daarmee zal de prijs van een internet abonnement ook fors stijgen - wat consumenten ook niet willen accepteren.

Het is net een slecht gemanaged software ontwikkelproject waarbij er geen features overboord gekieperd mogen worden, geen extra geld en resources beschikbaar zijn, en de einddatum ook niet verschoven mag worden.

Het lijkt mij dat er een nieuwe vorm van netiquette moet komen op basis waarvan de providers de bandbreedte op een nette manier tussen gebruikers kunnen verdelen.

[Bloodshot]

Ik denk dat je daar fout zit: Ik als gebruiker vind gewoon dat mijn browsen redelijk vloeiend moet gaan, mijn emails niet tergend langzaam verzondern worden (maar een seconde meer of minder boeit niet), mijn VOIP zeer vloeiend gaat en of mijn downloads er een procent of 10, 20 of 30 langer over doen boeit me echt niet.

Het gaat hier om de gebruikerservaring.

Ik vind het een zeer nobel streven om dit op groot internationaal niveau (zoals dus op IETF-level) aan te pakken.

Als de BT-softwareschrijvers er dan ook nog rekening mee houden (JA: veel bandbreedte gebruiken, maar ALLEEN als het er is!) gaat het allemaal wel goed komen. Of dit nu op eindgebruikersniveau wordt toegepast of op ISP-niveau is voor mij minder spannend.

[i-chat]

als er in de netiquete dan maar gegarandeerd wordt dat er alleen geknepen mag worden wanneer dit ook nodig is...

en dat de data die ge-analiseerd wordt onlogbaar en onherken baar moet zijn...

[Jaco69]

Als applicaties zich zoveel mogelijk bandbreedte willen toeeigenen moeten ze dat vooral doen, dat geeft geen probleem voor QoS.
QoS zorgt er juist voor dat de applicaties die maar een bepaalde bandbreedte nodig hebben maar dit zeer constant en met weinig jitter en vertraging dit kunnen reserveren.

Als een background mode applicatie krijg alle beschikbare bandbreedte maar andere (interactive en streaming) krijgen voorang.

Als de bandbreedte voor een streaming applicatie niet beschikbaar is dan start tie niet op (network bussy) dus voor een torrent om zich voor te doen als streaming heeft geen zin.

Kortom als je een andere QoS opgeeft dan wat je nodig heeft dan snij je jezelf.

[Verwijderd]

Zo werkt dat niet: als de bandbreedte voor een streaming app niet aanwezig is start hij wel op maar wordt je beeld- of geluidskwaliteit slechter.

[Tijger]

QoS vereist dat alle participanten in een netwerk er gebruik van maken, een ISP kan alleen het stukje tussen zijn 'internet gateway' en de eindgebruiker garanderen en er zijn geen QoS overeenkomsten tussen ISP's onderling of ISP's en carriers.

Dus ja, QoS kan het wel maar valt en staat bij wereldwijd verbond tussen ISP's die dan ook allemaal dezelfde QoS regels moeten hanteren.

[Verwijderd]

Ik ben op dit moment bezig met prioritering en shaping van datastromen op ons eigen netwerk met Zeroshell

Zeroshell is een linuxdistro (in principe een live-cd, maar via het eveneens beschikbare compactflash image, ook te installeren op een harddisk) die uitgebreide mogelijkheden heeft voor diverse netwerktaken (DHCP, DNS, VPN, Captive Portal, RADIUS en nog een paar meer waaronder QoS, zowel shaping als prioritering van datastromen...)

Daarnaast is het via een webinterface een zeer eenvoudig te beheren omgeving waarop zelf verder geen x-server draait.

De distro wordt actief ontwikkeld en er is een entousiaste en groeiende community eromheen aan het vormen.

Wat mij betreft een aanrader om eens naar te kijken.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 10:15]

[The Zep Man]

Dit is gedoemd om te mislukken. Stel je hebt een flag in het pakket die aangeeft of het een interactief pakketje is of niet. Dan gaat iedereen voor alle pakketten die flag aanzetten, omdat het internet op alle aspecten sneller gaat lopen...

Waarom makkelijk doen als het ook moeilijk kan?

Hoewel het iets meer moeite kost, is het heus wel mogelijk om BitTorrent (of elk ander op TCP gebaseerd protocol) uiteindelijk compleet met UDP aan de praat te krijgen. Integriteitscontrole verplaats je daarmee naar het applicatie-niveau. UDP pakketten gaan ze echt niet vertragen omdat ook die gebruikt worden voor voice/video-chat. Ook is er geen sessie die ze kunstmatig langzamer kunnen maken.

Voeg ook nog eens een goede encryptie verplicht eraan toe. Het is een nieuw protocol, dus dat moet wel erin te bakken zijn. Vervolgens kunnen ISP's helemaal niet meer zien om wat voor pakketten het gaan en het reguleren wordt ook een stuk moeilijker.

Even voor de duidelijkheid: dit is nu al mogelijk. OpenVPN kan tunnels aanmaken over UDP en heeft integriteitscontrole ingebouwd. Als je door zo'n tunnel TCP pakketten schiet, kan er vanaf de buitenkant totaal niet gezien worden om wat voor pakket het gaat (geen sessienummers, geen identificatie... niks).

[Reactie gewijzigd door The Zep Man op 26 juli 2024 10:15]

[Carpento]

TCP pakketten versturen over UDP is wel een work-around maar een oplossing van het probleem is het zeker niet. In dit artikel wordt gefocussed op TCP, inderdaad zoals gesteld één van de basisprotocollen van het internet. Het andere is UDP, en juist bij dat protocol vindt een excessieve stijging plaats van verkeer. Streaming video en streaming audio zijn een uitstekend voorbeeld van capaciteitvretende UDP-toepassingen.

Nu TCP in de knel komt moet er zonodig binnen het TCP protocol een oplossing gezocht worden. Nobel, maar ik denk dat het werkelijke probleem breder ligt, en wel bij UDP. Waar TCP nog bijgestuurd wordt als er drukte is op het net doet UDP dat niet. Bij TCP wordt de kraan dichtgedraaid als de afvoer (of doorvoer) het niet aankan. UDP kiept simpelweg een emmer pakketjes de lijn op, en als de lijn overstroomt en dingen verloren gaan: so be it. Dat is ook precies de bedoeling van die protocollen maar tegenwoordig blijkt dat de gewenste capaciteit zo snel stijgt dat er wel degelijk rekening met elkaar gehouden moet worden.

Verschuiven van TCP naar UDP 'omdat dat tenminste niet geremd wordt' is dan niet bepaald een fraaie oplossing. Daarmee zaag je juist aan één van de fundamenten van het internet.

[Reactie gewijzigd door Carpento op 26 juli 2024 10:15]

[Zyppora]

Ik vind het gebruik van UDP voor het bittorrent (of vergelijkbaar) protocol juist een mooie oplossing. TCP hoort eigenlijk alleen gebruikt te worden als, zoals al gezegd wordt, integriteitscontrole toegepast moet worden. Dit levert een bepaalde overhead op in het IP pakket, maar garandeert dat er een check gedaan wordt. Bij dingen zoals browsen en chatten is dat redelijk te verwachten.

Bij torrents is dat echter niet zo. De integriteitscontrole hoeft eigenlijk pas uitgevoerd te worden als de client zegt: nu heb ik de volledige torrent binnen. Mis is misschien nog ergens een deel? Stuur maar een nieuwe (UDP) aanvraag en kijk maar of er nog wat binnenkomt. Dat kan heel makkelijk en bandbreedte-vriendelijk met een simpele checksum. Natuurlijk verbruik je dan meer, omdat in het voorbeeld het totale aantal pakketten verdubbelt, maar dat wordt netjes gesmeerd over een langere periode en de 'ultra-fast-on-demand' applicaties zullen daardoor niet gehinderd worden.

Veel mensen doen wat anders (browsen/tv kijken/spel spelen/devven/naar het werk/stad/vrienden/familie/etc) en laten de torrent op de achtergrond lopen. Als dat via UDP loopt, en de helft van de pakketten valt weg, en het duurt dus twee keer zo lang, geeft dat in principe niet. Het is altijd lekkerder om een torrent met een poep en een scheet binnen te hebben, maar gemiddeld genomen is en blijft het een background process, en juist daarvoor is UDP geschikt.

[Reactie gewijzigd door Zyppora op 26 juli 2024 10:15]

[Jaco69]

Dus alles traag wat lost dat op?

De oplossing is het implementeren van QoS. Elke stream heeft dan gegevens over wat belangrijk is, bandbreedte of snelheid in reactie.
Op die manier kan je bandbreedte reserveren voor een video sessie bijvoorbeeld.
Voor bittorent kan er eens een paketje weggegooit worden ten behoeve van browsing of streaming daar merkt de torent niks van.

Als zo'n systeeem ooit nog eens geimplementeerd word en het wordt gesaboteerd door torents die een video stream aanvragen dan is de volgende stap om streaming, browsing en background verkeer verschillende prijzen te geven. Dus beter saboteer je niet.

[Verwijderd]

Als je aan verschillende prijzen begint gooi je dus de flatfee abo's overboord. Volgens mij is zo'n abonnement in elk geval in Nederland onverkoopbaar in de huidige markt.

[Armada651]

Veel BT clients ondersteunen al encryptie over alle verstuurde data pakketen. Je hoeft het alleen maar even aan te vinken.

[chrisO]

En het nut daarvan is? encryptie zorgt er enkel en alleen voor dat de inhoud van het pakketje (wat je via bittorrent verstuurt/ontvangt) encrypted is. Dat het gaat om een bittorrent protocol pakketje is niet encrypted!

[Klaus_1250]

BitTorrent encryptie is puur en alleen om te maskeren dat het om BitTorrent traffic gaat (alhoewel het geen waterdicht systeem is). Daarvoor is het ook ontworpen, het is niet ontworpen voor veiligheid/privacy/....

[HarmoniousVibe]

Die encryptie vindt plaats in de applicatielaag en niet in de transportlaag (e.g. tcp, udp). Met andere woorden, de headers die de transportlaag aan het pakketje toevoegt (waarin die flag zou moeten komen) worden niet geëncrypt. Dat heeft dus totaal geen zin.

[Mathijs]

Maar dat is nu juist het probleem daar. Die ISP's hebben niet genoeg bandbreedte.
Ik heb vaak zat verhalen gehoord over hoe de snelheid daar inkakt 's avonds van mensen die daar wonen.
En dit is natuurlijk ook weer een totaal verkeerde insteek om aan een oplossing te werken, zorgen dat de bottleneck verdwijnt zou natuurlijk veel structureler zijn.

[mjtdevries]

Dan heb je dus totaal niet begrepen waar het om gaat.

Gewoon bergen bandbreedte kopen is de makkelijkste en domste oplossing.
Het kost namelijk bergen geld, die de ISP weer moet verhalen op de klant.
Het abonnement wordt duurder, terwijl de normale gebruiker geen verbetering ondervind en alleen de zware P2P gebruikers baat hebben. Dat is dus niet wenselijk.

Terwijl je de boel ook veel goedkoper, beter en structureler zou kunnen oplossen als de P2P verkeer wat lagere prioriteit zou hebben.
Dan kan je voor dezelfde kosten aan bandbreedte de normale gebruikers een betere experience geven (browsen gaat sneller) terwijl het ook voor het meerendeel van de P2P gebruikers nog heel acceptabel blijft. Dat is dus voor een ISP een veel betere oplossing.

[Olaf van der Spek]

Dan gaat iedereen voor alle pakketten die flag aanzetten, omdat het internet op alle aspecten sneller gaat lopen...

Dat kun je natuurlijk combineren met een datalimiet voor packets met de vlag. Ga je over de limiet heen, dan wordt de vlag automatisch gedropped.

[Bacchus]

.. Of beter nog: Gewoon knijpen, om te browsen heb je aan iets van 50KB/s of 100KB/s al wel genoeg. Of een combinatie misschien.

[Spacecowboy]

Knijpen? Dus mij wordt een 8Mbit abbo aangeboden, maar ik mag die snelheid niet gebruiken? Hou eens gauw op.

[Olaf van der Spek]

Knijpen? Daar wordt de consument natuurlijk echt niet vrolijk van.
Bovendien, het is toch een internetabo en geen browseabo?

[i-chat]

nee maar 't is wel een FAIR USE abo.. dus iedereen moet met een acceptabele snelheid kunne internetten, dus niet direct een race om de meeste tcp- requests...

[Rex]

FAIR USE moet wel wederzijds zijn! Als de ISP's 20 mbit leveren en dan hun klanten niet tegelijk gebruik kunnen laten maken van hun bandbreedte, dan moeten ze óf meer bandbreedte inkopen of de snelheid van alle klanten verlagen.

[L-VIS]

Hij zegt toch precies hetzelfde?

Maar dat is toch geen reden om er niks aan te doen. Ik zelf vind dat hij wel een punt heeft. E-mail en surfen zou hoger in de pikorde moeten staan dan p2p downloads. Ik denk dat Voip misschien daarboven nog komt.

Vergelijk het maar met het snelwegennet van NL. We kunnen als een gek wegen aanleggen, wat nu niet meer rendabel lijkt te worden. Of we kunnen verkeer spreiden over dagdelen en delen van de week om de capaciteit opitmaal te benutten.

Goed initiatief IMO om de discussie hierover aan te gaan!

[Verwijderd]

De downloader moet maar 's nachts z'n downloads aanzetten, dan is er toch geen hond die aan het emailen is of op youtube zit, binnen een bepaald gebied dan. Dan heeft niemand last van het downloaden. En volgens mij gaat het ook nu al vaak zo, dus hoezo is het nodig om downloaders af te knijpen en mailers voorrang te geven. Alsof een mailtje van hooguit enkele mb's binnen 1 seconde bij Pietje moet zijn...
Of Hans de spammer, die moet wel altijd kunnen mailen, die heeft er baat bij als ie duizenden mailtjes per minuut kan versturen

[i-chat]

toch vind ik dat je hier onrecht doet aan 't idee van internet ...

als ik internet normaal gebruik, en daarmee dus weinig resources verbruik... en altijd ruim onder de FUP limiet zit... moet ik dan maar bij elke site die ik bezoek een minuut moete wachten voor ie geladen is omdat jan de buurman lekker also met 9mbps porn zit te downloaden.

ik denk dat bepaalde P2P verkeer best geknepen mag worden. hoewel ik er wel voorstander van ben om dat zo min mogelijk te doen, bijv alleen tijdens de internet spits..

dan denk ik bijv aan een systeem waarbij 't wellicht zelfs per dag deel moet kunne verschillen... ik neem maar wat...

van 7 sochtends tot 4 smiddags mag 1/2 deel uit p2p bestaan... van 7 tot 1 maar 1/3 en van 1 tot 7 1/1

want eigenlijk is 't raar dat BT apps je te gebruiken data wel voor JOUW broser-sessies wil beperken maar niet voor die van je buurman...

[LessRam]

En wanneer is het dan nacht voor "de downloader" ????

[Ge Someone]

Ook als jij slaapt is het ergens anders gewoon dag. P2P is niet persé regionaal.

[Bor]

Je kunt het natuurlijk ook zo maken dat een router / centraal systeem deze flag toevoegd aan bepaalde datastromen na analyse hiervan zodat een eindgebruiker hier geen invloed op heeft.

[elleP]

Maar dan ben je weer terug bij 'deep packet inspection' wat extra vertraging oplevert, en duur is.

[martijnvanegdom]

nee want voor een ISP is het makkellijk te zien of jij dat gedaan hebt.. en dan gewoon evil de lijn blokken.. foei jongentje je mag niet met flags spelen

[Verwijderd]

Tja... de vraag in deze is inderdaad: wat is eerlijk? Ik kan me voorstellen dat de ISP wat willen doen aan het uit de klauwen gelopen p2p bandbreedtegebruik, maar daar staat tegenover dat de p2p-gebruikers net zo goed betalen voor hun bandbreedte.

Een beter systeem zou volgens mij zijn: gewoon de kosten per maand variabel maken, afhankelijk van de hoeveelheid bandbreedte die gebruikt is. Zo betalen de grootverbruikers meer, en de gewone internettertjes minder. Eerlijk toch? Bovendien lijkt een aanpassing van het tcp-protocol mij een hoop geld en tijd kosten, wat dus eigenlijk niet nodig is. Bovendien beperkt zo'n aanpassing mensen in hun vrijheid om te doen wat ze willen, en dat lijkt me toch ook niet de bedoeling lijkt me.

Gewoon mensen laten betalen naarmate ze meer vereisen van hun internetverbinding.

[Beun de Haas]

Helaas gaat niemand dat accepteren. Kijk maar eens naar de reacties als het over een Belgische provider gaat. Wat jij voorstelt heet volgens mij namelijk gewoon "data limiet".

[i-chat]

en dat is idd prcies NIET wat er hier ook wordt voorgesteld,

de bedoeling van deze man lijken me meer gericht op 't al dan niet tijdelijk (bepaalde dagdelen) knijpen van verbindings-snelheden... eigenlijk is dat helemaal niet zo raar 't enige is dat 'wel eerlijk moet zijn.. -

maar eigenlijk zouden ze dan om 't eerlijk te maken snachts gewoon de hele cab van je verbinding af moete halen... bijv tusse 2 en 5 snachts gewoon de sneheid vrijgeven...

[Jaco69]

Hij wil niet knijpen maar de hele snelheid van de backbone gebruiken, maar dan verkeer dat interactief is voorang geven.

In dat geval kan je de backbone veel hoger belasten zonder dat je met browsen merkt dat het trager wordt.

Als al het verkeer gelijk behandeld wordt dan merk je met 50% belasting al vertraging.

Dus het torrent verkeer loopt nog steeds ongeveer even snel maar het browsing en streaming verkeer neemt de spitsstrook en vliegt voorbij.

[X-Stuff]

Op dit moment betaald iedereen al naar gelang hij/zij bandbreedte inkoopt.

20mbit is duurder dan 1mbit, datavekeer is de hoeveelheid en niet de breedte.

[ATS]

Maar bandbreedte is iets anders dan waar het hier over gaat. Ik wil graag met zeer hoge bandbreedte kunnen mailen en surfen en video-converstaties doen. Dat zijn maar heel weinig verbindingen, waar ik wel graag veel data overheen wil trekken. Torrents (en andere P2P systemen) leggen juist heel veel verbindingen tegelijk. Als er nu bandbreedte verdeeld moet worden, en dat gebeurd op basis van "elke TCP verbinding even veel", dan wordt P2P dus enorm bevoordeeld over mijn mail, browse of voip verkeer. Dáár gaat het hier over.
Zou het niet helpen om op drukke momenten het aantal TCP toegestane verbindingen per internetaansluiting gewoon te knijpen? Met gewone applicaties heb je daar geen last van, die gebruiken er niet zo veel, maar torrents worden wel beperkt. Dit kan zonder dat je de packets op zich hoeft te inspecteren.

[DutchStoner]

"Een beter systeem zou volgens mij zijn: gewoon de kosten per maand variabel maken, afhankelijk van de hoeveelheid bandbreedte die gebruikt is."

Dan moeten we straks een internet abbo afnemen met bv een 100 Gb bel, databundel en 500 sms emailtjes... BAH! Het flat fee model heeft het internet veel goeds gedaan, ik zie niet waarom we terug in de tijd moeten.

[Reactie gewijzigd door DutchStoner op 26 juli 2024 10:15]

[Verwijderd]

lol... kom naar de zuiderburen... het is er prachtig wonen en je krijgt de databundels er NIET GRATIS bij...
(/me woont inmiddels 4 jaar bij de zuiderburen en verbaast zich nog steeds dat er geen ECHTE nationale opstand is tegen de 2 internetgrootmachten)

[Reactie gewijzigd door Verwijderd op 26 juli 2024 10:15]

[DutchStoner]

Ik vraag me wel eens af waarom daar geen 'gezonde' marktwerking plaatsvind. Een provider zonder datalimiet zal denk ik al snel een commercieel succes zijn in Belgie... Of mis ik iets?

[FabianNL]

Ik denk dat je mist, dat de mensen die zouden overstappen naar zo'n flat-free alleen maar extreme downloaders zijn. De 'normale' internetter hoeft er niet direct perse naar over te stappen, alleen mensen die veel willen downloaden. Die provider krijgt dus alleen de groot verbruikers en zal niet snel rendabel worden.

Dus de 2 grote ISP moeten gewoon samen over stappen op flat-free anders wordt het niks.

(Ik heb eigenlijk geen idee meer hoe het precies in NL is verlopen)

[barfieldmv]

Het was al snel fair use met een paar bedrijven die daar te weinig aan doen. Toen het downloaden eenmaal uit de klauwen liep was het bedrijfsleven al te laat om terug te gaan naar euro's per GB.

[Rex]

Ik denk dat normale internetters ook zouden willen overstappen. De garantie dat je nooit teveel betaald is zo'n grote pluspunt dat ik dat liever zou hebben.

[ATS]

@ReFleXWolf:
Nou, ik zou best terug willen stappen naar een abbo waarbij er wel limieten aan de hoeveelheid data zijn, als dat betekent dat ik minder ga betalen en/of een hogere bandbreedte krijg voor dingen die ik wél gebruik.

[Reactie gewijzigd door ATS op 26 juli 2024 10:15]

[erwinb]

Ik zie er we voordeel in om af te rekenen mer verzonden e-mail. Dan heeft het spannen ook zijn langste tijd gehad.
(Oké, als mij pc door een bot wordt overgenomen moet daar wel wat voor te verzinnen zijn.
Bij het internet abbo. zitten 1000 e-mails per maand, maximaal 10 per uur, zou voor mij goed zijn maar een spambot heeft daar niet echt veel aan)

[Verwijderd]

Ja, daar is wel wat voor te verzinnen: omdat je zelf dat voorstel doet mag je dan voor al die miljoenen mails dokken. Dan leer je het wel af om dit soort voorstellen te doen.

Het lijkt gvd wel rekeningrijden, alleen kan ik daar niet minderen en qua p2p gebruik wel: ik moet toch op m'n werk komen. Dus de kosten gaan of voor mij (in dat geval gaat de baas het bij de salarisronde horen) of voor de baas omhoog. Ik rij er geen km minder om.

[LessRam]

Lullig als je dood gegooit wordt met spam......

[Olaf van der Spek]

Toenemend p2p-gebruik maakt tcp-fup noodzakelijk

Ik dacht, nu komt het, mooi, iemand heeft een oplossing bedacht.
Maar nee hoor, slechts een erkenning van het probleem.

Zouden ISPs geen BT/download proxy kunnen draaien, in ieder geval voor legale content?
Een per-ISP tracker om snel lokale peers te vinden zou ook erg handig zijn. Als bijvoorbeeld een kabel-ISP dan ook de upstream verhoogt voor packets die binnen de ISP blijven zou dat al een hoop schelen denk ik.

[Reactie gewijzigd door Olaf van der Spek op 26 juli 2024 10:15]

[Verwijderd]

Wat heeft het lokaal afhandelen van die paar legale downloads nou voor zin? Dat is maar een fractie van het totale verkeer.

[Dennizz]

Ik ben principieel tegen het onderscheiden van verkeersstromen, maar zie wel in dat er een probleem ontstaat. Wat ik echter niet goed vind is dat ze het op willen lossen door p2p omlaag te brengen. Mijn inziens kun je beter verkeer gaan kleuren (QoS) met dscp waardes en dan binnen je netwerk prioritiseren. Je hebt dan zelfs met mpls "the magic traffic engineering carpet" de mogelijkheid om verschillend gekleurd verkeer in verschillende banen te lijden. Zo kun je bijvoorbeeld een "gold" path in je isp netwerk hebben waar alle http verkeer overheen gaat en een "best-effort" path waar peer to peer overheen gaat...

Lijkt mij een mooiere oplossing, hierdoor ga je niet p2p letterlijk knijpen, maar http (etc) anders routeren of prioritiseren zodat het in hogere queues komt op network devices.

[DieterVDW]

QoS iemand ...?
http://en.wikipedia.org/wiki/Quality_of_service

Ik snap het probleem niet. QoS is net hiervoor gemaakt.
De technologie om dit probleem op te lossen is er al...
Ik kan me moeilijk voor stellen dat Mr. Briscoe nog nooit van QoS gehoord heeft?

[Reactie gewijzigd door DieterVDW op 26 juli 2024 10:15]

[Jaco69]

Bestaat nog niet voor IP.

DiffServ komt het dichts in de buurt maar dat is alleen het prioritizing gedeelte van QoS.

[Olaf van der Spek]

Inderdaad. Maar ik heb een behoorlijk goed modem, maar packets taggen zodat ze in een low priority queue terecht komen op de router kan volgens mij niet eens.

[DieterVDW]

Het lijkt me toch niet zo moeilijk om gewoon wat QoS regels in te stellen zodat poort 80 traffiek (ea) prioriteit krijgt over 'unknown' bulk traffiek.

Het lijkt me ook niet de verantwoordelijkheid van de gebruiker om zijn data te taggen.
Leechers zullen dit toch sowieso niet doen.

[Reactie gewijzigd door DieterVDW op 26 juli 2024 10:15]

[Azzmodan]

Het zou alleen de gebruiker moeten zijn. Jij wilt zelf aangeven wat voor jou belangrijk is en de provider heb je er voor om zo snel mogenlijk paketje A naar locatie B te krijgen.

Zeggen dat bepaald verkeer altijd minder belangrijk is is ook niet altijd waar, kijk naar skype voor p2p audio of wow patches waar de wow spelers toch echt met smart op wachten maar die zijn eigenlijk gewoon bittorrent verkeer.

[mjtdevries]

Nee, juist niet de gebruiker.

Het zijn immers juist die gebruikers die vinden dat AL hun verkeer belangrijker is, dan het verkeer van hun buurman. (met name de leechers)

Dus moet dit juist op ISP nivo geregeld worden om het voor alle gebruikers eerlijk te houden.

[Olaf van der Spek]

Behalve HTTP wil ik al het verkeer (behalve BT) een hogere prioriteit geven. Dus ook email, games, AV streams, etc.

Het lijkt me ook niet de verantwoordelijkheid van de gebruiker om zijn data te taggen.
Leechers zullen dit toch sowieso niet doen.

Op een private/thuisnetwerk kan tagging toch prima?

[Reactie gewijzigd door Olaf van der Spek op 26 juli 2024 10:15]

[Jaco69]

Waarom email? email is toch gewoon background trafic (net als BT)

3 prioriteiten, background, interactive en streaming zijn volgens mij wel genoeg.
Het zou helemaal fijn zijn als je voor streaming gegarandeerde bandbreedte kon reserveren voor de duur van het filmpje. (desnoods voor een centje meer)

[Verwijderd]

Sterker nog... de technologie is er al 30 jaar. De standaardisatie ontbreekt.

[FluoDude]

Het probleem is gewoon dat overboeking , normaal is in ISP land. De bandbreedte waar je voor betaald kan gewoon niet altijd op maximum staan. Moest dit wel kunnen dat zou dit probleem zich nooit voordoen , tenzij je zelf lokaat P2P draait.
Stel je voor dat als je de telefoon opneemt om te bellen dat een dame je vriendelijk vertelt nog 2 minuten te wachten alvorens het nummer te draaien want de lijnen zijn nog even bezet.

[Olaf van der Spek]

Stel je voor dat als je de telefoon opneemt om te bellen dat een dame je vriendelijk vertelt nog 2 minuten te wachten alvorens het nummer te draaien want de lijnen zijn nog even bezet.

Nog nooit geprobeerd tijdens oud en nieuw?