Help me get started (II)

Help me get started (II)

[Siavash Eghlimi]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Dear contributors,

Hi. I already did a post, and got A LOT of help from a
Mr.Høiland-Jørgensen, if I'm not wrong. first I wanted to thank all of you;
and HIM, in particular.

Second, it was suggested to me to so some measurements AND to choose a more
specific area (Aspect) of bufferbloat. Well, I did some measurements and
some research just to get an idea of how it works... Can't say I completely
get it yet, but I'm getting there :)

also, I chose a more detailed aspect of bufferbloat; "Low-layer network
protocols' design and their impact on buffering (ex: WiFi networks can't do
aggregation without some buffering)"

Since I wanna do a Thesis on it, and use Linux as a tool to understand
networking and do programming, I found resources on Linux and its network
stack.

What I need now is specific resources on the ASPECT of bufferbloat that I
chose. where should I go? what should I read? how to get into it? I don't
wanna dive into it blindly. I want to do this RIGHT. and because of the
Thesis, time is of the essence. also, I really wanna do something to help
the community, HOPEFULLY.

I appreciate ANY kind of help.

Thank you all.
Siavash

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

Re: Help me get started (II)

[Toke Høiland-Jørgensen]

Siavash Eghlimi <eghlimidev@gmail.com> writes:

> Dear contributors,
>
> Hi. I already did a post, and got A LOT of help from a
> Mr.Høiland-Jørgensen, if I'm not wrong. first I wanted to thank all of you;
> and HIM, in particular.

You're welcome ;)

> Second, it was suggested to me to so some measurements AND to choose a
> more specific area (Aspect) of bufferbloat. Well, I did some
> measurements and some research just to get an idea of how it works...
> Can't say I completely get it yet, but I'm getting there :)
>
> also, I chose a more detailed aspect of bufferbloat; "Low-layer
> network protocols' design and their impact on buffering (ex: WiFi
> networks can't do aggregation without some buffering)"
>
> Since I wanna do a Thesis on it, and use Linux as a tool to understand
> networking and do programming, I found resources on Linux and its
> network stack.
>
> What I need now is specific resources on the ASPECT of bufferbloat
> that I chose. where should I go? what should I read? how to get into
> it? I don't wanna dive into it blindly. I want to do this RIGHT. and
> because of the Thesis, time is of the essence. also, I really wanna do
> something to help the community, HOPEFULLY.

Well, first question would be: What did you measure, and what did that
show? Was there something there you thought was interesting that you
want to explore further? And what did you read already? :)

-Toke

Help me get started (II)

[Siavash Eghlimi]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Hi everybody, hope you all feel great,

I wanna do a thesis on bufferbloat. I posted some questions and got
beautiful answers. following those conversations, it was asked:

--What did you measure, and what did that show?
    I measured my DSL line via couple of different methods and tools. seems
my line is bloated. ping time got tripled. there is latency in, both, my
download and upload. i have the results saved.

--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.)

--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?

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 ....

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 ?
Third place goes to "SQM".

Any suggestions?  :)
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.)

Thanks a lot
Siavash Eghlimi

[-- Attachment #2: Type: text/html, Size: 3066 bytes --]

Re: Help me get started (II)

[Toke Høiland-Jørgensen]

Siavash Eghlimi <eghlimidev@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