Brian E Carpenter wrote:
Matthew,
I said earlier that I prefer there to be enough bandwidth. But when there isn't?
Then this won't help because no one's solved the actual issue with QoS on the internet which is about trust. Fundementally the issue is that defining QoS policies at an IX means that a third party is making traffic engineering decisions for me. A third part(y|ies) that I do not trust. Beyond this is the issue that no one trusts packet markings on the internet anyway. How do I know if you behave rationally and mark packets in a meaningful way that abides by some rules that I accept as being valid? Or do you mark all packets as EF on exit from your network to ensure your customers get the best experience? (Heck, I know one ISP that munges the markings to figure out what traffic is domestic peering vs transit). People always seem to focus on the easy bit - which is arbitrarily coming up with rules which can be implemented in an ethernet switch but always seem to come unstuck at the "well, what's the trust relationship?". It's the Internet. There's no trust and the beer is virtual at best. If you've run out of bandwidth TO an IX then dropping packets is your problem. If the IX has run out of switch capacity then I'd suggest selecting a new IX. When I run out or get close I move traffic off of the IX onto PNIs, upgrade ports or join another IX and move traffic there. I don't outsource traffic engineering to other people. MMC
Brian
On 2009-03-28 11:10, Matthew Moyle-Croft wrote:
Brian E Carpenter wrote:
Say I'm a VOIP provider. All of my traffic is voice, so, usually gets high priority markings. Therefore I expect most of my in/outbound traffic is marked as a high priority. You're saying that I need to pay for a 10x bigger port to ensure that I can pass/receive all my traffic correctly without the IX switches dropping it because it doesn't conform.
Actually, to cope with potentially unbounded amounts of audio and video, I don't see a physically possible alternative to traffic policing for conformance with an SLA, unless the SLA allows for 100% of the installed ingress bandwidth to be real-time packets. With this type of traffic, the traditional all-you-can-eat approach to traffic is neither fair nor neutral.
What SLA? As I said in my previous post. IXes are just a subsitute for lots of cross connects etc. Cross connects don't make packet dropping decisions, so neither should an IX. If people are running out of bandwidth on their IX port or the IX fabric then it sounds like more traffic needs to be rolled off onto PNIs.
If people want to bilaterally trust their DSCP bits, then fine - all power to them, but don't enforce some crazy SLA based QOS madness on an IX I want to just pass packets for me.
MMC
Yes, that's a change. But ignoring this problem won't vanish it, IMHO.
Brian