search

gw-cs-sd / sd-2017-team-ddos

sd-2017-team-ddos created by GitHub Classroom
0 stars 0 forks source link

Milestone 1 #6

Open twood02 opened 7 years ago

twood02 commented 7 years ago

Finish naive load balancer

Due: Friday April 14, 2017

twood02 commented 7 years ago

reminder @mrdude -- we will meet on Friday to discuss!

mrdude commented 7 years ago

@twood02

Todo / What have I been doing?

I still haven't finished the naive load balancer yet, but I'm so close. Here's what happens so far, as of commit cca117 in dev-athenafsm2:

1) Client sends a SYN packet to Athena 2) Athena responds with a SYN-ACK, and sends a SYN to a backend 3) Instead of sending a SYN-ACK back to Athena, the backend seems to assume that the connection is just fully open and starts sending data packets. Instead of dealing with the data packets, Athena gets confused and will just ignore them until the SYN-ACK comes in. Eventually the backend will try to send a few PSH packets, then give up and RST the connection.

Plan of Action / What am I doing next?

My gut feeling is that this bug has something to do with the TCP options that Linux sends (and Athena completely ignores). This means that my next step is to start figuring out what common TCP extensions I need to implement in order to get Athena and Linux talking together. A big of googling tells me that RFC1323 is responsible for the TSval and TSecr values I'm seeing in my pcaps, so I'm going to start with that. I've also heard of something called "TCP Fast Open", which may have something to do with the backend's weird behavior during the TCP handshake.

I'm also going to take a few pcaps of "normal" TCP sessions between two Linux hosts, and compare those to my Athena pcaps to find the bug.

mrdude commented 7 years ago

@twood02 I read all about the 3 most commonly used TCP options (selective acks, timestamps, and window scaling); Athena doesn't really need to care about them and can just blindly pass the TCP options through. I skimmed through a few other RFCs, but I couldn't find any options that would indicate any of the weird TCP behavior I've been seeing.

Then I went back to the printf() debug-spew from my latest Athena run, and realized that the bug is in how I map TCP packets to struct connection's. Athena changes the port number on packets (in order to route packets to HTTP backends), but doesn't account for this in ct_lookup_connection(); what ends up happening is that my Athena <=> Client half of the connection gets mapped to one connection, and my Athena <=> Backend half gets mapped to another connection.

twood02 commented 7 years ago

Sounds like progress.

On Sat, Apr 22, 2017 at 3:27 AM Warren S notifications@github.com wrote:

@twood02 https://github.com/twood02 I read all about the 3 most commonly used TCP options (selective acks, timestamps, and window scaling); Athena doesn't really need to care about them and can just blindly pass the TCP options through. I skimmed through a few other RFCs, but I couldn't find any options that would indicate any of the weird TCP behavior I've been seeing.

Then I went back to the printf() debug-spew from my latest Athena run, and realized that the bug is in how I map TCP packets to struct connection's. Athena changes the port number on packets (in order to route packets to HTTP backends), but doesn't account for this in ct_lookup_connection() https://github.com/mrdude/openNetVM/blob/dev-athenafsm2/examples/athena_lb/connection_table.c#L85; what ends up happening is that my Athena <=> Client half of the connection gets mapped to one connection, and my Athena <=> Backend half gets mapped to another connection.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gw-cs-sd/sd-2017-team-ddos/issues/6#issuecomment-296354806, or mute the thread https://github.com/notifications/unsubscribe-auth/ADa1C6trfL9nPsPuG-dQWsgD3BSe-gmIks5ryav9gaJpZM4M3Pml .

--

Timothy Wood, Ph. D. Assistant Professor Department of Computer Science The George Washington University http://www.seas.gwu.edu/~timwood

twood02 commented 7 years ago

How are things going? Should we meet on Friday this week to discuss?

mrdude commented 7 years ago

State machine actions are done -- I just pushed the commit. With that version of the code, Athena correctly passes through HTTP requests from Wget and Vegeta.

That means that my naive load balancer is finally done! Hopefully this also means that I'll have an easier time implementing the rest of the load balancing strategies, as I won't have to re-implement (and re-debug) any of the code responsible for correctly routing TCP connections. The goal is to have all of the load balancing strategies (least connections, round robin, queue time) implemented by Friday so that I can spend the weekend cleaning/refactoring/polishing code.

Even if I do finish the code, we should probably meet this week to go over non code-related details (the poster, screencast, website, etc). When are you free on Friday?

twood02 commented 7 years ago

How about Friday at 1:30?

mrdude commented 7 years ago

Ok, sounds good!

mrdude commented 7 years ago

Now that the actions are done, this is all coming together nicely:

twood02 commented 7 years ago

sounds good. Do you have a setup that allows you to have multiple backends?