QoS considerations

[Black_David@emc.com]

> I'd prefer to hear from QoS people on this.

I guess I count as one of the "QoS people" (e.g., I'm one
of the authors of a number of diffserv RFCs), even if it
did take me a while to catch up to the email on this topic.

The place to start is RFC 2983, which (among other things)
takes up the issue of QoS differentiation vs. IPsec
replay windows for diffserv.  Quoting from Section 4.1:

   If reordering-based [QoS] differentiation is desired within
   such tunnels [e.g., IPsec], multiple parallel tunnels
   between the same endpoints should be used.

[text in square brackets added for clarity in this post]
In other words, a separate SA (and specifically a separate replay
window) should be used for each of the QoS levels among which
QoS reordering is desired/allowed between the tunnel endpoints.
Early in this discussion, an assumption showed up that a sender
[tunnel ingress node]:

	a) would request for the ESP traffic the same priority
		level as the highest priority among the different
		data streams,

This is in about the same category as an assumption that an
IPsec implementation would encrypt all IP traffic passing
through it -- this depends on the problem one is trying to solve
and the network environment in which one is trying to solve it.
While there are situations in which it is appropriate, there
are also situations in which it is clearly not appropriate.

Similarly, the assertion that "IKE is nothing more than a
virtual wire establishment protocol" is also sometimes
appropriate for thinking about QoS, and sometimes not --
see RFC 2983 for a more comprehensive discussion.  There
are situations in which it's appropriate to perform QoS
traffic conditioning within a tunnel and have the results
visible beyond the egress.

QoS negotiation via IKE is also sometimes appropriate.
For a single-direction SA (as is the case for IKEv1), QoS
negotiation is not necessary for diffserv; the sender applies
the appropriate DSCP marking/traffic conditioning and that's
that.  For a bidirectional SA pair (as IKEv2 proposes), obtaining
consistent QoS in both directions is often desirable and
negotiation can help.  For diffserv, PHBIDs should be negotiated
(see RFC 3140), not DSCPs.  A worked example of DSCP negotiation
for a similar bidirectional scenario can be found in L2TP - see
draft-ietf-l2tpext-ds-05.txt for details and some text
than can probably be reused.

IPsec currently makes QoS for tunnels somewhat difficult, as
RFC 2401 requires copying the DSCP from the inner header
to the outer header on tunnel ingress, and discarding it 
at tunnel egress, even if it's been changed.  This is
overly severe, and I believe/hope that it will be made more
flexible in the new version of RFC 2401.  See RFC 2983 for a
longer explanation of what the QoS folks would like to see,
but a quick summary is:
- Copy inner DSCP to outer DSCP on ingress, but allow traffic
	conditioning on the outer header (e.g., to set the DSCP
	to some fixed value) afterwards if desired/appropriate.
- On egress allow static selection (per SA) whether to use
	the inner or outer DSCP on traffic emerging from the tunnel.
Allowing use of the outer DSCP does raise additional security
concerns - these are discussed in the Security Considerations
sections of RFC 2983 (as well as 2474 and 2475).

Finally, RSVP is also in the "sometimes appropriate" category
- by now, this theme should be clear.  RSVP is a useful tool
 in some situations, but it doesn't handle admission control
by itself, and one cannot count on it always being available
or appropriate to use.  Relying on RSVP as the only solution
to providing QoS will result in not being able to support
QoS in many network environments.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------