Network Working Group L. Yong Ed.
Internet Draft P. L. Yang
Intended status: Standards Track Huawei
Expires: Sept. 2010 March 5, 2010
Enhanced ECMP and Large Flow Aware Transport
draft-yong-pwe3-enhance-ecmp-lfat-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 4, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Yong et al. Expires September 4, 2010 [Page 1]
Internet-Draft Enhanced ECMP and LFAT March 2010
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the BSD License.
Abstract
Internet Traffic has constantly shown the pattern that a very
small amount of the traffic flows generate a high traffic volume
while a significant amount of small flows contribute a small
amount of traffic volume. Differentiating such large flow and
small flow in the packet switched network enables an enhanced
transport method over Equal Cost Multi Paths (ECMP). This draft
describes the enhanced ECMP transport with the large flow
awareness.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................4
2.1. Terminology...............................................4
3. Large Flow Recognition.........................................4
4. Enhanced ECMP Process..........................................5
4.1. Congestion Control........................................7
5. Large Flow Indication..........................................8
6. Backward Compatibility.........................................9
7. Applicability..................................................9
7.1. Link Aggregation Groups..................................10
7.2. The Single Large Flow Case...............................10
7.3. Flow Rate Difference.....................................10
7.4. Multi-Segment Pseudowires................................11
7.5. IP Flows.................................................11
7.6. LSP with Entropy Label...................................11
8. Security Considerations.......................................12
9. IANA Considerations...........................................12
10. References...................................................12
10.1. Normative References....................................12
10.2. Informative References..................................13
11. Acknowledgments..............................................13
Appendix A. Simulation Analysis..................................14
1. Introduction
[FAT-PW] introduces the flow label on the label stack for some
pseudowires (PW) to take the advantage of ECMP transport. The
method inserts a flow label on each packet at ingress PE. The
ECMP process in the packet switched network (PSN) hashes the
label stack that contains the flow label. As a result, individual
flows in a PW can be transported over different ECMP paths. Since
Yong Expires September 4, 2010 [Page 2]
Internet-Draft Enhanced ECMP and LFAT March 2010
the packets that belong to the same flow have the same label
value, the method gets ECMP transport benefit as well as
preserves the ordering of each individual transported IP flow.
However, the traffic over Internet today includes Web browsing
data and audio as well as video/downloading and streaming.
Video/downloading and streaming generates the very high rate
flows compared to Web browsing data/audio. This causes Internet
traffic clearly mixed with huge amount of small flows and small
amount of very high rate flows. Internet traffic analysis [CAIDA]
indicates that, today, ~2% of the top rate ranked flows takes
about 30% of traffic volume while the rest of 98% flows
contribute 70% of traffic volume. As Web HDTV and 3D TV will be
on the Internet, the traffic volume ratio between large and small
flows may be further higher. Although the flow label can
improve the load balancing per the flow basis within a
pseudowire, under such traffic pattern, hash based distribution
is inadequate for satisfactory load balancing.
Hash based distribution ensures any flow to be mapped into only
one of ECMP paths (fixed one) so the flow ordering is preserved
in the transport. However, hash based distribution disperses all
the possible flow identifiers over ECMP paths no matter a flow
exists or not at the time and does not consider individual flow
rate, i.e. it has the nature of stateless distribution. Such
distribution method generates adequate load balancing if the
traffic contains huge amount of flows that have similar flow
rates. The simulation has shown that given Internet traffic
pattern, the hash method does not evenly distribute the flows
over ECMP paths. The load difference between two of ECMP paths
can be significant large; the more ECMP paths exist, the more
severe the un-balancing syndrome presents. This implies that hash
based distribution can cause some path congested and some being
partial filled only. This results that the packets are dropped at
congestion point and the network reroute impacted traffic. In
other words, this syndrome lowers the network performance and
brings operator desires to improve load balancing over ECMP. One
option to prevent such syndrome is to add more transport resource
in the network. But this will lower the network utilization and
increase the service cost.
This draft describes an enhanced ECMP method for such traffic
pattern and also introduces the large/small flow indication on
the flow label to facilitate enhanced ECMP transport in PSN. The
enhanced method uses a table for a small amount of large flow
distribution and hashing on all other flows. The method gets
evenly load balance by maintaining a small set of large flow
Yong Expires September 4, 2010 [Page 3]
Internet-Draft Enhanced ECMP and LFAT March 2010
states. The draft states the process procedures on PE and P
routers.
The simulation result has shown that the enhanced ECMP gets much
better improvement on load-balancing compared to hash based ECMP
under Internet traffic pattern. The load difference among paths
is less than 1%.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2.1. Terminology
Large Flow: a group of packets that contain the same "identity"
in their header and come to the network at a high rate, i.e. the
packet volume per time is high.
Small Flow: a group of packets that contain the same "identity"
in their header and come to the network at a low rate, i.e. the
packet volume per time is very low. Single packet can be
considered as a special small flow in the context of this
document.
3. Large Flow Recognition
The high technology now enables router devices to inspect the
received the packets and identifies the large flows from huge
amount of packets that belong to many flows (both large and
small). Large flow recognition process may use protocol
inspection, flow volume measurement, or other methods to detect
the large flows. If a router can differentiate packets that
belong to the high rate flows from all the received packets, it
can perform differentiated transports for the large flows and
small flows in PSN as described in section 4.
It is possible for hosts to insert a large flow indication on the
packet header. However, there is a huge security concern for a
network to perform on the customer inserted indication.
Typically, a large flow has the context for an entire packet
switched network. It has obvious benefit that if ingress PE
performs the large flow recognition and inserts a large flow
indication on the packets, then all the P nodes within PSN can
Yong Expires September 4, 2010 [Page 4]
Internet-Draft Enhanced ECMP and LFAT March 2010
distinguish the large flow packets by checking this indication.
This can largely reduce the implementation cost and the impact on
the performance.
The native service processing function (NSP) [RFC3985] in the
ingress PE can identify the flow or groups of flows in the
service, and insert the flow (group) identity of each packet
before it is passed to the pseudowire forwarder. When ingress PE
performs large flow recognition, the pseudowire forwarder
[RFC3985] can perform packet inspection and detect the large flow
packets. The design method for the large flow recognition is
outside the scope of this document. The pseudowire forwarder can
insert a large flow indication on all the packets that belong to
the large flow once it is recognized as a large flow. The large
flow indication encoding schema is described in section 5. Since
a large flow comes and disappears when it is transported
completely, the list of large flows could dynamically change.
Large Flow Recognition has the assumption that a large flow
sustains for certain time on the network. This assumption applies
video, streaming, and file download applications. Although
application rate may vary over the time, its lowest rate value is
still much high compared to the small flows. Operator can set the
large flow criteria.
It is worth to mention that a large flow recognition process may
or may not need a time to recognize a large flow. If it needs and
even the time is very short, during this period, some packets
belonging to a large flow may be treated as small flow packets,
which may cause the packets for a large flow traversing different
paths during the transition. Thus this may cause a bit packet
disordering at a destination. To prevent the packet disordering,
Large Flow Recognition Process can use some temporary caching
technology to hold the large flow packets for short time at the
time the flow is recognized as a new large flow. Another factor
to consider is that today packet based applications at the end
points normally have a buffer to deal with packet delay variance
and loss/disordering, thus the seldom disordering during
transport is no longer a BIG issue for Internet traffic. Some
large flow recognition may not need time to detect the large
flow; it does not generate the ordering issue.
4. Enhanced ECMP Process
Label switched routers can implement the enhanced ECMP for
distributing flows over ECMP paths. The enhanced ECMP process
separates the packets that belong to a large flow from the
Yong Expires September 4, 2010 [Page 5]
Internet-Draft Enhanced ECMP and LFAT March 2010
packets that belong to a small flow and applies different
treatments on these two types of packets. The process uses
hashing to select the path from equal cost multi paths for all
the small flow packets and uses a large flow table to select the
path for all the large flow packets. Figure 1 illustrates the
enhanced ECMP processing diagram.
+-------------+ | 4 ECMP Paths
| Small-Flow | |
+--->| Forwarding |--->|=========
+------------+ | | Process | |
Packets| Packet | | +-------------+ |=========
------>| Separation |---+ |
| Process |---+ |=========
+------------+ | +-------------+ |
| | Large-Flow | |=========
+--->| Forwarding |--->|
| Process | |
+-------------+ |
Figure 1 Enhanced ECMP Process Diagram
Figure 1 depicts three function elements. There are four equal
cost paths shown as an example. Small-Flow Forwarding Process is
used for forwarding all the small flow packets, which can be the
same as existing ECMP process. Packet Separation Process and
Larger-Flow Forwarding Process are the new elements in the
enhanced ECMP proposed in this document. The Packet Separation
Process receives all the transported packets and evaluates all
the income packets; it uses the first nibble to distinguish
labeled packets or IP packets. If a labeled packet is marked as a
large flow, it will be sent to Large-Flow Forwarding Process; if
not, it will be sent to Small-Flow Forwarding Process. As a
result, the small flow transport path will be determined by
hashing method; the large flow transport path will be determined
by Large-Flow Forwarding Process. Since this draft focuses on the
labeled packets, IP packet process is described in section 7.5.
Since the bottom label at the label stack (S bit = 1) can be PW
label, LSP label, or Flow Label, it is necessary for Packet
Separation Process to differ Flow Label from PW Label and LSP
Label. Since Flow Label is never on the top of the label stack
and is not processed by the forwarder, it has its unique
position. The draft suggests setting FL TTL to 0. Thus, when S
Yong Expires September 4, 2010 [Page 6]
Internet-Draft Enhanced ECMP and LFAT March 2010
bit =1 and TTL = 0, the label is Flow Label. Otherwise, it is
either PW Label or LSP label.
Large-Flow Forwarding Process uses a flow table for packet
forwarding. The flow table has an entry for each "live" flow.
When the process receives a packet, it retrieves the flow ID from
the packet and performs the table lookup by using flow ID. It
forwards the packets to the path indicated in the table. If the
process does not find an entry that matches the flow ID on a
packet, it calls the path selection algorithm. The algorithm can
select a path for the flow, say A, based on current path load,
i.e. select the path that has least load at the time. Then the
process forwards the packet to the selected path and inserts a
new entry for the flow A in the table. The following packets of
flow A will be forwarded to the path indicated in the table. When
a flow is transported completely, the process no longer receives
the packets that belong to the flow; the age function in the
process can delete the flow entry from the table, which prevents
the table size from the unnecessary growth. The age process
frequency is configurable based on operation needs. If one of
ECMP paths is down the algorithm will map impacted large flows to
other ECMP paths. If a new ECMP path is added, the new flows can
be assigned to the new path; it is optional for the process to
perform the "live" large flow reassignment since the "live" flows
may disappear itself anyway. The design method of Large-Flow
Forwarding Process is outside the scope of this document.
Note: Large-Flow Forwarding Process can work with any hash-key
generation scheme. Large-Flow distribution method using few large
flows effectively compensates the uneven distribution caused by
hashing and traffic pattern. It is worth to mention the
differences between DiffDerv and large and small flow
differentiation. Although both relate to traffic classification,
they aim the different purposes. DiffDerv is for the network to
perform differentiated service treatments. Large and small flow
differentiation is to improve the network utilization in ECMP.
4.1. Congestion Control
The enhanced ECMP also brings an advance in congestion control.
The congestion happens when the traffic volume exceeds the path
capacity. Since the large flows take much more bandwidth,
dropping few large flows can efficiently rescue the congestion
condition and keep the rest of services running normally. As a
result, the congestion control only impacts few services. Large-
Flow Process can easily select the large flows and block them
during the congestion. Whether it is worth to cache these blocked
Yong Expires September 4, 2010 [Page 7]
Internet-Draft Enhanced ECMP and LFAT March 2010
flows or not is for further study and outside the scope of this
document.
5. Large Flow Indication
This draft specifies the protocol to encode a large flow
indication on the flow label specified in [FAT-PW]. Figure 2
illustrates current flow label format [RFC3031] with the
amendment given in [RFC5462]. Label field is filled with the flow
identity. Since the flow label is never on the top of label
stack, TTL field is not used. However, to prevent any
provisioning error, TTL filed is recommended to set as 1. S bit
is used to indicate the bottom of stack and set to 1 for the flow
label. 3 Traffic Class bits are not used in current ECMP
processing now. The document suggests using the first bit in the
Traffic Class bits to indicate the large flow or small flow, and
suggests value 1 for the large flow and value 0 for the small
flow. The two other bits reserve for the future. Figure 3 shows
proposed format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
TC: Traffic Class, 3 bits;
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Figure 2 Current Flow Label Formant
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |F| RV|S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
F: Flow Characteristics Indication, 1 bit;
Yong Expires September 4, 2010 [Page 8]
Internet-Draft Enhanced ECMP and LFAT March 2010
RV: Reserved Bit, set to 0
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Figure 3 Flow Label Format with Large-Flow Indication
When Flow Label is used on a PW, ingress PE can insert the flow
label and a large flow indication on each packet; egress PE will
trim off the flow label before sending the packets to the right
AC. The procedure for informing flow label presence and label
insertion procedure remains the same as [FAT-PW].
TC bits in MPLS Label are typically used for DiffServ purpose.
[RFC3270] [RFC5129] Since Flow Label is never used in the top of
Label Stack, DiffServ function does not apply to the Flow Label.
Hence the proposed Flow Label TC bit usage in this document does
not impact DiffServ function.
6. Backward Compatibility
The enhanced ECMP fully support backward compatibility in PSN. If
ingress PE does not support Large Flow Recognition, it SHALL set
flow label F bit to 0. Then all the flows are treated as small
flows in PSN. P routers with existing ECMP or enhanced ECMP
capability use hashing to discriminate the flows and distribute
those flows over ECMP paths. If ingress PE supports Large Flow
Recognition, it will insert the indication on the flow label. The
P routers with existing ECMP capability will ignore the
indication and just perform hashing on all the flows. The P
routers with enhanced ECMP capability will separate the large and
small flows and perform different treatments as proposed in this
document. Although P router with existing ECMP capability gets
uneven load balancing over its ECMP paths, it maintains the same
performance as today's network. If ingress PE does not support
the flow label on PW, when enhanced ECMP applies, it will treat
PW packets or LSP packets as small flow packets.
7. Applicability
Carriers have desires to improve transport network capability via
certain service awareness in packet transport and not be
constrained in just "pipe" transport service.[FAT-PW]brings such
potential by introducing the flow label in the label stack, which
enables ECMP transport discriminates traffic at flow granularity.
The large flow aware transport further enables ECMP transport to
distinguish the large and small flows and perform different
Yong Expires September 4, 2010 [Page 9]
Internet-Draft Enhanced ECMP and LFAT March 2010
treatments on two types of flows, which can improve the load
balancing when traffic pattern contains very small percentage of
large flows.
The method described in this document requires the new capability
from the PSN and applies to packet switched routers. It requires
ingress PE to perform the large flow recognition and inserts a
large flow indication on the flow label; and P or PE routers
perform the enhanced ECMP function. Since each router node
performs ECMP function independently, a packet switched network
can work well even when some nodes support the enhanced ECMP
capability and some do not. This allows operator to gradually
upgrade the network.
7.1. Link Aggregation Groups
A Link Aggregation Group (LAG) is used to bond together several
physical circuits between two adjacent nodes so they appear to
higher-layer protocols as a single, higher bandwidth "virtual"
pipe. These may co-exist in various parts of a given network. The
enhanced ECMP proposed in this document can assist in producing a
more uniform flow distribution and controlling the congestion in
LAG.
7.2. The Single Large Flow Case
[FAT-PW] has suggested several options for the single large flow
in a PW. With the enhanced ECMP capability, it has beneficial to
insert a flow label even for a single large flow. Then ingress PE
can insert a large flow indication. P routers in PSN can treat it
as a large flow.
7.3. Flow Rate Difference
The enhanced ECMP method uses the different treatments between
large flows and small flows. Neither of treatments considers the
flow rate in the distribution process. This is because that even
load balance is achieved by hashing on the small flows and
selecting the least used the path for a new "live" flow. The
latter distribution using few large flows effectively compensates
the uneven balance caused by the former and is unnecessary to
consider individual flow rate. This is nice that enhanced ECMP
keeps the nature of statistical balancing. Therefore, the
enhanced ECMP method works well even flow rates are broad.
Yong Expires September 4, 2010 [Page 10]
Internet-Draft Enhanced ECMP and LFAT March 2010
7.4. Multi-Segment Pseudowires
The flow label mechanism described in this document works on
multi-segment PWs [MS-PW] without requiring modification to the
Switched PEs (S-PEs). This is because the flow label is
transparent to the label swap operation. There is no need to
perform Large Flow Recognition at Switched PEs.
7.5. IP Flows
Today's ECMP method applies to both IP flows and MPLS labeled
flows in PSN. Typically, Hash method uses IP source and
destination address pair plus other elements to discriminate IP
flows and distribute them over ECMP paths. If PE can insert a
large flow indication in the packets of IP flows, the proposed
method can apply to IP flows as well. IPv6 protocol [RFC2460]
already has the flow label field. 3-tuple: source, destination,
and flow label is used in ECMP.[RFC3697] The method proposed here
meets the restriction on the flow label.[FLOW-ECMP] IETF just
needs to specify one bit in TC field (8 bits) to indicate small
and large flow. By default, all TC bits are set as 0 [RFC2460],
which is compatible to this solution. Although IPv4 protocol does
not have such flow label, IETF can decide if it is necessary to
improve IPv4 protocol to have the large flow indication or just
wait the time for IPv6 to take over. The IP large flow
recognition and indication is outside the scope of this document.
The Packet Separation Process in the enhanced ECMP uses the first
nibble to differentiate IP flows and non IP flows before
evaluating the large flow indication. When PSN does not support
large and small IP flow distinction, the enhanced ECMP treats all
IP flows as small flows.
7.6. LSP with Entropy Label
Entropy Label [Entropy] is inserted in LSP traffic at ingress LSR
to gain better ECMP load balancing at transit LSRs. Entropy label
is very similar as PW flow label and is used to differentiate
"microflow" within a LSP so ECMP process can get better
dispersion granularity. Enhanced ECMP and Large Flow Aware
Transport can apply to LSP with entropy label. Traffic class
field in the Entropy can use the same encoding scheme described
in this document. If ingress LSR does not support large flow
recognition, then it SHOULD set Large Flow indication bit to 0.
The same approach applies to Application Label [RFC4928] as well.
Yong Expires September 4, 2010 [Page 11]
Internet-Draft Enhanced ECMP and LFAT March 2010
8. Security Considerations
Since the number of large flows is very small compared to the
number of small flows; packet switched routers only need to
maintain a small size of table or flow states. Notes operator can
use the large flow criteria to control the large flow volume. The
method won't create the scalability and performance issue.
9. IANA Considerations
IANA is for the further study.
10. References
10.1. Normative References
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiple
protocol Label Switching Architecture", RFC3031, January
2001.
[RFC3270] Faucheur F. Le, etc, "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services", RFC3270, May
2002
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3985] Bryant, S., Pate P., "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to
"Traffic Class" Field", RFC3985, March 2005
[RFC4928] Swallow, G., Bryant, S., and Andersson, L., "Avoiding
Equal Cost Multipath Treatment in MPLS Network",
RFC4928, June 2007.
[RFC5129] Davie, B., Briscoe, B., and Jay, J., "Explicit
Congestion Marking in MPLS", RFC5129, January 2008
[RFC5462] Andersson, L. etc, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: EXP Field Renamed to Traffic
Class Field", October 2009
Yong Expires September 4, 2010 [Page 12]
Internet-Draft Enhanced ECMP and LFAT March 2010
10.2. Informative References
[FAT-PW] Bryant, S., Drafz, U Kompella, V., etc, "Flow Aware
Transport of Pseudowires over an MPLS PSN", draft-ietf-
pwe3-fat-pw-03, (work in progress), Jan. 2010
[Entropy] Kompella K, Amante S., "The use Entropy Labels in MPLS
Forwarding", draft-kompella-mpls-entropy-label-01,
January 2009
[MS-PW] Bocci, M. Bryant, S., "An Architecture fro Multi-Segment
Pseudowire Emulation Edge-to-Edge", RFC5659 October
2009
[FLOW-ECMP] Carpenter B., "Using the IPv6 flow label for equal
cost multipath routing in tunnels", draft-carpenter-
flow-ecmp-01, February 18, 2010
[CAIDA] Caida Internet Traffic Analysis,
www.caida.org/data/monitor
11. Acknowledgments
Authors like to thank Stewart Bryan, Frederic Jounay, Simon
Delord, Raymond Key for the review and suggestions.
Yong Expires September 4, 2010 [Page 13]
Internet-Draft Enhanced ECMP and LFAT March 2010
Appendix A. Simulation Analysis
We create Internet Traffic Generator based on observed Internet
Traffic pattern. The generator randomly generates 98% of small
traffic flows and 2% of large traffic flows up to 10G traffic.
The traffic volume for the large flows and small flows are 30%
and 70%. Simulator uses hash based distribution to disperse the
traffic over 4 paths and 10 paths, respectively; and also uses
enhanced ECMP method to disperse the traffic over 4 paths and 10
paths. The results show the performance between ECMP and enhanced
ECMP from 6 simulations. Enhanced ECMP gets <1% load differences
among paths while ECMP have up to 15% load differences. It shows
how the simple distribution on few large flows can effectively
compensate the uneven load balance caused by hashing and the
traffic pattern.
Yong Expires September 4, 2010 [Page 14]
Internet-Draft Enhanced ECMP and LFAT March 2010
Authors' Addresses
Lucy Yong
Huawei Technologies Co., Ltd.
1700 Alma Dr.
Plano, TX 75075
US
Phone: +14692295387
Email: lucyyong@huawei.com
Peilin Yang
Huawei Technologies Co., Ltd.
No.91, Baixia Road, Nanjing 210001
P. R. China
Phone: +86-25-84565881
EMail: yangpeilin@huawei.com
Yong Expires September 4, 2010 [Page 15]