Opened 8 years ago

Closed 6 years ago

#3729 closed defect (fixed)

obfsproxy rate limiting

Reported by: asn Owned by: asn
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #3591 Points:
Reviewer: Sponsor:

Description

As a temporary workaround to the hurdles of #3587, I implemented rate-limiting internal to obfsproxy; like it was discussed in Canada.

Basically, there is a new obfsproxy option '--throttle=<kb>' which sets the read/write rate/burst per second, to <kb> kilobytes.

It's not really flexible (no way to specify different values for read/write or rate/burst), but it serves as a basis for future work... maybe.

Child Tickets

Change History (9)

comment:1 Changed 8 years ago by asn

Status: newneeds_review

Check out bug3729 branch.
It's currently based on zwol's 1f022eac.
I'll improve it and make it more flexible when #3613 is resolved.

comment:2 Changed 8 years ago by asn

Status: needs_reviewassigned

This is not complete and should not be merged.
Pulling it out of needs_review.

comment:3 Changed 8 years ago by asn

Please see branch bug3729_take2 in https://git.gitorious.org/obfsproxy/obfsproxy.git.

I added four new obfsproxy arguments:

--read-limit=<kb> ~ set the soft limit of incoming traffic to <kb> kilobytes per second (default: no limit)
--read-burst=<kb> ~ set the hard limit of incoming traffic to <kb> kilobytes per second (default: no limit)
--write-limit=<kb> ~ set the soft limit of outgoing traffic to <kb> kilobytes per second (default: no limit)
--write-burst=<kb> ~ set the hard limit of outgoing traffic to <kb> kilobytes per second (default: no limit)

Would it make more sense to only have two options, one for the soft limit and one for the hard limit, and not care whether it's outgoing or incoming traffic?

Also, if the user specifies only a soft limit (without a hard limit (burst)), I spit out a warning and set the hard limit equal to the soft limit.

comment:4 Changed 8 years ago by asn

Status: assignedneeds_review

comment:5 Changed 8 years ago by nickm

What happens if the rate is set but the burst is not? it looks like only the opposite case is configured.

Converting strings to integers seems like it's part of the UI, and should probably happen in main or something, not network.

The SET_RATE_LIMITING_VALUE macro should probably check for overflow.

Otherwise looks okay.

comment:6 in reply to:  5 Changed 8 years ago by asn

Replying to nickm:

What happens if the rate is set but the burst is not? it looks like only the opposite case is configured.If the rate is set but the burst is not, I set the burst to EV_RATE_LIMIT_MAX. So I end up with the user-defined rate, and an unlimited burst.

If the rate is set but the burst is not, I set the burst to EV_RATE_LIMIT_MAX. So I end up with the user-defined rate, and an unlimited burst.

Converting strings to integers seems like it's part of the UI, and should probably happen in main or something, not network.

At the moment, this is just an atoi() call inside the SET_RATE_LIMITING_VALUE macro. Do you think I should move a wrapper of it in main?

The SET_RATE_LIMITING_VALUE macro should probably check for overflow.

Done. Please check branch bug3729_take2 again.

Otherwise looks okay.

comment:7 Changed 8 years ago by asn

I'm thinking of reducing the configuration parameters to two, one for the rate and one for the burst, similar to how BandwidthRate and BandwidthBurst does it for tor.

What do you think?

comment:8 Changed 8 years ago by arma

Component: Pluggable transportObfsproxy

comment:9 Changed 6 years ago by asn

Resolution: fixed
Status: needs_reviewclosed

This ticket is about the old C-based obfsproxy. Closing.

Note: See TracTickets for help on using tickets.