Date: Sat, 10 Apr 1999 17:43:40 +0200 (CEST) From: Remy Nonnenmacher <remy@synx.com> To: luigi@labinfo.iet.unipi.it Cc: net@FreeBSD.ORG Subject: DN Bandwidth sharing. (was Re: possible dummynet enhancement (rando m pkt reordering)) Message-ID: <199904101543.RAA20807@rt2.synx.com> In-Reply-To: <199904101214.OAA02250@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Apr, Luigi Rizzo wrote: > Excuse me but i think there is a misunderstanding. Having dummynet > reorder packets is just to simulate a network "feature" that should > not exist on most networks (but it might if you have clustered > links or multiple paths) and see how the protocol stack behaves. > > It is not a way to implement some form of fairness... > Oups, sorry. Was too focused on getting things better than worst for test-beds tools purposes. I missed the 'enhancement' meaning. > so, i think the first part of your email does not apply (i know > applications will have a harder time!) while the second part could be > interesting and worth reposting under a separate Subject (or, if as you > say it is long, put it somewhere on the web and give me an URL). > Here is : pipes are gathered by logical groups depending on their number. A group is just a range (0-99, 100-199, 200-299, etc....). Within a group, bandwidth that have not been used by a pipe is spred over the active pipes within that group. Actually, the process is : - Design the set of ipfw rules that will designate a pipe (ie: HTTP, telnet, smtp, other) and the flow (in/out). - build the set of pipes that will handle the flow *in the worst case* (every pipe active). The sum of the bandwith must be the real, physical, maximum allowed bandwidth for that group. Exemple : Lets say that, using a 64Kb/s link, you allow, in the worst case : - HTTP : 30Kb/s - Telnet : 10Kb/s - SMTP : 5Kb/s - Other : (64 - 30 - 10 - 5) = 19Kb/s So the set of pipes are : ipfw pipe 1 config bw 30K .. ipfw pipe 2 config bw 10K .. ipfw pipe 3 config bw 5K .. ipfw pipe 4 config bw 19K .. and routing ipfw rules like : ipfw add 1 pipe 1 from any to any http via tun0 out ipfw add 2 pipe 2 from any to any telnet via tun0 out ipfw add 3 pipe 3 from any to any smtp via tun0 out ipfw add 4 pipe 4 from any to any via tun0 out (ps: needs net.inet.ip.fw.one_pass=1) then, same process for the input stream : ipfw pipe 100 config bw .. ipfw pipe 101 . 102 . 103 and routing rules using 'in' final clause. This done, each group corresponds to a physical value (the output bandwidth for pipes 0-99, the input one for pipes 100-199). Original dummynet fixed and preserved bandwidth function is kept by using one pipe per group, ie: using pipes number by multiples of 100. If the old config was : ipfw pipe 1 config .... ipfw pipe 2 config .... ipfw pipe 3 config .... the new config would be : ipfw pipe 1 config .... ipfw pipe 100 config ... ipfw pipe 200 config ... The implementation was fairly easy because, fortunetly, pipes are linked in their increasing numbering order so it's just a matter of detecting a cross-100 multiple and relooping in the group to distribute gathered bandwidth during the first pass. There are many possibilities to build priority queing this way (sub-grouping) but it bothers me to have too much hidden semantic in the pipe numbering. a big ipfw rules table is already a good way to get lost. A much cleaner way would be to add a class number in each pipe but it's more computational intensive, aside needing an ipfw modification. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904101543.RAA20807>