Help me get started (II)

[Toke Høiland-Jørgensen]

Siavash Eghlimi <eghlimidev at gmail.com> writes:

> --Was there something there you thought was interesting that you want to
> explore further?
>     Well, this whole thing is interesting. I didn't know that I'm NOT using
> about 47% of my bandwidth :)  (talk about helping people...)
> turned out, ALL of my devices have SOME kind of a problem in this area.
> but, what was MOST interesting to me was "How much I don't know"; I'm not
> only talking about knowledge, but about these problems that exists and MANY
> people, even PROs (not that I am one), don't know about.
> Science-wise, most interesting part is the implementation of algorithms and
> protocols that caused these problems in the first place. why did they cause
> it? integrating some of the solutions together (like SQM). things of that
> nature is interesting to me. generally, Implementation is more interesting
> to me than the solution, itself. (How to do, rather than WHAT to do.)

Ah, sounds like the true hacker spirit; excellent ;)

So in this vein, and since you're running DSL, one project might be to
get your hands on a DSL device with a hackable driver and see if you can
get the driver on its own to perform on par with ethernet. I.e., fix it
so it doesn't need the software shaper on top that we currently use in
sqm-scripts, but would work well with low latency just by installing
fq_codel as the root qdisc on the interface.

This would involve figuring out how to integrate BQL into a DSL driver,
probably; I think the lantiq driver would be the one to look at (since
it's open source), but I have no idea how much work it would be to get
something working. It would certainly be useful, though (you'd have
basically shown that the uplink side of DSL can be fixed). And it's
certainly something you can pretty much just start hacking on. The
downside is that there's a risk of being really frustrated when working
this close to hardware that is probably not terribly well documented,
and it may be that the driver requires quite a bit of surgery. But from
a thesis perspective, describing this and coming up with a design to do
something about it might be quite viable, even if you don't get all the
way.

> --And what did you read already? :)
>     1. Classic bufferbloat article.
>     2. ALMOST advanced network concepts like "Window Scaling" , "Framing",
> etc. etc.
>     3. One fourth of "TCP/IP Architecture in Linux .... "
>     4. Wireshark (Basics)
>
> So, my question:
> first, any suggestion, generally, so far?

Well, first off, understand the problem you are trying to solve,
describe your proposed solution and why it is a good idea, then go
implement it. Mostly in that order (though there's also a feedback cycle
here).

> second, I tried to study FreeBSD since Linux was TOO BIG. anyway, I found a
> good book and as I was studying, I could swear I saw something in "
> bufferbloat.net" about FreeBSD. So, I checked it out; turns out it's a
> project to implement some algorithms like CoDel into FreeBSD. Immediately,
> I emailed the professor in charge, and he simply said: "I don't have time"
> :)
> This project seemed tailor-made for me. lots of coding. something CLEAR to
> do. loads of stuff for the Thesis. lots of science and knowledge. but
> ....

Heh, yeah, Linux is big and the code changes at a tremendous pace. Can
be daunting at first. You don't have to understand all of it to do
something useful, though (I don't think there's *anyone* who understands
the whole Linux kernel as it is today). I don't really know a lot about
FreeBSD in this respect; and am not terribly up to date on the state of
bufferbloat mitigation is in BSD either. If you wanted to look into it
for your thesis, what you could do is setup an experiment to compare
them (Linux and BSD, that is) and if one is better than the other figure
out why and fix it :)

> Second place goes to "Flent", though I don't know how much work is there to
> be done. Can it bear a thesis for me ?

Hmm, if you wanted to work on Flent you could pick a new feature to
implement. If you want to keep a network research component to the
thesis, it would be a new kind of measurement that you could add. But it
could also be general feature additions, which would make your thesis
more software engineery, I think.

Hmm, in the former category you could try to implement a measurement
that would detect the presence of fairness queueing in the network. In
the latter category you could try to get incremental test runs from the
GUI (and interactive plots while the test is running) to work.

That's all I can think of off the top of my head, but there are probably
other tests that might be useful to have; perhaps someone else can chime
in...

> Third place goes to "SQM".

Hmm, one thing that comes to mind here would be to do a comprehensive
comparison of the Cake qdisc to the HTB+fq-codel-based setup that
sqm-scripts uses when Cake is not available. We eventually want to
upstream Cake in Linux, and having comprehensive benchmarks to point to
would be useful in this regard. May also be some tweaking to be done on
the qdisc in relation to this.

> I really wanna start sooner than later and get my hands dirty. I know, this
> is not enough research to know exactly what you want, but my time is
> limited and I better begin.
> (By the way, I can put 7 months on it.)

Enthusiasm is a good starting point, certainly! :)

-Toke