Conversation
Holger Hoffstätte
asynchronaut@fosstodon.org
Interesting read of the day, with (new to me) bits about fq_codel.
cc: @toke
1
0
0
Toke Høiland-Jørgensen
toke
@asynchronaut
Interesting! I like the gradual phase-in approach. Will be interesting to look at the implementation once they (hopefully!) release that!
What was the bit that was new about fq_codel for you?
Interesting! I like the gradual phase-in approach. Will be interesting to look at the implementation once they (hopefully!) release that!
What was the bit that was new about fq_codel for you?
1
0
0
@toke Just the realization that fq_codel's drop seems to be so disruptive, though I don't know if they had batch drop (old implementation?). Maybe we should look into that, the batch drop always seemed a bit drastic to me.
1
0
0
Holger Hoffstätte
asynchronaut@fosstodon.org
Edited 9 months ago
@toke OTOH it makes sense because "per-flow fairness" is hokey since from the point of view of one running flow, the other party comes with 39 helpers in tow.. (unless it's HTTP2 etc.)
1
0
0
Toke Høiland-Jørgensen
toke
@asynchronaut
Yeah, per flow fairness is trivially gamed by just opening a bunch of flows. Which is basically what they show here.
This is the reason we added per host fairness to sch_cake, BTW: harder to game (in a regular home setting); it means that someone opening a bunch of flows will only hurt themselves. This "gentler fairness" idea may be useful in that context as well, though...
Yeah, per flow fairness is trivially gamed by just opening a bunch of flows. Which is basically what they show here.
This is the reason we added per host fairness to sch_cake, BTW: harder to game (in a regular home setting); it means that someone opening a bunch of flows will only hurt themselves. This "gentler fairness" idea may be useful in that context as well, though...
0
0
1