[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QoS selectors (was LAST CALL: IKE)
At 4:07 PM -0400 6/24/03, Mark Duffy wrote:
>I like Radia's proposal, mainly because I think trying to bind the
>SAs to DSCPs or PHBIDs is likely to become a bit of a rathole and
>really doesn't gain much.
>I don't see why the receiver should care which packets arrive on
>which SA, so long as they match all the (other) selectors.
>Some complications I see with negotiating DSCP or PHBID as a selector:
>. I agree with David that PHBID would be the correct beast to
>negotiate, from the Diffserv perspective. But since PHBIDs require
>a (locally unique) mapping to be translated to the actual bits
>(DSCP) in the packet, it is a bit of a leap for IPsec compared to
>the other selectors where the literal selector bits to be seen on
>the wire are negotiated. Moreover, the mapping from PHBID to DSCP
>may be 1:n, imposing perhaps a significant burden on an
>implementation to evaluate for any of multiple possible DSCP values.
>. For transport mode, the DSCP that the selectors are evaluated
>against is that in the outer (only) IP header. This is mutable and
>hence may be remapped at a Diffserv domain boundary while still
>representing the same semantics as represented by the corresponding
>negotiated PHBID. But for tunnel mode the selectors are evaluated
>against the inner IP header and this DSCP would *not* be mapped at a
>Diffserv domain boundary. This packet might fail at the receiver to
>match the negotiated PHBID. IF we negotiated DSCP instead of PHBID
>we'd just have the opposite problem instead.
The motivation that other had raised, and that I was merely
responding to, is that if one puts traffic with different service
characteristics on one SA, then it is likely that the traffic will
arrive very much out of order and as a result the receiver sequence
window will reject more traffic than under better circumstances. I
don't understand how the comments above address this concern. Could