1 / 8

Diameter Congestion And Filter Attributes

This document presents a supplement to draft-bertz-dime-congestion-flow-attributes-01, focusing on Filter Rules as proposed in RFC 5777. It addresses issues related to congestion management, including the lack of support for Explicit Congestion Notification (ECN) in Filter Rules and discusses the need for effective filters for managing network congestion. Key considerations include the implementation of TCP ECE and CWR filters, classifier support for ECN in RTP over UDP, and the evaluation of existing filters to enhance traffic management. The paper aims to foster discussion on the future of these enhancements within IETF.

meagan
Télécharger la présentation

Diameter Congestion And Filter Attributes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diameter Congestion And Filter Attributes IETF88, Vancouver, BC Lyle Bertz (lyle.t.bertz@sprint.com) Brent Hirschman (brent.hirschman@sprint.com) Supplement to draft-bertz-dime-congestion-flow-attributes-01

  2. RFC 5777 Foundation Filter-Rule ::= < AVP Header: 509 > [ Filter-Rule-Precedence ] ; Condition part of a Rule ; ------------------------ [ Classifier ] * [ Time-Of-Day-Condition ] ; Action and Meta-Data ; -------------------- [ Treatment-Action ] ; Info about QoS related Actions ; ------------------------------ [ QoS-Semantics ] [ QoS-Profile-Template ] [ QoS-Parameters ] [ Excess-Treatment ] ; Extension Point ; --------------- * [ AVP ] • RFC 5777 • Filter–Rule AVP • The basis our work. • Condition/Action design

  3. Congestion Management • Filter-Rule does not support ECN in 2 ways • No AVP to add to condition part to Classify ECN marked traffic • No Congestion-Treatment Action Set (RFC has Excess-Treatment and Treatment-Action AVPs) • We need to build many filters for Congestion Management • How do we know they are working? (Is any traffic captured) • What can we observe on existing filters in order to remove unused ones OR ones deprecated by new filters?

  4. Progress since IETF86 • No real progress in 3GPP UPCON • Struggling with solution • Off-path (OAM) Solution is insufficient • Application layers will continue to push for ECN • Emergency calling, IMS, others • Multipath TCP is ramping up • Need path level congestion marking • Network Coding is seeing progress

  5. Questions for Consideration • Should we add TCP ECE and CWR filters? • Should we add Classifier support for ECN for RTP over UDP (RFC 6679)? • What other extensions like RFC 6679 exist and should they be incorporated? What can we do to progress this Draft?

  6. Background

  7. ECN Specific AVPs • ECN-IP-CodepointAVP (Enumerated) • Specifies the Explicit Congestion Notification codepoint values to match in the IP header. • Use: Place in Filter-Rule’s Classifier • Congestion-Treatment AVP (Grouped) • Similar in design/use to Excess-TreamentAVP • NOTE: Criteria for Congestion or traffic under congestion is out of scope of the AVP specification • Flow-Count AVP (Unsigned64) • Indicates the number of protocol specific flows. The protocol is determined by the filter • Packet-Count AVP (Unsigned64) • Indicates the number of protocol specific packets.

  8. Filter AVPs for maintenance • Two AVPs • Flow-Count AVP (Unsigned64) • Indicates the number of protocol specific flows. The protocol is determined by the filter • Packet-Count AVP (Unsigned64) • Indicates the number of protocol specific packets. • Uses • Use in accounting/reporting to determine if Filter is working as planned • Can be combined with other AVPs to provide rudimentary traffic profile (e.g. bytes per flow, bytes per packet, etc.) • Can be sent in Filter-Rule as prescriptive

More Related