[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS selectors (was LAST CALL: IKE)
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:mat@cisco.com]
> Sent: Thursday, June 26, 2003 11:03 PM
> To: Black_David@emc.com
> Cc: kent@bbn.com; ipsec@lists.tislabs.com
> 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
>
> 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
> > ----------------------------------------------------
>