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, 63 rd IETF, Aug. 3rd, 2005

2. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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

3. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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

4. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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

5. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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

6. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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

7. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF 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.

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

9. Aug. 3, 2005Congestion Notification Process for Real-Time Traffic TSVWG, 63 rd IETF Comparison of ECN Semantics ECN FieldRTECNRFC 3168 Bit 6Bit 7ECN Notation 00Not-ECT 10ECT(0) 11CE(1)CE 01CE(2)ECT(1) 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 1 st level CE(2) – Congestion Experienced at 2 nd level