Again, apologies, Finnish only, but maybe this isn't completely inscrutable. Mind commenting on my bufferbloat visualization? Especially interested in whether it makes sense if you haven't heard about bufferbloat before. https://uusinetti.fi/tekniikka

@pajp one of the cables goes right by our summer cabin island so the under sea aspect of it was very top of mind here

@karppinen Oli ymmärrettävä mutta pakettien tiputtelu ratkaisuna ei ollut heti ilmeistä. Ja sitten tietysti herää kysymys että eikö siitä muodostu ongelmaa?

@samikki oikeastaan vipuja on vain kaksi: pakettien tiputtaminen ja ECN-bitin asettaminen. Käytännössä jälkimmäisellä ei ole kovinkaan suurta merkitystä. Olennaista on tiputtaa fiksusti niitä paketteja, se iso TCP- tai QUIC-tiedonsiirto kyllä pärjää packet lossin kanssa, teamsit ja vastaavat sitten huonommin

@samikki …ja esim nykyään paljon sekä TCP- että QUIC-yhteyksissä käytetty BBR-hallinta lähettää surutta tavaraa kunnes paketit alkavat hukkumaan, eli tavallaan ympäristö on aggressiivisempi nykyään

@karppinen CC @toke

@karppinen It’s not quite NDP-level, but pretty nice and looks accurate.
(NDP being https://youtu.be/BO0QhaxBRr0?is=e4vVR6ddhcsljHbZ)

@lars thank you for the link, hadn't seen this before!

@lars @karppinen Nice! I like the "packet stuck in the queue" animation! The wave-shaped graph of latency underneath it is less clear, I think. I understand what it means, but I also now what to look for. And even then, I found myself looking for a relationship between the queue length in the animation, and the wave crests, but I don't think there is one?

Also, your animation shows the downlink, what are you doing with the uplink? And have you had any issues with queue buildup inside the end-user fibre networks you're providing service across?

@toke yeah the wave graph does show the historical trend of the main buffer length, but it's a bit too tidy to look real :) It's supposed to show the bulk TCP flow backing off periodically but a bit simplistic for sure.

We're running the same DRR++/FQ-CoDel shaper both up and downstream, shaped very slightly below the plan rate. Pretty good results so far, but it's *very* early days, we're just launching and starting to get real world experience on this.
@lars

@karppinen @lars right, so you supply the CPE, and that runs FQ-CoDel as well? Cool!

So when you say "DRR++/FQ-CoDel" is that your own implementation, or are you using one of the Linux qdiscs (and if so, which one)? :)

@karppinen it makes me think why your service is better than the others. It just shows animation where packets get queued or not. I'd perhaps add a sentence or two why someone would believe the graph. "Our technology works better because it uses ... so packets are queued smarter."

@toke right now we just naively run it on the network side in both directions, clearly not ideal for the upstream but seems to help even there. It’s our in-house userland router that works on vxlan packets.

Also doing this on a CPE would clearly be complimentary, especially for WiFi, but it’s quite the undertaking…@lars

@ikkeT yeah. explaining queuing disciplines gets real technical real fast, so how much to simplify is the trade off. But the intent is to show us dropping packets so it’s not just that we don’t have a queue and others do

@karppinen silloin vain sanoisin sen. Ei välttis satunnainen selaaja hiffaa logiikkaa pelkästä kuvasta. "ratkaistu heti siellä missä pullonkaula on, eli poistamme tukkivaa liikennettä jo laitteissamme." Tjsp.

@karppinen Kuulostaa kauhealta haaskaukselta jos paketteja vaan dumpataan lisää ja lisää kun jossain on hidasta 😃

@samikki joo no tosiaan jos haluaa ihmisen hyvyyteen uskoa niin sitten lähettävä pää ymmärtää yskän ECN-signaloinnilla ja paketteja ei tarvitse pudottaa. Mutta todennäköisesti pudotetaan :)