netdev - TCP Vegas per-socket alpha, beta, gamma parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF0XkCCmL4nxQbvGOVneRqh_9bofc+yFe=nrJAQzGv+nHmEWvg@mail.gmail.com>
Date:   Mon, 19 Jun 2017 14:48:06 +0100
From:   Lars Erik Storbukås <storbukas.dev@...il.com>
To:     Netdev <netdev@...r.kernel.org>
Subject: 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@...il.com)