netdev - Re: 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]

Message-ID: <4FF4A873.1000001@gmail.com>
Date:	Wed, 04 Jul 2012 22:32:51 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	"Erdt, Ralph" <ralph.erdt@...e.fraunhofer.de>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Rick Jones <rick.jones2@...com>
Subject: Re: RFC: (now non Base64) replace packets already in queue

Le 03/07/2012 12:02, Erdt, Ralph a écrit :
> 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.

I suggest you try and send a properly formated patch with your code, so that people here can have a 
look at it and evaluate the interest of integrating it into main line kernel.

That being said, I really think you should try to manage a userspace queue, in particular if you 
already have most of the job done in userspace using a tun/tap. I don't know the details of the 
special device you work with, but if you manage both side of the link, you can add many nice 
features into userspace to enhance the speed/quality :

- Compression (including very clever one if you know the meaning of the data you are transmitting).
- Packet numbering, to allow the remote side to ACK packet, the same way TCP does.
- Early ACK on TCP, if you get an ACK from the other side of your link and you assure that this link 
is the worst part of the path. This may help TCP to work on this low speed/high RTT link.

And I really see your packet replacement system as one of those nice features and cannot imagine a 
good reason not to put it in userspace.

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