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

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 27 Jun 2003 15:55:09 +0200

hi michael, 

why do you think that it is not a good idea to select qos flows based on the
flow label (3 tuple)?

ciao
hannes

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, June 26, 2003 11:03 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: QoS selectors (was LAST CALL: IKE)
> 
> 
> 
> 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
> 
> [email-masked] 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
>  > [email-masked]        Mobile: +1 (978) 394-7754
>  > ----------------------------------------------------
>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jun 2003 09:25:53 -0700 (PDT)

> why do you think that it is not a good idea to select qos flows based on the

No, my note was merely cautionary. The flow label
as its been standardized is both different than
what I understood being discussed here and has
permuted subtly from the generally understood
meaning before it was standardized. Not really
understanding it fully could lead to a disconnect.
As I said, if the flow label authors feel
comfortable though, I'm satisfied too.

		    Mike