AltQ + ng_iface
Hi, I am looking at using pf + AltQ + mpd instead of my original ipfw + dummynet + ppp setup but it seems that ng_iface doesn't have any AltQ hooks :( I had a look at it to see if they could be retrofitted but alas it appears the ng_iface driver is not very much like others (ie no queueing of packets?) so it would need more work.. I could use ppp(8) and do queueing on tun, but I would prefer to use mpd as all of the packet movement is in the kernel which makes sense to me. Does anyone have any patches for this? Or is it just a dumb idea and I should live with ppp(8)? :) Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp2aQMerEHTS.pgp Description: PGP signature
Re: AltQ + ng_iface
Daniel O'Connor wrote: Hi, I am looking at using pf + AltQ + mpd instead of my original ipfw + dummynet + ppp setup but it seems that ng_iface doesn't have any AltQ hooks :( I had a look at it to see if they could be retrofitted but alas it appears the ng_iface driver is not very much like others (ie no queueing of packets?) so it would need more work.. I could use ppp(8) and do queueing on tun, but I would prefer to use mpd as all of the packet movement is in the kernel which makes sense to me. Does anyone have any patches for this? Or is it just a dumb idea and I should live with ppp(8)? :) is there altq for tun or gif? Thanks. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AltQ + ng_iface
Daniel O'Connor wrote: Hi, I am looking at using pf + AltQ + mpd instead of my original ipfw + dummynet + ppp setup but it seems that ng_iface doesn't have any AltQ hooks :( I had a look at it to see if they could be retrofitted but alas it appears the ng_iface driver is not very much like others (ie no queueing of packets?) so it would need more work.. I could use ppp(8) and do queueing on tun, but I would prefer to use mpd as all of the packet movement is in the kernel which makes sense to me. Does anyone have any patches ipfw and dummynet work on ng_iface I believe. Thanks. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AltQ + ng_iface
On Friday 29 July 2005 10:10, Julian Elischer wrote: > >Does anyone have any patches > > ipfw and dummynet work on ng_iface I believe. Well yeah, but dummynet is a little inflexible and can't prioritise ACKs (for example) > is there altq for tun or gif? Yes for tun, rev 1.143 of if_tun.c. No for gif though (that I can tell). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgph4mMKB6eqk.pgp Description: PGP signature
Re: AltQ + ng_iface
Daniel O'Connor wrote: On Friday 29 July 2005 10:10, Julian Elischer wrote: [ ... ] ipfw and dummynet work on ng_iface I believe. Well yeah, but dummynet is a little inflexible and can't prioritise ACKs (for example) Either the "established" or the "tcpflags !syn,ack" keywords in a rule adding matching packets to a high-priority queue ought to do it...? Or perhaps you meant something more specific than just "TCP packets with TH_ACK" set? :-) Anyway, I'm not convinced that trying to classify packets within an established TCP connection in order to place them on different queues is a really good idea, since you're quite likely to reorder the packets by doing so. I'd expect both latency and bandwidth of a TCP connection to suffer very noticably if more than 10% or so of the packets arrive out of order... [ Hmm. I suppose that one could make an exception to the above generalization if URG was set, but the TCP stack already makes an effort to prioritize and deliver out-of-band urgent stuff as quickly as possible, anyway, right? ] -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AltQ + ng_iface
On Friday 29 July 2005 11:02, Chuck Swiger wrote: > Either the "established" or the "tcpflags !syn,ack" keywords in a rule > adding matching packets to a high-priority queue ought to do it...? Or > perhaps you meant something more specific than just "TCP packets with > TH_ACK" set? :-) Hmm, I guess you could make those skip the pipe.. > Anyway, I'm not convinced that trying to classify packets within an > established TCP connection in order to place them on different queues is a > really good idea, since you're quite likely to reorder the packets by doing > so. I'd expect both latency and bandwidth of a TCP connection to suffer > very noticably if more than 10% or so of the packets arrive out of order... The theory is that by prioritising outgoing ACKs you don't cause downstream delays when your upstream is full. eg http://www.benzedrine.cx/ackpri.html > [ Hmm. I suppose that one could make an exception to the above > generalization if URG was set, but the TCP stack already makes an effort to > prioritize and deliver out-of-band urgent stuff as quickly as possible, > anyway, right? ] Maybe, but it doesn't appear to do a particularly good job for a lot of situations :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpLGYTEY7UN8.pgp Description: PGP signature
Re: AltQ + ng_iface
Daniel O'Connor wrote: On Friday 29 July 2005 11:02, Chuck Swiger wrote: Either the "established" or the "tcpflags !syn,ack" keywords in a rule adding matching packets to a high-priority queue ought to do it...? Or perhaps you meant something more specific than just "TCP packets with TH_ACK" set? :-) Hmm, I guess you could make those skip the pipe.. Anyway, I'm not convinced that trying to classify packets within an established TCP connection in order to place them on different queues is a really good idea, since you're quite likely to reorder the packets by doing so. I'd expect both latency and bandwidth of a TCP connection to suffer very noticably if more than 10% or so of the packets arrive out of order... The theory is that by prioritising outgoing ACKs you don't cause downstream delays when your upstream is full. eg http://www.benzedrine.cx/ackpri.html Ah. OK, it makes sense that delaying outgoing ACKs too much would slow things down. So you want to send dataless ACKs at a higher priority than generic big packets full of data, maybe via the "iplen" keyword with "established", look for packets smaller than ~100 bytes? My other thought on this is to wonder about window size and whether that was scaling properly up to a reasonable value, and whether both sides implement a sane network stack, or whether the other side was a windows box looking for quick responses and usage of SACK, rather than BSD (new-reno?) delayed ACKs... [ Hmm. I suppose that one could make an exception to the above generalization if URG was set, but the TCP stack already makes an effort to prioritize and deliver out-of-band urgent stuff as quickly as possible, anyway, right? ] Maybe, but it doesn't appear to do a particularly good job for a lot of situations :) I guess. :-) Getting 25% of the hoped-for max performance under a problematic case isn't so horrible, either, but I suspect other factors were involved, too. A tcpdump would've been informative -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AltQ + ng_iface
Chuck Swiger wrote: Daniel O'Connor wrote: On Friday 29 July 2005 11:02, Chuck Swiger wrote: Either the "established" or the "tcpflags !syn,ack" keywords in a rule adding matching packets to a high-priority queue ought to do it...? Or perhaps you meant something more specific than just "TCP packets with TH_ACK" set? :-) Hmm, I guess you could make those skip the pipe.. Anyway, I'm not convinced that trying to classify packets within an established TCP connection in order to place them on different queues is a really good idea, since you're quite likely to reorder the packets by doing so. I'd expect both latency and bandwidth of a TCP connection to suffer very noticably if more than 10% or so of the packets arrive out of order... The theory is that by prioritising outgoing ACKs you don't cause downstream delays when your upstream is full. eg http://www.benzedrine.cx/ackpri.html Ah. OK, it makes sense that delaying outgoing ACKs too much would slow things down. So you want to send dataless ACKs at a higher priority than generic big packets full of data, maybe via the "iplen" keyword with "established", look for packets smaller than ~100 bytes? I do this to great effect.. consider: two sites connected by links in which teh bottleneck is 200KB/sec (1 E1?) when a lot of data is flowing from 1 to 2 then data from 2 to 1 is also slowed down because the acks have to go through the queues on ingress side of the bottleneck router. I add a dummynet entry on 1, limiting output to 190KB/sec, so that the queue is in dummynet and not the intermediate router, and then allow small ack packets to bypass that queue. As a result the data from 2 to 1 also flows at near capacity, and with a much lower latency. SInce data flows tend to be large packets, I sometimes actually prioitise ALL small packets allowing interactive stuff to bypass ftps etc. and sometimes I do it on both ends. My other thought on this is to wonder about window size and whether that was scaling properly up to a reasonable value, and whether both sides implement a sane network stack, or whether the other side was a windows box looking for quick responses and usage of SACK, rather than BSD (new-reno?) delayed ACKs... [ Hmm. I suppose that one could make an exception to the above generalization if URG was set, but the TCP stack already makes an effort to prioritize and deliver out-of-band urgent stuff as quickly as possible, anyway, right? ] Maybe, but it doesn't appear to do a particularly good job for a lot of situations :) I guess. :-) Getting 25% of the hoped-for max performance under a problematic case isn't so horrible, either, but I suspect other factors were involved, too. A tcpdump would've been informative ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
