Subject: RE: QoS selectors (was LAST CALL: IKE)

From: [email-masked]
Date: Thu, 26 Jun 2003 14:33:34 -0400

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jun 2003 14:03:27 -0700 (PDT)

Just as a general note, the ip6 flowlabel is not
akin to the DSCP. The flowlabel is much more akin
to the 5-tuple. I'm not sure that it's a good idea
to select flows based on it. Or at least via IKE
right now. What is the downside to deferring
saying anything about the flowlabel here?  If it
must be done now, it would be a good idea to run
this all by the authors...

	 Mike

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Jun 2003 18:44:26 -0400

Yes, I think for ipv6 we should be talking about the traffic class field, 
not the flow label.  From RFC 2474, Differentiated Services Field, sect. 3:

    A replacement header field, called the DS field, is defined, which is
    intended to supersede the existing definitions of the IPv4 TOS octet
    [RFC791] and the IPv6 Traffic Class octet [IPv6].

Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 11:33:04 -0400

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