On Mon, Jun 19, 2017 at 3:30 PM, Lawrence Brakmo <bra...@fb.com> wrote:
> Hi Lars,
>
> You would need to modify the source code to support per connection alpha,
> beta and gamma parameters. Although you can modify the parameters at runtime,
> they would apply to all connections using Vegas, both existing and new ones.
>
> You may also want to consider using TCP NV (New Vegas) instead. It works
> better in current networks and servers.
>
> - Lawrence Brakmo
>
>
> On 6/19/17, 6:48 AM, "netdev-ow...@vger.kernel.org on behalf of Lars Erik
> Storbukås" <netdev-ow...@vger.kernel.org on behalf of
> storbukas....@gmail.com> wrote:
>
> I'm looking into how I can modify alpha, beta and gamma parameters for
> TCP Vegas on a per-socket basis (if at all possible). I want to modify
> the sending rate per-socket dynamically (not system wide) when a
> delay-based algorithm is used.
>
> Is it possible to modify the parameters of Vegas without modifying the
> source code of Vegas itself?
>
> Would setting the (system wide) alpha, beta and gamma parameters be
> updated immediately? Would an ongoing transmission get the new values
> of alpha, beta or gamma when they are modified, or is it read only
> when initialising a Vegas transmission?
>
> Background for question:
> I'm working on the implementation of a Deadline Aware, Less than Best
> Effort. A framework for adding both LBE behaviour and awareness of
> “soft” delivery deadlines to any congestion control (CC) algorithm,
> whether loss-based, delay- based or explicit signaling-based. This
> effectively allows it to turn an arbitrary CC protocol into a
> scavenger protocol that dynamically adapts its sending rate to network
> conditions and remaining time before the deadline, to balance
> timeliness and transmission aggressiveness.
>
> / Lars Erik Storbukås (storbukas....@gmail.com)
>
>
Thanks for a quick response!
I definetively see New Vegas as working better in current networks and
servers. I do however, need to support Vegas when implementing this.
Do you have any input of the best practice on how to provide (an
optional) per-socket configuration for alpha, beta and gamma
parameters? In other words when modifying the existing Vegas code.
Maybe it's possible to do add a parameters struct like this:
struct vegas {
u8 enabled;
u32 alpha;
u32 beta;
u32 gamma;
}
If vegas.enabled is set, it could use the per-socket parameters, and
if not, then it will use the system wide settings. Does this seem
logical?
Any help is greatly appreciated.
/ Lars Erik Storbukås (storbukas....@gmail.com)
