1. RMD-QOSM - The Resource Management in Diffserv QoS model draft-ietf-nsis-rmd-01
A. Báder, L. Westberg, G. Karagiannis,
C. Kappler, T. Phelan, H. Tschofenig

2. Outline Updates in the document Congestion notification
Security consideration

3. Major updates in –01 version
Title, terminology changed following the discussions regarding the QSpec Template draft
‘3.2 Basic features of RMD-QOSM’section was completed, redundant texts were removed from next sections
<Hop Count> PHR and PDR control info was changed for <NSLP Hops> and <Max NSLP Hops>
New control info added: <PDR Nonce>
Security considerations were included

4. Severe congestion X Severe congestion (overload,
Stateful edge
Stateless
interior
Severe congestion (overload,
edge node should be notified,
fast reaction is needed)

5. Conditions for severe congestion
Severe congestion: due to link/router failure rerouting causes (up to 100%) overload in the new path
Queues are over-floated, packets may be dropped
Packet drop cannot be tolerated, terminating/preempting flows are needed
Marking based on rate (for inelastic traffic) or queue length (for elastic traffic) measurement
Decision is done in the edge node, reaction only if a threshold is exceeded
Desirable time frame to restore normal operation: seamless handover requirements for inelastic traffic, e.g. 200 ms

6. Congestion notification, proposed solutions
DSCP remarking of data packets, proportional marking
Advantages:
Fast response (~100 ms)
Terminates or pre-empts the required number of flows (estimation of the per flow congestion percentage)
Standard Diffserv procedures used
Can be used both for elastic and inelastic traffic
Can be used together with end-to-end ECN marking
Disadvantage: requires 2 DSCPs per PHB
QoS-NSLP refresh messages
Standard QoS-NSLP procedure is used
Terminating/pre-empting the required number of flows (congestion %)
DSCP marking is not required
Disadvantage: slower response than in case of data marking (depending on the frequency of refresh messages)

7. Other proposals (discussion initiated by David Black)
ECN marking, RFC 3168
Advantages
Uses standard ECN procedure
DSCP remarking is not required
Problems
End-to-end scope, cannot be over-defined for local (edge-to-edge) use
Can be used only for elastic traffic
Terminating/preempting the required number of flows to solve the congestion is difficult (no indication of the per flow congestion percentage)
Discovering if end points are ECN capable

8. ECN marking, probes
Using RFC 3168 in a local domain, sending ECN probe packets
Advantages
Uses standard ECN procedure
DSCP remarking is not required
Disadvantages
Slow response (depending on the frequency of probes)
Additional load to network
No association between probes and the end-to-end sessions
Terminating/preempting the required number of flows is difficult (no indication of the per flow congestion percentage)
How to distinguish between probe packets and other ECN packets?
Using ECN additional procedures needed:
Discovering if Ingress and Egress are ECN capable
Define the probe packets

9. ECN for real-time traffic
draft-babiarz-tsvwg-rtecn-03
Advantages
Can be used for real-time, rate based measurement
DSCP remarking is not needed (but there are open issues)
Problems
Not standard yet
Terminating/preempting the required number of flows is difficult (no indication of the per flow congestion percentage)
Cannot be used for elastic traffic
How to distinguish between end-to-end and edge-to-edge ENC marked packets?
Open issues (raised in TSVWG):
Additional DSCPs may be needed to separate traffic (sharing the same PHB but) using or not using ECN
If a router is not Diffserv aware, how to separate ECN 3168 and rt ECN

10. Security considerations
Constraints:
No per flow states within the domain, no reverse routing state
Threats:
Injecting signaling messages by off-path, on-path non-NSIS nodes
Injecting messages by on-path NSIS nodes
Remarking of packets to indicate severe congestion
Possible security solutions:
Protection of edge-to-edge messages to limit signaling protocol interaction with nodes within the domain
Consistency checks: identify and check fields that cannot be changed, RII, PDR NONCE, consistency between intra-domain and inter-domain messages
Intrusion detection to deal with malicious node (packet data marking)

11. PDR Nonce
Protection against injection of fake RESPONSE messages in the RMD domain
Intra-domain RESPONSE’ is included into e2e RESPONSE as additional object
RII can not be used because RESPONSE carries e2e RII
Solution:
QNF ingress includes “PDR Nonce” into intra-domain RESERVE’
QNF egress includes the same “ PDR Nonce” into intra-domain RESPONSE’
Is this a good solution?
Reinvent the same mechanism (functionally identical to RII)?
Shall we define a new object in QoS-NSLP for edge-to-edge security?
QNF QNF QNF QNF
ingress interior interior egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
>| RESERVE | | |
>|
| RESERVE' | | |
>| | |
| | RESERVE' | |
| >| |
| | | RESERVE' |
| | >|
| | | | RESERVE
| | | >
| | | | RESPONSE
| | | |<
| | RESPONSE (RESPONSE’) |
|<
RESPONSE| | | |
< | | | |

12. Plans for next version
Work on severe congestion handling by refresh procedure, investigate the real-time ECN marking
Complete bi-directional reservation section
Complete security considerations
”PDR Nonce” and impact on QoS-NSLP