Homenet Working Group M. Cullen
Internet-Draft Painless Security
Intended status: Informational M. Zhang
Expires: April 21, 2016 Huawei Technologies
October 19, 2015
Considerations for Bandwidth Aggregation
draft-mrc-banana-considerations-00
Abstract
This document lists a number of architectural and technical topics
that should be considered in the design and implementation of
Bandwidth Agregation mechanisms.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cullen & Zhang Expires April 21, 2016 [Page 1]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is Bandwidth Aggregation? . . . . . . . . . . . . . . . 3
3. Taxonomy of Solutions . . . . . . . . . . . . . . . . . . . . 3
3.1. Tunnel-Based Solutions . . . . . . . . . . . . . . . . . 3
3.2. Per-Packet vs. Per-Flow Multiplexing . . . . . . . . . . 3
4. Considerations for All Solutions . . . . . . . . . . . . . . 4
4.1. Link Characteristics and Performance . . . . . . . . . . 4
4.2. Bypass Traffic . . . . . . . . . . . . . . . . . . . . . 4
4.3. Capped or Tariffed Interfaces . . . . . . . . . . . . . . 4
4.4. Learning from History (Multilink PPP) . . . . . . . . . . 4
5. Considerations for Tunnel-Based Solutions . . . . . . . . . . 5
5.1. Tunnel Overhead . . . . . . . . . . . . . . . . . . . . . 5
5.2. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Fragmentation Issues . . . . . . . . . . . . . . . . 5
5.2.2. Issues with MTU Changes . . . . . . . . . . . . . . . 5
6. Considerations for Per-Packet Solutions . . . . . . . . . . . 5
6.1. Packet Ordering . . . . . . . . . . . . . . . . . . . . . 5
6.2. Transport Layer Algorithms . . . . . . . . . . . . . . . 5
7. Considerations for Per-Flow Solutions . . . . . . . . . . . . 6
7.1. Granularity Issues . . . . . . . . . . . . . . . . . . . 6
7.2. Aggregated Flows . . . . . . . . . . . . . . . . . . . . 6
7.3. Encrypted Traffic . . . . . . . . . . . . . . . . . . . . 7
8. Practical Considerations . . . . . . . . . . . . . . . . . . 7
8.1. Use Available Information . . . . . . . . . . . . . . . . 7
8.2. Theory is No Substitute for Experience . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Binding Tunnel Endpoints . . . . . . . . . . . . . . . . 7
10. Appendix A: List of Solutions . . . . . . . . . . . . . . . . 7
10.1. Multilink PPP . . . . . . . . . . . . . . . . . . . . . 8
10.2. GRE Tunnel Binding . . . . . . . . . . . . . . . . . . . 8
10.3. LISP-Based Solution . . . . . . . . . . . . . . . . . . 8
10.4. MIP-Based Solution . . . . . . . . . . . . . . . . . . . 8
10.5. MP-TCP-Based Solution . . . . . . . . . . . . . . . . . 8
11. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
There are currently several bandwidth aggregation solutions being
discussed within the IETF or other parts of the Internet industry.
This document discusses a number of technical and architectural facts
that should be considered in the design and implementation of those
solutions. This document is intended to provide useful information
to the community, not to state requirements or advocate for a
particular solution.
Cullen & Zhang Expires April 21, 2016 [Page 2]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
There is one simple thought underlying many of the considerations in
this document: the goals of bandwidth aggregation are to increase the
effective bandwidth available to customers and improve the
reliability of customers' Internet access by using all of the
available links, not just one of them. Intuitively, two links should
have more bandwidth and reliability than one link, but experience
shows that it is actually quite hard to design a bandwidth
aggregation solution that will achieve the desired goals in all
cases, and quite easy to design a solution that will reduce the
effective bandwidth or decrease the reliability of Internet access in
an unacceptably high number of cases. Many of the considerations in
this document are intended to point out why that happens, so that
solutions and implementations can avoid known pitfalls in this area.
[Note: This document is a work in progress. Feedback on the existing
content is welcome, as well as feeback on other considerations that
should be included. Please send any feedback to the Bandwidth
Aggregation mailing list: banana@ietf.org]
2. What is Bandwidth Aggregation?
[TBD]
3. Taxonomy of Solutions
This section attempts to catergorize bandwidth aggregation solutions
along several axes, providing a taxonomy tbat we can use to describe
and reason about individual solutions. [Note: This section is
largely TBD.]
3.1. Tunnel-Based Solutions
Many of the Bandwidth Aggregations currently under discussion are
tunnel-based solutions. They tunnel traffic over the links that are
being aggregated, and recombine the traffic on the remote end.
[Insert ASCII image of tunnel-based approach.]
There is at least one proposal for Bandwith Aggregation (the MP-TCP-
based approach) that does not use tunnels. The considerations for
tunnel-based solutions listed below may not apply to non-tunnel-based
solutions.
3.2. Per-Packet vs. Per-Flow Multiplexing
The solutions currently under discussion use several different
methods to determine which traffic will be sent over which interface.
Cullen & Zhang Expires April 21, 2016 [Page 3]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
These methods can be grouped into two categories: per-packet
multiplexing and per-flow multiplexing.
Per-packet multiplexing aggregates the bandwidth by sending the
desired proportion of packets over each interface. In these
solutions, packets from single flow (such as a TCP connection) may be
split across multiple interfaces and will need to be recombined at
the remote end. However, the ability to multiplex on a per-packet
basis makes it possible to most precisely apportion traffic across
the available bandwidth.
Per-flow multiplexing involves choosing a single interface for each
flow (i.e. TCP connection or application session) and sending all of
the packets for a single flow across that interface. In these
solutions, the flow do not need to be combined on the remote end.
However, the ability to balance traffic between multiple links may be
limited if there are only a small number of traffice flows active.
4. Considerations for All Solutions
This section desribes potential issues that should be considered in
the design and implementation of all bandwidth aggregation solutions.
4.1. Link Characteristics and Performance
4.2. Bypass Traffic
4.3. Capped or Tariffed Interfaces
In some cases, bandwith aggregation may be performed between
dedicated links and links that have traffic caps or tarifs associated
with additional use. In these cases, customer may want to use
bandwidth aggregation to increase the performance of some
applications, while other applications (e.g. firmware upgrades or
content downloads) may be limited to using the dedicated link.
Solutions that wish to support this capability will need to support
having a set of traffic that will be distributed using the bandwidth
aggregation algorithms, and a set of traffic that will not.
4.4. Learning from History (Multilink PPP)
The IETF has a venerable, standard, implemented solution to this sort
of problem: Multilink PPP. Unfortunately, it is commonly said that
experience with Multilink PPP did not find that it increased the
effective bandwidth when it was used to share two indentical ISDN
lines, compared to the bandwidth that was achieved from using only
one line...
Cullen & Zhang Expires April 21, 2016 [Page 4]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
[Note: We should attempt to determine if this is true and, if so,
find any research papers or other documentation that might help us
understand why this was true, so that we might learn from history.]
5. Considerations for Tunnel-Based Solutions
5.1. Tunnel Overhead
Tunneling involves more overhead than sending non-tunnelled traffic
for two reasons: the extra IP and tunnel headers that must be
included in each packet, and any tunnel management traffic that must
be exchanged. This means that, in order to achieve increased
effective bandwidth by aggregating traffic across more than one link,
the raw bandwidth across multiple links must be higher than the
bandwidth on a single link by a large enough margin to compensate for
the tunnel overhead, so that increased effective bandwidth will
result.
5.2. MTU Issues
There are a number of MTU Issues associated with all tunneling
mechanisms, and there is a different set of MTU issues associated
with any mechanism that changes the MTU of packets within a given
flow.
[Note: This section is TBD.]
5.2.1. Fragmentation Issues
5.2.2. Issues with MTU Changes
6. Considerations for Per-Packet Solutions
6.1. Packet Ordering
6.2. Transport Layer Algorithms
There are transport layer congestion control algorithms implemented
in every TCP/IP stack. It is the purpose of these algorithms to ramp
up the speed of a TCP connection slowly, and to back off at the first
sign of congestion (i.e. packet loss). There are also algorithms
which are designed to detect packet loss as quickly as possible by
analyzing the protocol round-trip times, and deciding that a packet
has been lost whenever there is a longer delay than expected before
an acknowledgement is received. Per-packet solutions run the risk of
interacting pathologically with these algorithms.
Cullen & Zhang Expires April 21, 2016 [Page 5]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
For example, if traffic from a single flow is being demultiplexed
across two links with significantly different round-trip times (i.e.
differnt latencies), the TCP retransmission algorithms may be
triggered for packets that traverse the higher latency link. This
may cause the TCP congestion control algorithms to inaccurately
detect congestion (even when neither link is congested) and slow down
the speed of the TCP connetion. In these cases, the throughput of
each TCP connection may be reduced, thus reducing the performance of
a customer's applications to the point where their applicaitons would
have run faster over a single link.
This problem can potentially be avoided by avoiding aggregation of
links with significantly different latencies. However, it may be
desirable to perform bandwidth aggregation across those links in some
cases.
7. Considerations for Per-Flow Solutions
This section describes some potential issues that should be
considered in the design of per-flow bandwidth aggregation solutions.
7.1. Granularity Issues
Per-Flow demultiplexing is in widespread use for traffic engineering
and load balancing in carrier and corporate networks. Within those
networks, there are a very large number of flows, so being able to
direct traffic on a per-flow basis will generally be sufficient to
achieve acceptable load-balancing or link aggregation.
However, the number of flows generated by a single home or small
office might not provide sufficient granularity to achieve the desire
level of bandwidth aggregation. Also some flows, such as streaming
video flows, might use far more bandwidth than other, such as
downloading a single image on a web page. It is not always possible
to predict which flows will be high-bandwidth flows, and which will
require less bandwidth.
7.2. Aggregated Flows
Some Internet flows are aggregated into single, larger flows at the
end-nodes. This would include VPN traffic that is tunnelled to a
corporate intranet, or other tunnelled traffic such as Teredo traffic
for IPv6. Use of these mechanisms can prevent proper classification
of traffic into separate flows, thus exacerbating the granularity
issues described above.
Cullen & Zhang Expires April 21, 2016 [Page 6]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
7.3. Encrypted Traffic
In some cases such as secure VPN traffic, the contents of packets may
be encrypted in a way that does not allow a middlebox to see the
transport-layer flow inforamtion (such as TCP or UDP ports). In
these cases, it might not be possible to properly separate multiple
flows between a single set of endpoints. This can exacerbate the
granularity issues described above.
8. Practical Considerations
8.1. Use Available Information
In many of the environments in which these mechanisms will be
deployed, there is already considerable informaiton available about
link quality, lost packets, traffic loads and effective bandwidth.
It is possible to use that information to actively tune a bandwidth
aggregation solution to achieve optimal effective bandwidth. This
information can also be used to detect situations in which the link
quality of a secondary link is not sufficient to provide enough
additional bandwidth to compensate for the bandwidth aggregation
overhead.
8.2. Theory is No Substitute for Experience
Because of the complexity of the algorithms implemented at multiple
layers of the TCP/IP Stack, many things that would appear to work in
theory or in limited simulation do not have the expected results when
deployed in a real-world environment. Therefore, it would be highly
desirable to have real-world experience running a bandwidth
aggregation mechanism in an operational network before standardizing
it within the IETF.
9. Security Considerations
9.1. Binding Tunnel Endpoints
10. Appendix A: List of Solutions
This is a (possibly incomplete) list of current or proposed solutions
for Bandwidth Aggregation. The descriptions in this section (when
present) were provided by the proponents of each solution. This list
is provided only as a source of information about possible solutions,
not as a recommendation for or against any of these solutions.
[Note: Insert information from Google Doc in this section.]
Cullen & Zhang Expires April 21, 2016 [Page 7]
Internet-Draft Considerations for Bandwidth Aggregation October 2015
10.1. Multilink PPP
10.2. GRE Tunnel Binding
10.3. LISP-Based Solution
10.4. MIP-Based Solution
10.5. MP-TCP-Based Solution
11. Informative References
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
DOI 10.17487/RFC6126, April 2011,
<http://www.rfc-editor.org/info/rfc6126>.
Authors' Addresses
Margaret Cullen
Painless Security
14 Summer Street, Suite 202
Malden, MA 02148
USA
Phone: +1 781 405-7464
Email: margaret@painless-security.com
URI: http://www.painless-security.com
Mingui Zhang
Huawei Technologies
Email: zhangmingui@huawei.com
Cullen & Zhang Expires April 21, 2016 [Page 8]