[zeromq-dev] QoS support

[Martin Sustrik]

Hi Erich,

AFAIU what you are saying is that there's sense in tagging packets by
different TOSes depending on the message contained in the packet, right?

If so, the problem is that many messages can be sent in a single packet
to gain performance boost. In that case we would have to use highest
priority for such a packet thus giving other messages unfair preference.

As for 1. and 2. can you give a concrete example? My feeling is that our
thoughts are basically in line just that we are expressing them in a
different way.

Martin

There is a strong argument for end-to-end QoS, as opposed to gw-to-gw.
There are two different reasons for this:

> 1.  Better application support -- Provided a host is (fairly) trusted, and
there is a good network admission layer, applications themselves can
internally prioritize their traffic. Instead of requiring 3 connections
managed by the application, it just calls send(...,PRIORITY_X). The
middleware of course could just set up 3 connections, which would
certainly be easy enough. With a QoS integration that is more than just
connection oriented however, there is a benefit from an adminstrative
point of view as well, not needing to know each possible communication
set an application will need/use.

2. Host protection -- ingress and egress rate controls and priority queues
(and etc.) allow critical traffic through, even in the face of a crowded
network, or a crowded network card. Say for example you have a low
priority
task that is generating a lot of traffic, just sending your high priority
packet from the same host without QoS measures on the NIC does not ensure
timely sending, no matter what the network is set up to do. A priority
queue
certainly goes a long way to help this. Example:  I have tc set up on my
home desktop to put torrents in the lowest priority and skype in the
highest, and everything else in the middle. I recently torrented the new
Ubuntu, and it came through very quickly, utilizing as much of my
connection
as it could, however my skye session w/ my sister did not suffer at all.

A final note, when integrating QoS to the endpoints, it opens up a perfect
way to integrate middleware to signal back to the network when QoS is not
being met.

Steven is absolutely correct in that gw-to-gw style QoS does take reduce
the
need to trust every app developer out there, but I think that the gateways
should sanity check edge QoS instead of obviating it.