RE: QoS selectors (was LAST CALL: IKE)

[Black_David@emc.com]

Steve,

> Several folks have asked for the ability to place traffic with 
> different TOS values on different SAs, which requires that the TOS 
> field (IPv4) and the flow spec field (IPv6) be useable as selectors.

That includes me - see Section 4.1 of RFC 2983.

> If we agree to add this feature, we need the ability to negotiate 
> this in IKE. What I meant to say is closer to what David referred to 
> in his message, i.e., I would anticipate a sender using the 6-bit DS 
> field as an additional selector value (not the ECN bits). I don't 
> think this is affected by the question of whether the interpretation 
> of these bits is uniform across ISPs. The concern is that if these 
> bits really do have an affect on the order of delivery of traffic, 
> then putting different classes of traffic into the same SA has the 
> potential to cause a non-trivial percentage of the (lower priority) 
> traffic to be rejected due to receiver window mismatches.

Use of DSCPs (6-bit DS Field) as selectors is fine as long as the
receiver is not expected to be able to understand/check/verify how
the sender assigned traffic to the SAs.  That does appear to be
the case here (receiver doesn't have to check how sender assigns
traffic to SAs).

One note for selector design - with the exception of "all", masks
or wildcards are not to be used; there will be cases in which multiple
DSCPs are needed in a single selector (e.g., when indicating different
levels of drop preference) - in all such cases, an explicit list
is the right approach.  This is based on the diffserv architecture,
as specified/described in RFCs 2474/2475.

> Now this is 
> not a problem if the bits are inside a tunnel and NOT propagated to 
> the outer header, but then they are not helping out during transit 
> across unprotected nets. I admit to not being familiar with PHIBs, so 
> I'm not sure what the issues are there. I'm also open to suggestions 
> from IPv6 experts about what to do there, for flows.

PHBs are only relevant to this discussion if there's a need for both
ends to understand the QoS-based SA selection, as their purpose is t
provide a network domain-independent representation of traffic QoS classes.

> Mark & Radia suggest that we don't need this facility to be 
> negotiated. I didn;'t understand the arguments until I worked my way 
> through the cases. Now I think I understand the arguments, and 
> basically agree.  Let me try to examine the relevant cases:

[... Analysis snipped, as I basically agree ...]
 
> So, what this seems to suggest is that there is a good use for 
> DiffServ bits (or PHIBs, or whatever) as selectors, but that if one 
> uses them, one need not tell the receiver. Is that right?

That sounds good to me.  I strongly prefer to keep IKE
out of the QoS negotiation business.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------