Congestion Notification Process for Real-Time Traffic

1. Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-04.txt Jozef Babiarz (babiarz@nortel.com) Kwok Ho Chan (khchan@nortel.com) Victor Firoiu (victor.firoiu@baesystems.com) TSVWG, 63rd IETF, Aug. 3rd , 2005

2. Supporting Drafts • Submitted the following drafts in support of RTECN • Informational draft explaining a RTECN use case of admission control and preemption • draft-alexander-rtecn-use-cases-00.txt • Informational draft showing simulation results of RTECN used in admission control and preemption • draft-dudley-rtecn-simulation-00.txt • Informational draft, provide analysis of rate proportional and threshold based marking • draft-babiarz-rtecn-marking-00.txt • Draft defining RTP-probe format that is used in the “Use-cases” draft. Was presented in AVT • draft-alexander-rtp-payload-for-ecn-probing-01.txt • Draft defining a SIP precondition that is used in the “Use-cases” draft. Was presented in MMUSIC • draft-alexander-congestion-status-preconditions-00.txt Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

3. Why New ECN Semantics • RFC 3168 defines ECN semantics for all IP packets, specifically the following: • TCP or TCP like congestion control • Specifies AQM method for marking CE • Issues • Real-time flows (voice, video, etc.) do not have the ability to respond to CE in the same way • The measurement method to detect early congestion indication for real-time flows is different • In some deployments, real-time flows require more than one CE level • But the end-to-end objectives of managing traffic level within DiffServ network is achieved Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

4. Status Update • Updated draft to meet requirements in “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field” for safe co-existence of RTECN with the default ECN mechanism. • Traffic that is ECN-capable and non-ECN-capable is marked with the same DSCP and forwarded using the same service class. • Independent metering: • Police (drop) non-conformant non-ECN-capable traffic • ECN mark ECN-capable traffic if specified rate is exceeded • Aggregated metering: (ECN-capable and non-ECN-capable) • Drop non-ECN-capable packets if a specified rate “C” is exceeded • Mark ECN-capable traffic if a specified rate “A” is exceeded • Addressed how real-time inelastic ECN-capable flow will react when it encounters congested router that supports RFC 3168 • RTECN flows get out of the way (is not admitted or is preempted) • Updated Appendix A, example of metering and marking algorithm Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

5. Behavior of ECN-Capable End-System • During establishment of new flow: • Receive CE(1) marked packets • normal priority flow should not be admitted • emergency/situation critical flow, should be admitted • Receive CE(2) marked packets • new flow should not be admitted • For established flows (after the flow is admitted): • Receive CE(1) marked packets • if end-systems have the ability they should reduce their rate, as agreed during session setup • Receive CE(2) marked packets • flow should be preempted Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

6. Detection of Inappropriate Changes to the ECN Field • Provides a method for detecting if end-to-end path is conformant • During session setup, using RTP-probe flow, detect if a: • device falsely modifies ECN bits • device lowers/clears congestion marking (cheating) • congested router marks packets per RFC 3168 • Once the flow is established, detect if a: • device lowers/clears congestion marking (cheating) • congested router marks packets per RFC 3168 Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

7. Workable Approach for RTECN Co-existence • We propose that an amendment to RFC 3168 be considered that would allow non default DS codepoints to be used for indicating alternate ECN semantics with guidance as stated below: • ECN as per RFC 3168 applies to the Default Forwarding PHB '000000‘ • In DiffServ enable networks, DS codepoints are used to indicate the ECN mechanisms • ECN as per RFC 3168 should be used with the AF PHBs. • RTECN should be used with EF PHB. • Class Selector PHBs may use RFC 3168 or RTECN and should be based on traffic characteristic assigned to the PHB. See “Configuration Guidelines for DiffServ Service Classes” for guidance. • As RFC 3168 defines the default behavior, all other mechanisms that are defined should not cause harm to the default ECN behavior or network if the alternate ECN mechanism encounters RFC 3168 marking. Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

8. Next Steps • Add support for rate proportional or weighted marking • Address requirement for edge-to-edge solutions • Address comments Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF

9. Comparison of ECN Semantics • Not- ECT – Endpoints are Not ECN-Capable • ECT(0) - ECN-Capable Transport (Endpoints are ECN-Capable) • ECT(1) - ECN-Capable Transport (Endpoints are ECN-Capable) • CE - Congestion Experienced • CE(1) – Congestion Experienced at 1st level • CE(2) – Congestion Experienced at 2nd level Congestion Notification Process for Real-Time Traffic TSVWG, 63rd IETF