LibreQoS zou kunnen helpen om met name de latency significant omlaag te brengen. Is dit iets wat Freedom ook inzet of wat misschien interessant zou kunnen zijn om in te zetten?
Ik weet niet of âFreedomâ als bedrijf op het forum opereert.
Los van latency issue, zou het fijn dat er een soort dashboard is waar de netwerk(load&occupancy)status inzichtelijk is.
Ik heb soms ook onverklaarbare hickups van minuten en kan niet goed achterhalen waar in wel deel van de transportweg dit zit. krijg dan bv het idee dat iets/iemand ergens de pijp dichttrekt.
Vooral wanneer een concullega op datzelfde moment met bv een KPN abbo, geen enkel issue naar dezelfde target ervaart.
Ik denk dat Freedom dat in haar âNoCâ wel zichbaar heeft en het niet al te moeilijk zou zijn een een stukje door te sluizen naar een status scherm.
Ik heb de video nog niet gezien. Maar ik heb er eerder al naar gekeken na het beluisteren van een packet pushers podcast [1].
Merk op dat de latency niet omlaag maar juist omhoog gaat Alleen de latency wordt gelijkmatiger. Of te wel de jitter wordt minder. En dat maakt de âQuality of Experienceâ (QoE) beter.
We gebruiken het niet. Dat is voor ons stukje niet nodig omdat we voldoende bandbreedte hebben. We kunnen het zien als de buffers te vol beginnen te raken. Het kan anders zijn voor de access-netwerken. Dat proberen we ook in de gaten te houden maar is lastiger en kan beter (lees meer pro actief).
Mijn interesse ging idt dan ook niet zo zeer uit naar de QoE, want dat heeft pas nut bij te volle netwerken. De near realtime monitoring (5ms interval) is vanuit de techniek wel super interessant alleen kan het vanuit privacy oogpunt wel weer een probleem zijn.
Niet dat ik last heb van latency; denk wel dat je beter kan weten waar je op kunt rekenen - ook qua beheer - dan afwachen wat iets gaat worden.
In mijn low-level netwerktijd wel routines (in)gebouwd in systemen die extreme zaken voor gebruikers (af)dempten. In andere omgevingen, beurs/handel, juist zorgen dat het ânetwerkâ voor iedereen - waar/hoe dan ook - een gelijk QoE speelveld bood.
Vwb providers, heb ik liever rotsvaste 100mbit als ondergrens waar op kan worden voortgebouwd dan een onvoorspelbare 1000mbit die afwachtend jo-joâed als een malle.
Kwaliteit gaat dan voor kwantitijd.
Ik vind dat de presentator niet zo veel inhoudelijks zegt in dit stuk van de video
Het zegt alleen: âLees RFC8290â. Deze RFC beschrijft het Controlled Delay (CoDel)â Active Queue Management Algoritme. Dat doet de apparatuur van Freedom niet. Onze apparatuur doet Random early detection (RED).
Beide mechanismes hebben voor en nadelen en beide verminderen âbufferbloatâ [1]. RED wat minder goed dan CoDel. Maar RED heeft een hogere doorvoer capaciteit.
Het is even goed om te zeggen dat CoDel en RED alleen spelen als de apparatuur de packets niet meer kan uitsturen omdat de maximale capaciteit (bandbreedte) bereikt is. Dus als de verbindingen vol zitten. En dat is niet het geval bij Freedom. Neem bijvoorbeeld onze core1 router:
arien@core1> show interfaces queue | match drop.*[0-9] | count
Count: 320 lines
arien@core1> show interfaces queue | match drop.*[1-9] | count
Count: 0 lines
Uitleg: 320 teller tonen queue drops. Geen heeft een waarde hoger dan 0.
Dan: âBandwidth is a lieâ. Dat wordt totaal niet onderbouwt bij deze slide. Eerder in de presentatie tipt de presentator wel âoversubscriptionâ aan. Dus ik denk dat hij daar op doelt.
Ook Freedomâs netwerk oversubscribed. Dat wil zeggen dat we niet alle klanten tegelijk een volle bandbreedte kunnen benutten. Net als niet alle klanten van een bank tegelijk hun geld kunnen opnemen. Ik zie geen leugens hier.
Geweldig, veel dank voor de uitgebreide reactie! Ik heb het ook voorgelegd aan de LibreQoE mensen en ik begrijp dat in de praktijk maar weinig ISPs zijn die dit al zo goed aanpakken als Freedom dit nu doet.
Hier is de discussie aan de andere kant, ik hoop dat ik het goed geformuleerd heb:
Mijn idee is dat Freedom echt zo goed is dat mensen zich dat gewoon niet kunnen voorstellen
Het verschil is ook wel groot. De gemiddelde ISP die ik tegenkom stopt je achter CGNAT zonder IPv6, een traceroute laat hops met RFC1918 adressen buiten het LAN zien, etc. Allemaal wazige meuk.
Ik zal daar nog reageren, dat het toch echt klopt.
PS: Je kunt wellicht zien waar ik nu zit. Wat ik hier zie en dit is niet het LAN ofzo:
$ ping -c 3 10.0.0.0
PING 10.0.0.0 (10.0.0.0) 56(84) bytes of data.
64 bytes from 10.0.0.0: icmp_seq=1 ttl=60 time=6.10 ms
64 bytes from 10.0.0.0: icmp_seq=2 ttl=60 time=5.24 ms
64 bytes from 10.0.0.0: icmp_seq=3 ttl=60 time=6.03 ms
--- 10.0.0.0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.242/5.789/6.096/0.388 ms
$ ping -c 3 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=254 time=85.2 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=254 time=25.2 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=254 time=21.5 ms
--- 10.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 21.544/43.962/85.171/29.176 ms
Ik heb inmiddels het antwoord. Hij heeft dezelfde leus trouwens ook op zijn LinkedIn-pagina, dus het is niet specifiek gerelateerd aan de presentatie:
Dit gaat met name over ISPs gaat die heel erg de nadruk leggen op hoge snelheden in termen van veel data per seconde in plaats van latency. Van dat probleem heeft Freedom niet echt last naar mijn idee
Voor veel zaken is een lage latency is belangrijker dan een hoge bandbreedte.