Let congestion control algorithms decide congestion window.
Needs ReviewPublic
Actions

Authored by hiren on Oct 12 2016, 6:19 AM.

Details

Reviewers

kmacy
rrs
jtl
lstewart

Group Reviewers

transport

Commits

rS307901: FreeBSD tcp stack used to inform respective congestion control module about the
rS307899: In Collaboration with: Matt Macy <mmacy at nextbsd dot com>

Summary

First draft of the idea we've been discussing for quite some time to fix
stack overwriting cwnd value set by CC algos.

Prevent stack from changing cwnd value when CC is present.
Update CCs to set cwnd on NDUPACKS.
Update CCs to have RTO handling.

This work is in collaboration with Matt Macy.

As I mentioned, this is the first draft and review is cretaed to discuss/refine
how to best fix this.

Test Plan

Local dummynet setup and later with LLNW prod traffic.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 5554
Build 5789: CI src build	Jenkins
Build 5788: arc lint + arc unit

Event Timeline

hiren updated this revision to Diff 21290.Oct 12 2016, 6:19 AM

hiren retitled this revision from to Let congestion control algorithms decide congestion window..

hiren updated this object.

hiren edited the test plan for this revision. (Show Details)

hiren added reviewers: rrs, lstewart, jtl.

hiren added a subscriber: transport.

Herald added a reviewer: transport. · View Herald TranscriptOct 12 2016, 6:19 AM

Herald added a subscriber: imp. · View Herald Transcript

kbowling added a reviewer: kmacy.Oct 12 2016, 6:22 AM

Ping!

Summary of verbal feedback today:

If it can be done without major surgery, please consider changing (u_)long to (u)int32_t.
Because this changes the assumption about who sets snd_cwnd, please verify that all the congestion control modules follow the new assumption.

With that said, I think this is a great idea! :-)

Changing snd_cwnd tracking variable's name from win to cwin and its type to uint32_t.
I'll run all my tests tomorrow and update here with results.

Herald edited edge metadata. · View Herald TranscriptOct 21 2016, 6:36 AM

I tried running a few loss scenarios with various available CC algos and nothing seem broken. Loss scenarios include : dropping a single packet, dropping a bunch of packets, dropping a lot of packets to create severe loss situation, ack loss, etc.

Closed by commit rS307899: In Collaboration with: Matt Macy <mmacy at nextbsd dot com> (authored by hiren). · Explain WhyOct 25 2016, 5:03 AM

This revision was automatically updated to reflect the committed changes.