Date: Mon, 27 Apr 1998 03:39:36 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: hackers@FreeBSD.ORG Subject: Re: RFC: IPFW/DIVERT change suggestion. Message-ID: <Pine.BSF.3.95.980427032227.9072A-100000@current1.whistle.com> In-Reply-To: <199804270828.KAA24696@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Apr 1998, Luigi Rizzo wrote: > > i think the most reasonable view of the "divert" process is to see > it as a graph where a pkt is forwarded. So we need to associate > a set of rules to each node of the graph, and a matching rule also > needs to specify the 'destination' node where to restart processing. The trouble with this approach is that the filter program needs to be able to specify where to go, as it might generate 2 packets from one incoming (imagine a compression filter). Also where would you store that information while the packet is out in user-land? This what why I suggested keeping info in the kernel for the last N packets (option 2). But I'm not crazy about that idea. > > So i would add a parameter to divert-like rules where you specify > the next rule to continue processing. > In a sense, this is similar to the first approach you propose, except > that the 'destination' can be interpreted as a "jump". > (there is no need to modify simple actions like allow/deny since the > decision is final.) what about a filter that looks at packets and makes a decision to send it back to one of 2 differnt rules? > > > would be that it might be possible to store a 'stack' for each packet > > so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're > > reading) > > don't like the idea of 'subroutines' very much, i doubt it would be > of much use in practice, and lot of work to implement it. you would also need local variables etc. it would become a whole language.. :-b ipfw-basic ;-) (someone would write a fortran compiler in it..) I've done 99% of a IPFW/divert using daemon that watches incoming traffic and tries to slow down sessions that look like they are monopolising the link. I should have it running tomorrow sometime. Re: dummynet: I'm not sure that providing queueing for TCP streams will provide an efficient manner of flow control. you eventually will need to drop a packet to get a window-size down to a size you like, other wise you will end up having to store a whole window's worth of data (16K on average I guess) for every TCP session. How do your results look for incoming control? what do you use for policy? (which sessions get what bandwidth?) Our BW limiter is basically similar to the scheduler in that long-running sessions get lower priority and sessions that have unused allocations get a higher priority when they eventually get data. The aim is to keep interactive response while allowing FTPs to continue at reduced throughput in the background. each 'tick' priorities are re-evaluated. presently it's a user mode daemon fro testing using DIVERT. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980427032227.9072A-100000>