Date: Tue, 2 Sep 2008 22:39:16 -0700 From: Lance Murdock <lance@theouterdarkness.com> To: Max Laier <max@love2party.net> Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ & Multiple Connections Message-ID: <20080903053916.GA81677@theouterdarkness.com> In-Reply-To: <200809030444.31690.max@love2party.net> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 03, 2008 at 04:44:31AM +0200, Max Laier wrote: > No and I don't know of any software that would make that > possible - probably because it's a horrible idea. I wouldn't say it is a horrible idea. It may have some implementation details, but the idea of maximally utilizing available resources at minimum cost is not fundamentally horrible. Also, this is for negotiation purposes as much as any technical reason. Our carriers feel there is no need to negotiate on price because they're going to get paid on the overages anyway. They figure the router and construction expenses of pulling in more fiber are pretty much a lock-in, and they're pretty much right. So I'd like to put a shot across their bow that not only do we have the power to control how much they get paid without scuttling our own site, but also we don't need to pull more fiber to do it. :-) > You will run into all kinds of trouble with out > of order packets. Let alone the issues you will have if any of > your ISPs does source filtering, or with asymmetric return paths > and possibly NAT. Source filtering and NAT are not in play here and the two endpoints are not identical but they are topologically very close so asymmetric routing impact should be minimal, especially for short-lived web connections. But yes, I can see that "sticky" behavior on a per-flow basis would be essential. Ideally we would let as much traffic as possible take its best path according to the route table and only shape the minimum necessary to meet our utilization objectives. But even I am confident I have crossed irretrievably into fantasyland at that point. I'm thinking of something along the lines of good old fashioned multilink PPP, which brought up more channels based on utilization. The only difference here is that we're not going to get protocol cooperation from the far end. > The only thing you can do is > some level of *per-flow* round-robin (with weights) onto your outgoing > connections - maybe adjusting the weights according to ALTQ usage stats. I'm sorry, I don't know enough about ALTQ to know if this is intended to be a practical suggestion. If so, where would I look for documentation? I've got the Reed book and it's been massively helpful but doesn't appear to cover the sort of crazy misuse that I have in mind. > But > that's a very rough estimate - but you can't do better than that, anyways. If we can get within, say, 10% that would be a great start. Since carrier standard is 95/5 billing, all we have to do is visibly clip the peaks on an MRTG graph to achieve our objective. Thanks, Lance
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080903053916.GA81677>