[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FB112703C4930F4ABEBB5B763F96491139379ECF@MAILSERV2A.lorien.fkie.fgan.de>
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
Powered by blists - more mailing lists