search

systemslab / tcp_inigo

TCP Inigo takes DCTCP's ECN based Congestion Control and uses a similar delay based CC alongside it, amongst other enhancements
2 stars 6 forks source link

Thx #1

Open dtaht opened 8 years ago

dtaht commented 8 years ago

For making the code and results widely available. It was a good paper, too. But I just don't believe in new tcps without code attached. Thx. I'll poke at this.

agshew commented 8 years ago

You're welcome! I'm glad you liked the paper. I agree with you that it's difficult to believe anything without code. And I've found that even code is insufficient. I've downloaded prototypes that I couldn't get to work well at all.

These are, of course, preliminary results. And while I believe Mininet validates the basic ideas and implementation, I am now working on a version of the code that responds once per-ACK instead of once per sub-window. It's based on some discussion about DCTCP and Relentless with Bob Briscoe on the IETF TCPM list.

It greatly simplifies the code to not have to keep track of a congestion ratio (alpha), and my Mininet experiments shows that a per-ACK response can tighten up the RTT distribution. However, I had to make some odd tweaks to the AIMD constants, and I'm working on understanding those changes in my fluid model equations before I work on the code some more.

I don't think I'll abandon using an alpha entirely even with a per-ACK response. The reason is that alpha, as it is defined by DCTCP and Inigo, isn't simply a congestion ratio. From the fluid model, it seems to me that alpha is a clear indicator of the number of other flows contending for the same bottleneck. While a straightforward Relentless-style algorithm backs off a fixed amount for each marked ACK, the backoff should still be modified by alpha to be more aggressive when number of flows is higher and vice versa.

I am also looking forward to an upcoming patch set from Eric Dumazet at Google to increase TCP time stamp resolution to usec. Since using TCP options to negotiate different resolutions is problematic, we'll probably have a per-route attribute at first. But I hope to develop a way to negotiate using just the time stamp values for long-lived flows. This won't necessarily help on the Internet, but I do like the idea of using differences in OWDs rather than RTTs.

Anyway ... enough rambling.

I'm looking forward to any feedback you have.

Andrew

dtaht commented 8 years ago

Couple thoughts.

1) We use flent to generate a variety of repeatable tests. Notably, the "rrul" test blows up most straight aqms, red, and dctp approaches. Try it. Regardless, the graphs are handy for analyzing all sorts of behaviors, especially including comparing tcps.

I will probable add a few new tests to compare cdg and this (Assuming the code builds on a 4.6 or later linux). I have a new pair O tcps arriving soon, also, to play with, after we get done with the wifi work, or at least at a stopping point.

Didn't know someone was going to usec, given than ms is far too granular I was figuring more would try to interpolate bursts across that. (see also sch_fq's pacing - which lets the sender get down below a ms)

And yea, any paper that doesn't make me want to pull out a dozen little red rubber stamps makes me happy, and additionaly you got all the recent history quite right, in a readable fashion.

http://blog.cerowrt.org/post/talks/engineering/