netdev - Process phantom ECN event in TCP without CWR response

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAF0XkCAFchar70B=b+TNXOD+jDoxGy6Ty9N4qhBP6ji9yipwDA@mail.gmail.com>
Date:   Wed, 24 May 2017 10:45:01 +0200
From:   Lars Erik Storbukås <storbukas.dev@...il.com>
To:     Netdev <netdev@...r.kernel.org>
Subject: Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the
transmission rate/throughput.

The signals is meant to be generated and received on a single host. I
don't want the ECN event to generate a CWR (Congestion Window Reduced)
response to the sender. I'm trying to think of ways to avoid the TCP
code from entering the part of an ECN event, where the response to the
sender is generated.

I have thought of two (possible) solutions:

1. Before the phantom ECN signal is generated, a FLAG is set,
indicating that a phantom ECN event is coming. Before entering the
part where the CWR response is generated, perform a check on whether
the FLAG is set or not (if set - do not enter CWR part).

2. Instead of generating ECN signals (modify incoming packets), use a
flag to indicate that the next incoming ACK is processed as if it were
an ECN signal (except entering the CWR part).

Any input on how to implement, or pointers for where to look for
similar solutions is greatly appreciated.

...

For those who are interested in why I'm trying to achieve this:

I'm working on the implementation of a Deadline Aware, Less than Best
Effort framework. 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)