RMD-QOSM - The Resource Management in Diffserv QoS model draft-ietf-nsis-rmd-01

1. RMD-QOSM - The Resource Management in Diffserv QoS modeldraft-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 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 • Advantages: • Standard QoS-NSLP procedure is used • Terminating/pre-empting the required number of flows (congestion %) • DSCP marking is not required • Can be used together with end-to-end ECN marking • 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 cannot 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