One document matched: draft-you-traffic-distribution-for-bonding-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.zhang-gre-tunnel-bonding SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-gre-tunnel-bonding.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-you-traffic-distribution-for-bonding-00"
ipr="trust200902">
<front>
<title abbrev="Traffic Distribution">Traffic Distribution for GRE Tunnel
Bonding</title>
<author fullname="Jianjie You" initials="J." surname="You">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>China</country>
</postal>
<email>youjianjie@huawei.com</email>
</address>
</author>
<author fullname="Mingui Zhang" initials="M." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>No.156 Beiqing Rd. Haidian District</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>zhangmingui@huawei.com</email>
</address>
</author>
<author fullname="Nicolai Leymann " initials="N." surname="Leymann ">
<organization>Deutsche Telekom AG </organization>
<address>
<postal>
<street>Winterfeldtstrasse 21-27 </street>
<city>Berlin</city>
<code>10781 </code>
<country>Germany </country>
</postal>
<email>n.leymann@telekom.de </email>
</address>
</author>
<author fullname="Cornelius Heidemann " initials="C." surname="Heidemann ">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz-Strasse 3-7 </street>
<city>Darmstadt </city>
<code>64295 </code>
<country>Germany</country>
</postal>
<email>heidemannc@telekom.de </email>
</address>
</author>
<date year="2016" />
<area>Internet Area</area>
<workgroup></workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Traffic Distribution</keyword>
<abstract>
<t>GRE (Generic Routing Encapsulation) Tunnel Bonding as an L3 overlay
tunneling mechanism is used for Hybrid Access (HA) bonding between HCPE
(Hybrid Customer Premises Equipment) and HAG (Hybrid Access Gateway).
The bonding performance depends upon the performance for each individual
link. This document specifies a trying overflow mechanism to avoid the
bonding performance downgrading due to the situation that an individual
link is disrupted or its quality downgrages too much so that the bonding
is no longer applicable.</t>
</abstract>
<note title="Requirements Language ">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Service providers want to supply a higher throughput for their
subscribers to provide a better customer experience, especially in those
cases where customers can only be offered with a low bitrate DSL access.
Bonding of fixed broadband and 3GPP access networks becomes desirable.
<xref target="I-D.zhang-gre-tunnel-bonding"></xref> proposes a GRE
(Generic Routing Encapsulation) tunnel bonding mechanism for bonding of
DSL (Digital Subscriber Line) connection and LTE (Long Term Evolution)
connection. An example of deployment scenario is illustrated in Figure
1. The Hybrid Access (HA) bonded connection is established between the
HCPE (Hybrid Customer Premises Equipment), in the customer premises
network, and the HAG (Hybrid Access Gateway), on the service provider's
network <xref target="WT-348"></xref>.</t>
<figure align="center">
<artwork>
+------+ LTE GRE Tunnel +-------+
+---------+ | +-----------------+ | Internet
|User +----+ HCPE | | HAG +-----
|Equipment| | +-----------------+ |
+---------+ +------+ DSL GRE Tunnel +-------+
Figure 1: GRE Tunnel Bonding</artwork>
</figure>
<t>The bonding should not be enabled if the
bonding performance is worse than DSL only. This document proposes a
traffic distribution algorithm named trying overflow to improve the
bonding performance.</t>
</section>
<section title="Terminology">
<section title="Abbreviations and acronyms">
<t><list>
<t>BRAS: Broadband Remote Access Server</t>
<t>CAR: Commit Access Rate</t>
<t>CIR: Committed Information Rate</t>
<t>HA: Hybrid Access</t>
<t>HAG: Hybrid Access Gateway</t>
<t>HCPE: Hybrid Customer Premises Equipment</t>
<t>LTE: Long Term Evolution</t>
</list></t>
</section>
<section title="Definitions">
<t><list>
<t>Hybrid Access: The bonding of two access paths based on
heterogeneous technologies (e.g., DSL and LTE).</t>
<t>Hybrid Access Gateway: A logical function in the operator
network implementing a bonding mechanism for customer access
services.</t>
<t>Hybrid Customer Premises Equipment: A CPE enhanced to support
the simultaneous use of both fixed broadband and 3GPP access
networks.</t>
<t>Hybrid Access Gateway: A logical function in the operator
network implementing a bonding mechanism for customer access
services.</t>
</list></t>
</section>
</section>
<section title="TCP Throughput Measurement and Issues">
<t>The Quality of Experience (QoE) on a hybrid access service depends
upon the performance of each individual link. Generally, TCP Throughput
(T) for a link can be measured as:</t>
<figure align="center">
<artwork>Throughput <= min (BW, WindowSize/RTT, MSS/(RTT*sqrt(p)) )</artwork>
</figure>
<t>While for hybrid access,</t>
<figure>
<artwork>RTT = max(RTT1, RTT2)
p = w1*p1+w2*p2</artwork>
</figure>
<t>Therein, <list>
<t>BW: maximum bandwidth</t>
<t>WindowSize: congestion window size</t>
<t>RTT: Round Trip Time; RTT1 for DSL link, RTT2 for LTE link</t>
<t>MSS: maximum segment size (fixed for each Internet path,
typically 1460 Bytes)</t>
<t>p: packet loss rate; p1 for DSL link, p2 for LTE link</t>
<t>w: distribution factor; w1 refers to the percentage of total
traffic on DSL link; w2 refers to the percentage of total traffic on
LTE link.</t>
</list></t>
<t>When LTE link becomes congested, the latency may reach up to 400 ms;
while the normal latency on DSL may only be 10 ms. According to the
formula above, the TCP throughput for the hybrid access would be worse
than DSL link only assuming p1 = p2.</t>
</section>
<section title="Traffic Distribution Algorithm">
<t>Principle: Traffic distribution over DSL is prior to traffic
distribution over LTE. The bonding mode would be enabled if the bonding
performance is better than DSL only. Otherwise the bonding should not be
enabled.</t>
<t>CAR (Committed Access Rate) with two token buckets is used to
distribute traffic flows on HA-compliant nodes.</t>
<figure align="center">
<artwork align="center">
+-------+ (RTT2, p2, T2) +-------+
| | LTE GRE Tunnel | |
| +-----------------------+ |
| HPCE | | HAG |
| | +-----+ | |
| +----------+BRAS +------+ |
+-------+ +-----+ +-------+
DSL GRE Tunnel
(RTT1, p1, T1)
Figure 2: Deployment Scenario</artwork>
</figure>
<t>1. Start DSL only, and measure RTT1, p1 and T1 periodically; get
<RTT1_min, p1_min>, <T1_max, RTT1_t1max, p1_t1max>. Here
RTT1_t1max refers to the RTT when the throughput reaches maximum
(T1_max) in a period. Likewise, p1_t1max refers to the p when the
throughput reaches maximum (T1_max) in a period.</t>
<t>2. Estimate the usage of DSL according to RTT1 and P1; If there's no
congestion (i.e. RTT1=RTT1_min and p1=p1_min), bonding is not
enabled.</t>
<t>3. If DSL is congested (i.e. RTT1>RTT1_min or p1>p1_min), start
the "trying overflow" procedure (detailed in Section 5). <list>
<t>1) The bonding mode is on. Tentatively distribute a small amount of traffic
onto the LTE link at the initial stage, assuming CIR2 = LTE_MIN
(minimum committed access rate). LTE_MIN is configurable and its
default value is 64Kbps.</t>
<t>2) Measure the throughput of the bonded links (T12) periodically.
<list>
<t>a) If T12 < T1_max and the DSL link is not congested, the
bonding mode should be off.</t>
<t>b) If T12 < T1_max and the DSL link is congested, the
bonding mode is open, the CIR adjustment (i.e. decreasing) of
the DSL link is triggered.</t>
<t>c) Otherwise, the bonding mode is on. Set CIR1 = T1_max, the
overflow traffic is distributed to LTE tunnel.<list>
<t>i. If the DSL link is not congested and T12 is increasing
rapidly, the CIR adjustment (i.e. increasing) of the DSL
link is triggered.</t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Trying Overflow Mechanism">
<t>The "Trying Overflow" mechanism is implemented using the token bucket
mechanism on, as shown in Figure 3.</t>
<figure align="center">
<artwork>
|
|CIR2=LTE_MIN
|
\|/
+---+----+
+--------+
| | Mark color
|Trying | (Yellow, #1)
|Overflow+---------------------+
|Bucket | |
| | \|/
+---+----+ +---+----+
|Mark color +--------+ Mark color
| (Green) | | (Yellow, #2)
\|/ | +--------------+
+----------+ |DSL | CIR1=T1_max |
|Forward to| |Bucket | \|/
|LTE tunnel| | | +----------+
+----------+ +---+----+ |Forward to|
Mark color | |LTE tunnel|
(Green) \|/ +----------+
+----------+
|Forward to|
|DSL tunnel|
+----------+
Figure 3: Trying Overflow</artwork>
</figure>
<t>• Trying Overflow Bucket: In this step, all the incoming traffic
will be distributed to the trying overflow bucket. Its CIR can be set to
LTE_MIN.<list>
<t>HA node has no knowledge of the quality of the LTE tunnel at
first. If the LTE tunnel is congested, the bonding may impair the
customer experience. So trying overflow is performed. If the trying
is successful, then it means the LTE tunnel can be used for
bonding.</t>
<t>The green packets will be distributed into the LTE tunnel, while
yellow packets of #1 will be put into the DSL bucket.</t>
</list></t>
<t>• DSL Bucket: Its CIR can be set to T1_max. The green packets
will be distributed into DSL tunnel, and yellow packets of #2 will be
distributed into LTE tunnel.</t>
<t>Theoretically, if the LTE tunnel is suitable for bonding, the bonding
TCP throughput T12 will increase continuously; and will exceed T1_max
immediately. Yellow packets of #2 can be continuously observed obviously
in a period of time.</t>
</section>
<section title="Overbooking Considerations">
<t>DSL bandwidth can be overbooked on the BRAS (Broadband Remote Access
Server). Overbooking may cause long delay or high packet loss rate.</t>
<t>When bandwidth downgrading happens on the BRAS due to overbooking,
the CIR of the DSL link needs to be decreased. At that time, the bonding
performance is worse than using DSL only and the DSL link is
congested.</t>
<t>When the bandwidth is restored, the CIR of the DSL link needs to be
increased. At that time, the bonding performance improves, and the
congestion on the DSL link can be relieved.</t>
</section>
<section title="Security Considerations">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&I-D.zhang-gre-tunnel-bonding;
<reference anchor="WT-348">
<front>
<title>BBF WT-348 Part-A: Hybrid Access for Broadband
Networks</title>
<author></author>
<date month="12" year="2015" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:09 |