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

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

Date:	Fri, 29 Jun 2012 11:06:57 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"Erdt, Ralph" <ralph.erdt@...e.fraunhofer.de>
Cc:	Rick Jones <rick.jones2@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: AW: RFC: replace packets already in queue

On Fri, 2012-06-29 at 08:46 +0000, Erdt, Ralph wrote:
> Hello Rick Jones,
> 
> > You might want to try the recent "codel" additions to the stack.  They
> > seek to keep the size of queues more manageable while still allowing
> > the occasional burst.
> Thank you for your hint. This is surly a needful solution in normal network, but this didn't help us:
> We are working with very heterogeneous networks:
> Internal: 100MBit and more.
> Extern: 9,6*K*Bit and LESS(*), and shared, and...
> A few other information: wireless (higher packet loss rate), medium access time > 100ms, RTT (standard ping) with IDLE network: 1,5 *seconds*, RTT with network load: minutes(!), and so on. Just very shocking..
> 
> TCP isn't usable over such a link. So we are only sending UDP. The codel didn't help us, as codel addresses the flow speed. It's dropping "randomly" (I know it's not random in the lower level, but it's random from the application's perspective) packets. 
> 
> I'm addressing the amount of information: Trying to reduce it intelligently by REPLACING old packets with new ones.. Surely - the application must handle this. But in such a network a administrator have to configure the queues and he knows the applications.
> In one private mail someone guesses that we are making VoIP. No - we just want to send status information (e.g. sensor information) which will get deprecated, when a new information is available.
> 
> I know, this is a very special problem, which didn't occur in normal or even abnormal situations. But I'm sure there are some other people having the this problem, too. So I'm glad to share my solution.
> 
> (*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..)

Problem is : with wireless, chances are high that the old packet is not
waiting in qdisc, but in wireless queues.

Anyway, adding a maxdelay to codel / fq_codel is really easy : This
would drop packet if its sejourn time is above a given limit.

You could use codel with @target being greater than @maxdelay to remove
all probabilistic drops, and only keep the @maxdelay behavior.

If you want I can cook this patch.



--
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