1 / 11

Localized Congestion Notification -- Conex wg at IETF Maastricht meeting

Localized Congestion Notification -- Conex wg at IETF Maastricht meeting. Lei Zhu. Content. Background Mobile multiplexing and congestion The problems to deploy ECN Proposed conclusions at the moment Backup – technical proposal in the mind. Congestion notification.

teresa
Download Presentation

Localized Congestion Notification -- Conex wg at IETF Maastricht meeting

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. Localized Congestion Notification--Conex wg at IETF Maastricht meeting Lei Zhu

  2. Content • Background • Mobile multiplexing and congestion • The problems to deploy ECN • Proposed conclusions at the moment • Backup – technical proposal in the mind

  3. Congestion notification • ECN (Explicit Congestion Notification) is initiated to prevent drop of packets by notification of early congestion. • congestion indication is expected to reflect queue status based on AQM mechanisms • Conex working is established after main discussions on the use cases of operator tools for dealing with the impact of broadband having serious limitations. • Draft:

  4. Mobile network multiplexing and congestion • As an example of wireless access architecture, 3GPP LTE supports peak data rate 100 Mbit/s DL and 50 Mbit/s UL within a 20 MHz bandwidth; • 3GPP LTE system specifies DL/UL shared channel mapping physical channel. The scheduling and priority handling functions are the multiplexing /demultiplexing of link layer frames belonging to logical channel (s) into/from transport blocks (TB) delivered to/from the physical layer on transport channels • The congestion of wireless access networks would most likely happen since the mobile applications are running out wireless access capacity, in case of the co-existence of 2G/3G/4G networks in 5 years.

  5. The problems to deploy ECN • Dependence on intermediates supports is not well summarized in individual draft. The shared experience sent by Bob Briscoe in 2010-07-14 e-mail in the list well described the problems to be resolved for acceleration of deployment. • One problem for users to implement ECN mechanism is that the supports of ECN mechanisms could not be 100% sure. • Most of Internet applications have to cross multiple networks which may have different strategies. • Upgrading intermediate nodes of running network is a difficult work.

  6. Existing solutions • Brief concepts: • Negotiate the use of ECN mechanism between endpoints. • Use IPv4 TOS or IPv6 Traffic Class Octet to encode one of the ECN values • For TCP, use two flags in the TCP header to signal the sender to reduce the amount of information it sends. NOTE: RTP for ECN solution is to negotiate the use of ECN mechanism notify congestion at application layer.

  7. Proposed conclusions at the moment • The congestion mostly happen at access networks; • Proposed wording “- congestion is mostly in access networks.” • Congestion could be indicated by wireless access nodes which monitor and have capacity information besides queue status introduced in RFC3168; • Proposed wording “- congestion can be extended to be indicated by wireless access nodes besides AQM.” • The dependence on supports in the path interferes the use of the ECN mechanism in some degree; • Proposed wording “- ECN sometimes does not get through certain middleboxes that do not support ECN.”

  8. Backup—solutions in the mind • Highlight: • Negotiation of ECN only for local access network is kept to be OPEN for access network system; • Others: • Use IPv4 TOS or IPv6 Traffic Class Octet to encode one of the ECN values • For TCP, use two flags in the TCP header to signal the sender to reduce the amount of information it sends. • For ECN for RTP, it seems no changes to existing mechanism too. • Impacts on existing solutions • No changes to existing ECN mechanism: • No changes to endpoints, no changes to intermediate nodes • NOTE: only impact on the endpoints and access networks which are proposed to notify localized congestion to endpoints.

  9. Proposal in mind • Scenario I: Congestion notification for TCP traffic (e.g. HTTP) with e2e ECN context established • UL traffic congestion can be indicated to sender (UE) by containing ECT flag in IP headers which is same as definition of RFC3168 Sender Access node Intermediate nodes Routers Receiver ECN negotiation at TCP level LECN negotiation UL congestion HTTP Response HTTP Response (ECT(1)) HTTP Response (ECT(1)) HTTP Response (ECT(1)) TCP Ack (ECN mark) TCP Ack (ECT mark) TCP Ack(ECT mark) TCP Ack (ECT mark)

  10. Proposal in mind con. • Scenario II: Congestion notification for TCP traffic (e.g. HTTP) in case e2e ECN context could not be established • UL traffic congestion can be indicated to sender (UE) by containing ECT flag in IP headers which is same as definition of RFC3168 Sender Access node Intermediate nodes Routers Receiver ECN negotiation at TCP level – failure! LECN negotiation UL congestion HTTP Response HTTP Response HTTP Response HTTP Response TCP Ack TCP Ack TCP Ack TCP Ack (ECT mark)

More Related