Re: altq on a variable bandwidth interface
* quartz qua...@sneakertech.com [2011-11-26 07:00]: i dunno what is so hard to understand about packet reordering based on priority. prio queueing is best effort, no guarantees. with more effort (towards low delay) for higher priorized traffic. no more, no less. Henning: my original question was that the altq directive appears to require me to type in a bandwidth number in order to even function. you seem to be saying that I can still set up a prio queue even if I don't know the bandwidth that my optical terminal is providing. given this, what do I type into my pf.conf to make this happen? altq priq is a bit more than a simple prio queuer. you can use the first bits of the upcoming queueing system that made 5.0, see the prio keyword in pf.conf but be warned that the syntax isn't set in stone yet and might change. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: altq on a variable bandwidth interface
You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck. that is plain bullshit. I think you are talking about two different things here: Henning Brauer is explaining how queuing and prioritization work in OpenBSD, while the others have in mind those network switches and routers which perform packet switching in hardware. In such devices, input frame or packet is forwarded without any queuing if the output port is not congested. Otherwise, the queues would quickly grow and overrun (and the latency would be higher). This is the only possible thing to do when there are tens or hundreds of interfaces, especially high speed ones. So, it is probably not a good idea to automatically apply knowledge about network hardware to packet switching in general-purpose operating systems.
Re: altq on a variable bandwidth interface
i dunno what is so hard to understand about packet reordering based on priority. prio queueing is best effort, no guarantees. with more effort (towards low delay) for higher priorized traffic. no more, no less. Henning: my original question was that the altq directive appears to require me to type in a bandwidth number in order to even function. you seem to be saying that I can still set up a prio queue even if I don't know the bandwidth that my optical terminal is providing. given this, what do I type into my pf.conf to make this happen?
Re: altq on a variable bandwidth interface
On 11/23/11 20:58, Henning Brauer wrote: * Jussi Peltola pe...@pelzi.net [2011-11-20 04:09]: On Sat, Nov 19, 2011 at 08:58:46PM -0500, quartz wrote: is there a way to set up altq+priq on an internet connection with highly variable/unknown bandwidth? I'd like to create a simple one layer queue system that prioritizes empty ACKs over anything else (always, all the time, no matter the load or congestion). it looks like priq is the way to do this, but all the documentation I can find seems to say you have to type in a hard number, which won't work for my case. This is usually impossible. The packets get re-queued in the modem or whatever device is next to the choke point, and any prioritization you configure becomes useless. Typically the only way around it is to send at a rate slightly lower than the choke point bandwidth, so the buffer of the modem never starts to get utilized. If the bandwidth is variable, you're screwed. this is not true for simple priority queueing. it just reorders the packets. the modem is not supposed to, so your higher priority packets still go out before the later sent lower priority ones. This works only as long as the modem doesn't start to drop packets because its queue is full. If the modem ist not queueing packets, why do you do priorization? Most people use priority queueing because they want short delay on some connections like ssh, VoIP... They don't want the modem to buffer packets at all because that would add delay. This means you can priorize packets only on the bottleneck. however and admittedly: the effect of simple priority queueing isn't all that drastic since your machine only reorders within the packets it has in flight at the given moment (few less even). the combo of the extra buffer and the lower bandwidth link further down the road minimizes the effects - foremost when there is congestion on that slower link. as soon as the modem starts queueing your deley rises (my modem buffers up to 2500ms - try doing VoIP over such a connection). as soon as the modem starts dropping packets (because it has a small buffer or because it gets fed with 100MBit) your priorization won't work anymore, too. You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck.
Re: altq on a variable bandwidth interface
* Christopher Zimmermann madro...@zakweb.de [2011-11-24 12:28]: On 11/23/11 20:58, Henning Brauer wrote: * Jussi Peltola pe...@pelzi.net [2011-11-20 04:09]: On Sat, Nov 19, 2011 at 08:58:46PM -0500, quartz wrote: is there a way to set up altq+priq on an internet connection with highly variable/unknown bandwidth? I'd like to create a simple one layer queue system that prioritizes empty ACKs over anything else (always, all the time, no matter the load or congestion). it looks like priq is the way to do this, but all the documentation I can find seems to say you have to type in a hard number, which won't work for my case. This is usually impossible. The packets get re-queued in the modem or whatever device is next to the choke point, and any prioritization you configure becomes useless. Typically the only way around it is to send at a rate slightly lower than the choke point bandwidth, so the buffer of the modem never starts to get utilized. If the bandwidth is variable, you're screwed. this is not true for simple priority queueing. it just reorders the packets. the modem is not supposed to, so your higher priority packets still go out before the later sent lower priority ones. This works only as long as the modem doesn't start to drop packets because its queue is full. that changes the order how exactly? the only valid point is that the modem drops packets regardless of their priority while we would drop low prio first. If the modem ist not queueing packets, why do you do priorization? that sentence doesn't make any sense at all. Most people use priority queueing because they want short delay on some connections like ssh, VoIP... They don't want the modem to buffer packets at all because that would add delay. This means you can priorize packets only on the bottleneck. sigh. what part in simple priority queueing just reorders packets didn't you understand? however and admittedly: the effect of simple priority queueing isn't all that drastic since your machine only reorders within the packets it has in flight at the given moment (few less even). the combo of the extra buffer and the lower bandwidth link further down the road minimizes the effects - foremost when there is congestion on that slower link. as soon as the modem starts queueing your deley rises (my modem buffers up to 2500ms - try doing VoIP over such a connection). as soon as the modem starts dropping packets (because it has a small buffer or because it gets fed with 100MBit) your priorization won't work anymore, too. wrong. the priorization works just fine. the priorized packets go out before the unpriorized ones. you don't get your desired effect, but that is a whole different story. You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck. that is plain bullshit. it is most effective at the bottleneck, but especially priority queueing - how often do I have to stress this, which just REORDERS PACKETS - has its effects and value no matter where. it does not suffice to guarantee low delay for voip or the like, but that has never been promised. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: altq on a variable bandwidth interface
On Thu, Nov 24, 2011 at 02:21:57PM +0100, Henning Brauer wrote: that changes the order how exactly? the only valid point is that the modem drops packets regardless of their priority while we would drop low prio first. There won't be an appreciable queue on a router that is not next to the choke point. It will just pass the packets toward the modem at whatever rate they come, unless you configure the queue bandwidth lower than the choke point's, invalidating the assumption that the router is not next to the choke point... If the modem ist not queueing packets, why do you do priorization? that sentence doesn't make any sense at all. It makes perfect sense. You control what the modem does with the packets in its queue with marking, assuming the modem actually honors that. Most people use priority queueing because they want short delay on some connections like ssh, VoIP... They don't want the modem to buffer packets at all because that would add delay. This means you can priorize packets only on the bottleneck. sigh. what part in simple priority queueing just reorders packets didn't you understand? It does not reorder much at all if the rate is less than the max. however and admittedly: the effect of simple priority queueing isn't all that drastic since your machine only reorders within the packets it has in flight at the given moment (few less even). the combo of the extra buffer and the lower bandwidth link further down the road minimizes the effects - foremost when there is congestion on that slower link. as soon as the modem starts queueing your deley rises (my modem buffers up to 2500ms - try doing VoIP over such a connection). as soon as the modem starts dropping packets (because it has a small buffer or because it gets fed with 100MBit) your priorization won't work anymore, too. wrong. the priorization works just fine. the priorized packets go out before the unpriorized ones. Since there is not much queue on the machine where you are prioritizing, the packets go out immediately. The prioritized traffic is not any more likely to get delivered, or getting any less delay. It may get ahead of a few packets in case of a burst, but the majority of the queue is in the modem and not affected, and neither is the risk of the packet getting dropped. you don't get your desired effect, but that is a whole different story. You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck. that is plain bullshit. it is most effective at the bottleneck, but especially priority queueing - how often do I have to stress this, which just REORDERS PACKETS - has its effects and value no matter where. it does not suffice to guarantee low delay for voip or the like, but that has never been promised. reordering packets implies that you hold some in a queue, i.e. delay some packets less and some packets more. when does this happen when the actual rate of packets is lower than the queue's max rate? In any case, when your modem's queue is full, which is the case we are talking about here, reordering is 100% useless. The modem randomly drops packets and delaying some packets less than other packets will not make it any less likely that the modem will drop them. The original poster's objective was 1) Utilize the full link bandwidth 2) Prioritize some packets (affecting their risk of getting dropped, and their delay) This is impossible to do if you do not have feedback about the modem's queue, or knowledge of the speed of the link. 2) is possible without 1), assuming that some lower bound of the link speed is known. 1) is obviously possible without any prioritization at all. Jussi Peltola
Re: altq on a variable bandwidth interface
* Jussi Peltola pe...@pelzi.net [2011-11-24 15:18]: On Thu, Nov 24, 2011 at 02:21:57PM +0100, Henning Brauer wrote: that changes the order how exactly? the only valid point is that the modem drops packets regardless of their priority while we would drop low prio first. There won't be an appreciable queue on a router that is not next to the choke point. It will just pass the packets toward the modem at whatever rate they come, unless you configure the queue bandwidth lower than the choke point's, invalidating the assumption that the router is not next to the choke point... you are once again missing the point. the packets arrive reordered at the modem, priority queueing has done its job. If the modem ist not queueing packets, why do you do priorization? that sentence doesn't make any sense at all. It makes perfect sense. You control what the modem does with the packets in its queue with marking, assuming the modem actually honors that. I don't have modems in the path to begin with, but that's a whole different story. your unfounded claims are just that and parts plain don't make any sense. like this. the reordering has already happened at that point. is that really so hard to understand? Most people use priority queueing because they want short delay on some connections like ssh, VoIP... They don't want the modem to buffer packets at all because that would add delay. This means you can priorize packets only on the bottleneck. sigh. what part in simple priority queueing just reorders packets didn't you understand? It does not reorder much at all if the rate is less than the max. wrong. however and admittedly: the effect of simple priority queueing isn't all that drastic since your machine only reorders within the packets it has in flight at the given moment (few less even). the combo of the extra buffer and the lower bandwidth link further down the road minimizes the effects - foremost when there is congestion on that slower link. as soon as the modem starts queueing your deley rises (my modem buffers up to 2500ms - try doing VoIP over such a connection). as soon as the modem starts dropping packets (because it has a small buffer or because it gets fed with 100MBit) your priorization won't work anymore, too. wrong. the priorization works just fine. the priorized packets go out before the unpriorized ones. Since there is not much queue on the machine where you are prioritizing, sigh. you speak as if you knew internals, but your assumptions are off. i just rewrote prio queueing for openbsd, i naturally know the internals - I wrote them. the packets go out immediately. The prioritized traffic is not any more likely to get delivered, or getting any less delay. It may get ahead of a few packets in case of a burst, but the majority of the queue is in the modem and not affected, and neither is the risk of the packet getting dropped. you once again miss the point big time. priorization doesn't have much to do with a fifo queue in some shaby modem. you don't get your desired effect, but that is a whole different story. .. You cannot do any kind of bandwidth shaping, priorization or fair queueing on any link but the bottleneck. that is plain bullshit. it is most effective at the bottleneck, but especially priority queueing - how often do I have to stress this, which just REORDERS PACKETS - has its effects and value no matter where. it does not suffice to guarantee low delay for voip or the like, but that has never been promised. reordering packets implies that you hold some in a queue, i.e. delay hey, news: every packet going thru (or originating at) an OpenBSD machine is in queue at at least one point. another of your basic assumptions which is plain wrong. it's not 1990 any more. you don't PIO-grab a packet at a time off a NIC and process it to completion (i. e. has left the system thru the outgoing NIC). some packets less and some packets more. when does this happen when the actual rate of packets is lower than the queue's max rate? your basic misunderstanding is the wrong assumption that no queueing goes on unless you run an interface at line rate. In any case, when your modem's queue is full, which is the case we are talking about here, sigh. it is what YOU are talking about, based on wrong assumptions. reordering is 100% useless. another unfounded and 100% wrong claim. The modem randomly drops packets and delaying some packets less than other packets will not make it any less likely that the modem will drop them. network devices typically have a simple fifo queue. they don't change packet order. note the typically. there are exceptions. which are exactly that - exceptions. The original poster's objective was 1) Utilize the full link bandwidth 2) Prioritize some packets (affecting their risk of getting dropped, and their delay) no priorization can ever
Re: altq on a variable bandwidth interface
On 2011-11-20, quartz qua...@sneakertech.com wrote: supports DiffServ or 802.1q priority tags. by any chance, is there a utility that comes with 4.9 release or through the ports tree that can use to test this easily? In 4.9 you can use numeric tos values with ping -T or nc -T. In 5.0 you can use numeric values or symbolic names with ping -T, nc -T, or traceroute -t. There is also support for setting/clearing tos bits in PF, but this will be per-state, you can't just set this on empty ACKs.
Re: altq on a variable bandwidth interface
* Jussi Peltola pe...@pelzi.net [2011-11-20 04:09]: On Sat, Nov 19, 2011 at 08:58:46PM -0500, quartz wrote: is there a way to set up altq+priq on an internet connection with highly variable/unknown bandwidth? I'd like to create a simple one layer queue system that prioritizes empty ACKs over anything else (always, all the time, no matter the load or congestion). it looks like priq is the way to do this, but all the documentation I can find seems to say you have to type in a hard number, which won't work for my case. This is usually impossible. The packets get re-queued in the modem or whatever device is next to the choke point, and any prioritization you configure becomes useless. Typically the only way around it is to send at a rate slightly lower than the choke point bandwidth, so the buffer of the modem never starts to get utilized. If the bandwidth is variable, you're screwed. this is not true for simple priority queueing. it just reorders the packets. the modem is not supposed to, so your higher priority packets still go out before the later sent lower priority ones. however and admittedly: the effect of simple priority queueing isn't all that drastic since your machine only reorders within the packets it has in flight at the given moment (few less even). the combo of the extra buffer and the lower bandwidth link further down the road minimizes the effects - foremost when there is congestion on that slower link. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
altq on a variable bandwidth interface
is there a way to set up altq+priq on an internet connection with highly variable/unknown bandwidth? I'd like to create a simple one layer queue system that prioritizes empty ACKs over anything else (always, all the time, no matter the load or congestion). it looks like priq is the way to do this, but all the documentation I can find seems to say you have to type in a hard number, which won't work for my case.
Re: altq on a variable bandwidth interface
On Sat, Nov 19, 2011 at 08:58:46PM -0500, quartz wrote: is there a way to set up altq+priq on an internet connection with highly variable/unknown bandwidth? I'd like to create a simple one layer queue system that prioritizes empty ACKs over anything else (always, all the time, no matter the load or congestion). it looks like priq is the way to do this, but all the documentation I can find seems to say you have to type in a hard number, which won't work for my case. This is usually impossible. The packets get re-queued in the modem or whatever device is next to the choke point, and any prioritization you configure becomes useless. Typically the only way around it is to send at a rate slightly lower than the choke point bandwidth, so the buffer of the modem never starts to get utilized. If the bandwidth is variable, you're screwed. You can try if your modem or other device supports DiffServ or 802.1q priority tags. Some DSL modems do, which helps - DSL has an extra perk of the extra headers causing more overhead for small packets, so you need a shaper that can account for that, or you need to configure the max rate lower than what the line is capable of with large packets.
Re: altq on a variable bandwidth interface
The packets get re-queued in the modem or whatever device is next to the choke point, and any prioritization you configure becomes useless. yeah, I hadn't really thought of it that way, but that makes sense. You can try if your modem or other device it's an optical terminal connected to a fiber line in this case, if that helps any. supports DiffServ or 802.1q priority tags. by any chance, is there a utility that comes with 4.9 release or through the ports tree that can use to test this easily?
