netdev - RFC: (now non Base64) replace packets already in queue

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Jul 2012 10:02:05 +0000
From:	"Erdt, Ralph" <ralph.erdt@...e.fraunhofer.de>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>, "Rick Jones" <rick.jones2@...com>
Subject: RFC: (now non Base64) replace packets already in queue 

Hello,

I found, that my eMail program send the eMail as UTF-8 / Base64. I'm sorry for the circumstances. I hope it's OK for you, that I'm repeating the content, so that everyone can follow it. But I will compress the whole discussion (Thanks to Eric Dumazet, Rick Jones and Nicolas de Peslouan):

-

I'm writing a kernel module (net/sched) which replaces packets in the queue. I'm glad hearing your option.

Background:
We are working with a property wireless network (no 802.11). The specifications: 
 Range: Kilometers.
 Speed: <=9,600 bps (no Megs, Gigs or Kilo!) (*).
 RTT (standard ping): idle-network: 1,5 *seconds*; network with load: minutes
 Other: shared.
 Connection: loosely to a Linux box, but without Linux driver. 
 Driver: a user-space program, which opens a virtual network device and sends 
         the packet from the virtual network device to the device.
 Queue: The device has no queue nor the user-space program. The program waits 
         for the ACK from the device before sending the next packet. This is 
         possible, because the wireless is so lame...

(*you remember the good ol' times with modems over telephone lines? When the 
internet was called BBS? And how it suddenly feels, when the BBS starts using
ANSI? This was comfortable compared to our problem..)

With such a very low bandwidth network its hard (rather: impossible) to get all 
packets sent. (TCP isn't possible, so we are sending everything as UDP.)
Some of the packets contain information, which gets obsolete over time. E.g. 
(GPS) positions, which will be sent periodically. If the application sends a new 
packet while an old position packet is still in the queue, the old packet is 
obsolete. This can be dropped. But just dropping the old packet and queuing the 
new packet will result in never sending a packet of this type.

So I've written a tc-qdisc scheduler module, which replaces packets in the queue 
on enqueuing, when this properties are given:
- UDPv4
- not fragmented
- (TOS & bitmask) = givenCompare; (bitmask and compare are adjustable)
- same source IP
- same destination IP
- same destination port
- same TOS
So, the packet got sent over the time - but with the actual information.
 (The code is tiny - just a file (and Kconfig, etc.))

Why not using "codel"? Because codel will drop "randomly" ("random" not for the 
protocol, but for the application) packets. It's made to reduce the flow speed.
But we haven't a flow, only periodic sensor data.
My qdisc won't drop random packets. It will reduce the traffic by intelligently 
replacing packets in the queue. Surely - the application must handle this. But 
in such a network a administrator have to configure the queues and he knows the 
applications.

Why not adding a tun/tap interface and do everything in the user space? 
As mentioned, the device "driver" is a user space program, which creates a tun/tap
interface. We CAN mix the code there in, but separating the work has a few benefits:
- separating the work with clear interfaces is always a good idea.
- having a qdisc will allow complex TC rules using this qdisc - it's fully compatible.
  (In fact - we have guidelines given. We can handle all of the guidelines with the 
   given TC classes - except the replace thing.)
- administrators knowing TC can work with this qdisc without any problems

My question is: Should I do the work to create and release a kernel patch and make 
it perfect over the time, or is this just our internal code, which I can leave at 
the current state? I know our module won't be used widely (too special), but I'm 
sure, there are a few people out there, which would be thankful for this.

Have you any other comments?

Greetings
Ralph Erdt 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html