UPC / Chello knijpt dataverkeer nieuwsservers [deel 2]

Hier is het de laatste tijd ook hopeloos om 's avonds te downloaden via de nieuwsgroepen, soms valt de verbinding helemaal weg en krijg ik alleen maar time out's. Helaas heeft mijn usenetprovider (newshosting) geen SSL op mijn abonnement, dus dat kan ik ook niet aanzetten. Hopelijk gaat dit snel veranderen, want zo is het geen pretje...

Koekiemonster zei:

Zal vast. Dat zal ook de reden zijn dat iedereen hier via SSL wel de volle snelheid behaalt.....Maar goed...Ik ben beroepsmatig bezig geweest met apparatuur die dit doet. En weet van de leverancier aan wie ze dat nog meer hebben verkocht. En die apparatuur/software shaped niet op poort niveau, maar op pakket niveau. Het kijkt naar protocollen en niet naar poorten.

Klik om te vergroten...

Ik heb geen idee welke software, lijkt me overigens simpeler dan op pakketniveau,
simpele bandwith limiter op port, de http-poorten vrij laten, voilla, makkelijk dan met
24/60/120 de packets te analiseren en dan te laten beslissen of ze wel of niet op
volle snelheid mogen, protocollen zijn tegenwoordig niet meer relevant, als jij
beweert dat ze ssl niet shapen (shapen? knijpen lijkt me een beter woord) dan kunnen
ze nagenoeg geen winst halen uit het knijpen omdat tegenwoordig iedere client van
newsreaders tot aan torrentclients volgens mij ssl aan kunnen... wat dus inhoud dat
je voornamelijk de mensen zou treffen die 24/7 full throttle binnentrekken


Ik weet van mensen dat ze niet altijd de volle snelheid halen met ssl, lijkt me dus dat
UPC niet op packet knijpt.. die wikipediazooi lees ik wel als ik tijd heb, ben meer ge-
intreseerd naar het bedrijfje waar je over praat en de apparatuur zelf..

Als je via ssl download kan upc niet zien wat je aan het doen bent , dus met ssl moet je altijd sneller kunnen downloaden anders ligt het probleem ergens anders dan bij upc

Jappie_23 zei:

Als je via ssl download kan upc niet zien wat je aan het doen bent , dus met ssl moet je altijd sneller kunnen downloaden anders ligt het probleem ergens anders dan bij upc

Klik om te vergroten...

En u hebt deze wijsheid vergaard... hoe? waar?
Welke wiki-ik-vind-het-de-waarheid-omdat-iedereen-het-zegt heb je opengetrokken?

jazzpr zei:

En u hebt deze wijsheid vergaard... hoe? waar?
Welke wiki-ik-vind-het-de-waarheid-omdat-iedereen-het-zegt heb je opengetrokken?

Klik om te vergroten...

Nou ik zal maar dan wel gewoon normaal reageren

Ik ken iemand die bij upc werkt en dit ook aangeeft !!!

Ik met ssl verbinding een uitstekende download snelheid heb

Nou dat was het wat ik noh wou zeggen wou gewoon even ergens op reageren maar merk wel dat jij alles beter weet

Ik heb gesproken

Jappie_23 zei:

Ik heb gesproken

Klik om te vergroten...

Oh, het is dat je het zegt, anders had ik het niet durven herkennen... 

Nee, maar je zegt wat, wat wij als kennis dienen aan te nemen. Althans, je brengt het als een feit...
Dan vraag ik me af, hoe je aan deze kennis komt. Als je ook maar iets van zaken als SSL-encryptie weet, weet je ook dat wat je zegt, geen echte kennis is maar giswerk. Dat je dit van iemand van UPC weet, maakt het nog geen waarheid.

En ja, UPC heeft een heleboel nitwits in dienst; ze heeft haar afdeling 'klantenservice' er vol mee gekregen.  :'(

De persoon wat ik heb zit niet op de hd maar dat niet ter discussie .

Als ik niets van ssl weet ga ik het hier natuurlijk niet neerzetten .

Kijk en dit is wat ik zelf ervaar en van iemand weet dus daaromwou ik het even vermelden

Je hoeft me niet te geloven , maar ik weet dat het zo is .

Mango zei:

Ik heb geen idee welke software, lijkt me overigens simpeler dan op pakketniveau,
simpele bandwith limiter op port, de http-poorten vrij laten, voilla, makkelijk dan met
24/60/120 de packets te analiseren en dan te laten beslissen of ze wel of niet op
volle snelheid mogen, protocollen zijn tegenwoordig niet meer relevant

Klik om te vergroten...

Protocollen zijn per definitie relevant, want daar hebben we het hier over (nntp). Poorten zijn minder relevant omdat die simpel te veranderen zijn.

Mijn webserver draait in SSL mode, maar laat 'm luisteren op een andere poort dan 443. En heb INN draaien als nntp server voor intern netwerkje als test. En ook die kan ik simpelweg op een andere poort laten luisteren. Dus dan kan mijn provider wel op de nntps poort 563 gaan shapen, maar dat heeft dus weinig zin.

En zoals ik al zei, alle grote ISP's gebruiken software waarmee ze niet alleen op de transportlaag kunnen kijken, maar ook op de toepassingslaag. Wat uiteraard flexibeler is, omdat je dan niet van gebruikte poorten afhankelijk bent.

als jij beweert dat ze ssl niet shapen (shapen? knijpen lijkt me een beter woord) dan kunnen ze nagenoeg geen winst halen uit het knijpen omdat tegenwoordig iedere client van newsreaders tot aan torrentclients volgens mij ssl aan kunnen... wat dus inhoud dat je voornamelijk de mensen zou treffen die 24/7 full throttle binnentrekken

Klik om te vergroten...

Encrypted verkeer kan als zodanig herkend worden, maar de betreffende software kan niet herkennen om welk verkeer het daadwerkelijk gaat. En dus is op die manier lastig te shapen. Uiteraard kan je al het encrypted verkeer gaan shapen, maar dan tref je ook mensen die bijvoorbeeld hun bankzaken online doen of over SSL inloggen op bijvoorbeeld het netwerk van hun werkgever.

Zoals je wellicht wel kan opmaken uit mijn postings ben ik geen tegenstander van traffic shaping (mits toegepast met het doel de bandbreedte utilisatie niet te laten bestaan uit > 80 % P2P verkeer). Maar als mijn provider SSL verkeer gaat shapen zou ik zeker gaan klagen, aangezien ik dat voor mijn werk gebruik.

Ik weet van mensen dat ze niet altijd de volle snelheid halen met ssl, lijkt me dus dat UPC niet op packet knijpt.. die wikipediazooi lees ik wel als ik tijd heb, ben meer ge-intreseerd naar het bedrijfje waar je over praat en de apparatuur zelf..

Klik om te vergroten...

Verdiep je eerst maar eens in de materie, van voorzeggen wordt je niet wijzer

Edit: typo

Lijkt me dat je voor bankzaken geen 24 of 60 of 120 nodig hebt als snelheid,
dus knijpen op de ssl zal geen probleem zijn voor mensen die bankzaken doen.

Je webserver draait in ssl-mode op een niet ssl-standaard poort, dat houd in
dat je slechts een select groepje toelaat, lijkt me totaal niets te maken hebben
met newsgroepen, die draaien op de standaard ssl-poorten dus makkelijk te
shapen.

Je zegt overigens zelf wat tegenstrijdigheden, er is apparatuur die niet alleen
de transportlaag kunnen bekijken maar ook dieper, dat wil niet zeggen dat ze
dus dieper kijken, alleen dat de mogelijkheid er is. Dat houd dus in dat er
gewoon beslist kan zijn dat men op transport knijpt en niet op de onderliggende
laag selectief traffic knijpt... dat de mogelijkheid er is wil niets zeggen over het
gebruik ervan.

Nog geen antwoord over welke apparatuur en programmatuur, dus verdiepen
in wikipedia is schijnbaar het enige wat er gedaan kan worden, word ik niet
veel wijzer van, staat trouwens in dat Chello knijpt, beetje outdated.. of het
moet echt de enige zijn die knijpt in Nederland, maar dat word weer ontkent?

Wat medewerkers van UPC zeggen, op de enkele na die gewoon straight
antwoorden geeft en niet alles uit het draaiboekje moet halen heb ik niet
bijzonder veel vertrouwen in wat deze beweren... ervaring heeft mij geleerd
dat van de 100 medewerkers er nog geen 10 weten wat ze moeten doen
als hun draaiboekje er niet is.

Hoi,
ik download met grabit via de eweka server. Ik zie dat mijn downloadsnelheid in de avonduren zakt naar 300 kb/s , ik heb een 10MB abo.
Ik zag dat ik bij grabit wel die ssl kan aanzetten maar dan krijg ik helemaal geen verbinding. Wat kan ik doen ?