Nathan Ward wrote:
Technical point, I would expect that high priority traffic would be limited in capacity on egress, to say 10% of your port. So, they might be able to fill up the remainder of the high priority egress queue on your port, but I doubt they would be able to fill up the entire port.
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.
If people want to organise standard passing of priority bits for non-Internet traffic, then that's all well and good. But I suspect the relationship will have to be very different to the nature of Internet IXes.
I'm going to have to think about this some more before replying - I'm torn.
What's to think about? IXes aren't appropriate places for people to make up and enforce onto others QoS policies which are arbitrary. As I said before - the main reasons are: - No trust - no one should trust my DSCP bits and I'm not trusting anyone elses. - No use - no one uses externally accessible QoS on their Internet networks - No Common policy - what works for me (see example of VOIP provider above) doesn't work for every one and vise versa It really comes down to - what problem are we solving? IXes are big ethernet (usually) fabrics which are about not having a mass of cross connects and ports. I don't expect my cross connects to make packet dropping decisions for me, so I don't expect IXes to either. If people want to bilaterally trust DSCP bits, then that's peachy for them - but the IX isn't the place to enforce it. MMC