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