RE: QoS selectors (was LAST CALL: IKE)

[Stephen Kent <kent@bbn.com>]

At 2:33 PM -0400 6/26/03, Black_David@emc.com wrote:
>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.

In the new model IKEv2 (and soon, 2401bis) have for selectors, all of 
them are represented as a list of ranges, uniformly.

>
>>  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
>----------------------------------------------------