Congestion Notification Process for Real-Time Traffic

1
Congestion Notification Process for Real-Time
Traffic

• draft-babiarz-tsvwg-rtecn-04.txt

Jozef Babiarz (babiarz_at_nortel.com) Kwok Ho Chan
(khchan_at_nortel.com) Victor Firoiu
(victor.firoiu_at_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

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

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

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

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

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.

8
Next Steps

• Add support for rate proportional or weighted
  marking
• Address requirement for edge-to-edge solutions
• Address comments

9
Comparison of ECN Semantics
ECN Field ECN Field RTECN RFC 3168
Bit 6 Bit 7 ECN Notation ECN Notation
0 0 Not-ECT Not-ECT
1 0 ECT(0) ECT(0)
1 1 CE(1) CE
0 1 CE(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 1st level
• CE(2) Congestion Experienced at 2nd level