TCP Vegas per-socket alpha, beta, gamma parameters

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.dev@gmail.com)

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-owner@vger.kernel.org on behalf of Lars Erik Storbukås" <netdev-owner@vger.kernel.org on behalf of storbukas.dev@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.dev@gmail.com)
    

On Mon, Jun 19, 2017 at 3:30 PM, Lawrence Brakmo [off-list ref] 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-owner@vger.kernel.org on behalf of Lars Erik Storbukås" <netdev-owner@vger.kernel.org on behalf of storbukas.dev@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.dev@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.dev@gmail.com)