Re: QoS selectors (was LAST CALL: IKE)

[Mark Duffy <mduffy@quarrytech.com>]

Steve,

I would say that your analysis is basically correct, by my understanding.

I would argue that in tunnel mode it is basically a local matter for the 
sender how it wants to initialize the DiffServ bits in the outer 
header.  It might be "set to k" or "copy from inner" but could also be 
anything else.  So the cases to be considered might be a somewhat different 
set than you have below but the important points are the same.

I do not see a need however for the receiver to know exactly what the 
sender is doing or to know which DiffServ bits to expect on a given SA.  I 
also think there might be significant difficulties in trying to negotiate 
DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the traditional sense 
(described in my earlier email in this thread).  So I would opt for letting 
the sender make a local choice which SA to send on, and all the receiver 
needs to do is support multiple "redundant" SAs.

I added 3 comments in the message below.

--Mark

At 07:42 PM 6/25/2003 -0400, Stephen Kent wrote:
>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. 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 interpretatioon 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. 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.
>
>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:
>
>1. traffic with varying DiffServ bits mapped to one tunnel mode SA, but 
>not copied to the outer header
>         - because the network between the IPsec devices will not see 
> per-packet markings, there would be no addition reordering influence and 
> thus no motivation for separate SAs, hence no need for using these bist 
> as selectors
>
>2. traffic with varying DiffServ bits mapped to one tunnel mode SA and 
>copied to the outer header
>         - this is the obvious case where more significant reordering by 
> the net between the IPsec devices might cause problems (undesirable 
> receiver discards due to receive window mismatches) and what motivated 
> the suggestion to create different SAs for each class of traffic.
>
>3. traffic with varying DiffServ bits mapped to tunnel mode SAs using 
>these bits as selector values, and the bits are copied to the outer header
>even if the nets between the IPsec devices modify the values in the outer 
>header, this would not affect the inner header values and so I think would 
>work as desired. however, it is correct that this could be done 
>unilaterally by the sender using selectors but not telling the reeciver, 
>and still have this work for an SA, unidirectionally. What we would loose 
>is the ability to tell the receiver what we are doing, or not doing, and 
>thus trigger the reciprocal behavior by the responder, if appropriate.

I don't think any reciprocal behavior is needed.  Each sender can do its 
own thing with regard to making sure the desired number of SAa are present, 
and deciding which packets to send on which SAs.  This may offend some by 
its lack of symmetry but then the set of DiffServ values flowing in the two 
directions may not even be symmetrical in the first place.


>4. traffic with varying DiffServ bits mapped to one transport mode SA
>         - as in case 2, the traffic has an increased opportunity to be 
> delivered out of order, causing problems at the receiver. again, this 
> motivates using these bits to select different SAs at the sender.
>
>5. traffic with varying DiffServ bits mapped to transport mode SAs using 
>these bits as selector values if the nets between the IPsec devices 
>modifies the bits, we would have a problem when we tried to match the bits 
>against the selectors at the receiver. if the sender maps the traffic to 
>different SAs, using selectors, but does not tell the receiver, then there 
>would be no problems with mismatches in the SPD checks at the receiver. 
>so, I guess I would agree there here too this could be done by the sender 
>unilaterally and the effect would be OK.

These mismatches in SPD checks at the reciever could be prevented by 
negotiating PHB-IDs (globally meaningful) instead of DiffServ codepoints, 
but then that would break case 3  :-)


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

I think that is right (but I wouldn't call them selectors then).

I would just say that to avoid sequence number problems with packets 
reordered by the DiffServ network "the sender SHOULD use separate SAs to 
send packets whose DiffServ codepoints (in the outermost IP header) place 
them in different  Ordered Aggregates [RFC 3260]"

Keep it simple!


>Steve