Transcript Localized Congestion Notification -

Security Level:
Localized Congestion Notification
--Conex wg at IETF Maastricht meeting
Lei Zhu
www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Content
•
•
•
•
•
Background
Mobile multiplexing and congestion
The problems to deploy ECN
Proposed conclusions at the moment
Backup – technical proposal in the mind
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:
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 3
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
Radio Bearers
BCH
MCH
PCH
DL-SCH
Downlink
Transport channels
ROHC
ROHC
Security
Security
PDCP
RLC
Segm.
ARQ etc
...
Segm.
ARQ etc
CCCH
Logical Channels
Scheduling / Priority Handling
PBCH
PMCH
PDSCH
PDCCH
Downlink
Physical channels
MAC
Multiplexing
HARQ
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.
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 4
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.
R
R
•
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.
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 5
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.
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 6
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.”
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 7
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.
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 8
Proposal in mind
•
Scenario I: Congestion notification for TCP traffic (e.g. HTTP)
with e2e ECN context established
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))
TCP Ack (ECT mark)
TCP Ack (ECT mark)

HTTP Response (ECT(1))
TCP Ack (ECN mark)
TCP Ack (ECT mark)
UL traffic congestion can be indicated to sender (UE) by containing ECT flag in IP
headers which is same as definition of RFC3168
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 9
Proposal in mind con.
•
Scenario II: Congestion notification for TCP traffic (e.g. HTTP) in
case e2e ECN context could not be established
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 (ECT mark)

TCP Ack
TCP Ack
UL traffic congestion can be indicated to sender (UE) by containing ECT flag in IP
headers which is same as definition of RFC3168
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 10
Thank you
www.huawei.com