RE: QoS selectors (was LAST CALL: IKE)

[Michael Thomas <mat@cisco.com>]

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

Black_David@emc.com writes:
 > 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
 > ----------------------------------------------------