Re: [nznog] QoS-IXPs

26 Mar 2009

      Dear Mr. Hall and Mr. Newbery,

thank you for your replies and the current IX setup description. If I 
understand you right, the big majority of the customer base is untagged 
and some (e.g. TCL) is tagged.
---
1. We completely ignore the 802.1p bits on incoming frames.
2. We set the 802.1p bits on all outgoing frames to zero.
---

For the untagged community, 802.1p is of course not available and the 
mentioned features are in place. The switch fabric is over engineered and 
so are the customer ports.
Within this constellation, there is no chance and no need for 802.1p. Full 
stop.

For the remaining (tagged) parties, the over engineering rule applies 
as well and everything works just fine.

Comming to the possible use cases of 802.1p at an exchange.

1) prioritized forwarding in the case of congestion
-> Given the over engineering, this will not happen in the switching
    fabric.
-> Several sources exiting the switch to one customer port can lead to
    congestion in busy hours, which will require a port upgrade.
    With 802.1p, this upgrade could be delayed by some months because
    of the prioritized forwarding. Here is, where the number of queues
    is of interest.

2) QoS-enabled peering with layer 3 DSCPs
    If a peer C distinguishes e.g. 4 DSCPs and peers with A (running 12
    DSCPs) and B (running 3 DSCPs) there needs to be set up a mapping
    between A+C and B+C on how to map the DSCPs arriving at C's port.
    However, neither the IP destination nor the IP source address can
    give C the clue, which peer the arriving packet came from.
    There are two options:
    a) match the sending MAC
    b) agree on the marking in the encapsulating layer, hence the 802.1p.

All that is entirely independant from the CoS concept I am proposing at 
the IETF.
Dylan, you are right, that I am sending class of service marking and 
mapping (DSCP<->EXP<->802.1p<->VC) information within BGP attributes, 
which in the common route server case, will not be been exchanged mutually 
between peers, but rather between the route server and all of its clients.
Those marking attributes are of transitive type with IANA number 0x04 and 
will be relayed by the route server. As of quagga 0.99.10, no extra action 
was required to get the few attribute bytes relayed to the clients.

Again, thank you all for reading and for the posted replies, which I 
hope to have answered in this lengthy post.

Kind regards,
Thomas

On Thu, 26 Mar 2009, Dylan Hall wrote:
...
Speaking with my exchange operator hat on (nzix.net):
None of the NZIX exchanges support QoS at present.
The standard connection to the exchange is an access port (untagged)
which means we have no way of accepting 802.1p information from our
customers.
In the interests of hardening the exchange fabric we use a number of
features (storm control, spanning tree root guard, spanning tree bpdu
guard, port security, etc). Not all of these features are supported on
trunk interfaces[1].
The exchanges are made up of a mixture of Cisco hardware, mostly 29xx
and 35xx switches, but more recently some 3750 and ME-3400 switches.
Most of these switches have only very limited QoS capabilities (2
queues?).
Our approach is to over engineer the exchange fabric so congestion only
really occurs at the customer access port, and that can be addressed by
getting a faster port :)
Another interesting difference between the NZIX and other exchanges is
we operate route servers which most of the exchange participants use so
there are very few bi-lateral peering sessions. We use Quagga on linux
boxes for the route servers. Would we require any special options to be
configured to allow propagation of the CoS BGP attributes?
A couple more general questions:
Why is it necessary to use a layer 2 QoS marking at all? I assume most
of the traffic crossing exchanges is IPv4 with a handful of IPv6 (and
maybe MPLS?), all of which have their own QoS marking schemes
(TOS/DiffServ/EXP).
Are there any special expectations around how QoS marked traffic will be
handled by an exchange?  e.g. minimum/maximum bandwidth, queuing
algorithms (wrr, red), strict queuing etc, number of queues.
[1] This may not be true with recent hardware/IOS revisions, but was
certainly true in the past.
Thanks,
Dylan
On Thu, 2009-03-26 at 03:16 +1300, Brian E Carpenter wrote:
...
On behalf of Thomas Knoll:
---------- Forwarded message ----------
Date: Wed, 25 Mar 2009 02:02:42 +0100 (MET)
From: Thomas M. Knoll 
To: nznog(a)list.waikato.ac.nz
Subject: QoS-IXPs
Dear Sirs,
excuse me please for bothering you with the following information, but I
thought it could be of use for you as well.
Background:
I am currently proposing a class of service signalling extension to BGP in
order to enhance the current best effort AS interconnection into a simple
class-based interconnection.
This primitive traffic separation scheme also encompasses lower layer QoS
schemes in a consistent manner, which makes it attractive for QoS interested
peering partners to meet on peering platforms with Ethernet QoS support.
Therefore, I am trying to find out about Internet exchange points, which would
a least transparently (untouched) transfer user priority bits
across their platform and might even have 802.1p enqueueing and scheduling
enabled on their switches.
Having said that, I will point you to the current QoS capable IXP list on the
web.
http://www.bgp-qos.org/qos-ixp/
Furthermore, if you are interested to be recognized by QoS interested peering
partners as potential peering platform, I would cordially invite you to
register there as well.
http://www.bgp-qos.org/qos-ixp/add.php
Thank you in advance,
Thomas Knoll
_______________________________________________
NZNOG mailing list
NZNOG(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog