Re: [hiaps] Hybrid access bar bof

Mingui Zhang <zhangmingui@huawei.com> Fri, 31 July 2015 05:57 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: hiaps@ietfa.amsl.com
Delivered-To: hiaps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAE81B31DB; Thu, 30 Jul 2015 22:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H38lAiGSGG1; Thu, 30 Jul 2015 22:57:08 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094461B31C2; Thu, 30 Jul 2015 22:57:03 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml406-hub.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT60149; Fri, 31 Jul 2015 00:56:59 -0500 (CDT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 31 Jul 2015 06:54:58 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 31 Jul 2015 13:54:54 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, "pierrick.seite@orange.com" <pierrick.seite@orange.com>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [hiaps] Hybrid access bar bof
Thread-Index: AQHQygnqcIGgvNfbVkmYI0otgc11bJ3yEwIAgAEF1oCAAAPtAIAABz8AgAGu03A=
Date: Fri, 31 Jul 2015 05:54:53 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E78714E2A5@nkgeml512-mbx.china.huawei.com>
References: <A0D8C382-41E4-4247-93E2-04E8AFE1D550@gmail.com> <05C81A773E48DD49B181B04BA21A342A30F4A7DCE5@HE113484.emea1.cds.t-internal.com> <CAC8QAceEzk3fFuXcVveJh3a6+v8AEDxmG3pZ8DwnHN9kuyiK9A@mail.gmail.com> <05C81A773E48DD49B181B04BA21A342A30F4A7DD6E@HE113484.emea1.cds.t-internal.com> <BE651590-570B-4552-B453-EA6B8EB8A740@gmail.com> <05C81A773E48DD49B181B04BA21A342A30F4A7DDE2@HE113484.emea1.cds.t-internal.com> <05C81A773E48DD49B181B04BA21A342A30F4B0E99E@HE113484.emea1.cds.t-internal.com> <55B8E16C.9090304@uclouvain.be> <CAC8QAceVgwFH0fzbnDvE9upDtnSc=M8h2JJr4sU53YXco15pZQ@mail.gmail.com> <17487_1438241390_55B9D26E_17487_305_1_81C77F07008CA24F9783A98CFD706F71160E8F24@OPEXCLILM22.corporate.adroot.infra.ftgroup> <05C81A773E48DD49B181B04BA21A342A31DA9D7212@HE113484.emea1.cds.t-internal.com> <05C81A773E48DD49B181B04BA21A342A31DA9D7274@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A31DA9D7274@HE113484.emea1.cds.t-internal.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.146.93]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/hiaps/Pa4ZHR9-5fIzgyAEHHdmPEuQh1Q>
Cc: "behcet.sarikaya@gmail.com" <behcet.sarikaya@gmail.com>, "hiaps@ietf.org" <hiaps@ietf.org>, "banana@ietf.org" <banana@ietf.org>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "Roland.Schott@telekom.de" <Roland.Schott@telekom.de>
Subject: Re: [hiaps] Hybrid access bar bof
X-BeenThere: hiaps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" <hiaps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hiaps>, <mailto:hiaps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hiaps/>
List-Post: <mailto:hiaps@ietf.org>
List-Help: <mailto:hiaps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hiaps>, <mailto:hiaps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 05:57:11 -0000

Hi Dirk,

Thanks for the advertisement!

For the CPE based DSL+LTE use case, which is the primary use case of Hybrid Access, the basic requirement is to leave user's equipments unaware of the change. The goal is to increase the access bandwidth by adding free LTE bandwidth to the limited DSL bandwidth. I believe KT's experiment is not about this use case. 

1. The users' equipments are changed. 
2. WIFI is used to increase the bandwidth of LTE. Because WIFI is cheaper than LTE? We can see 850 Mbps is greater than 300 Mbps (LTE MAX) but it is apparently less than 867 Mbps (WIFI MAX). So this is "LTE+" rather than "DSL+LTE ", right?

I saw the MPTCP proposal for the CPE based DSL+LTE use case. Generally, two proxies are required. One is on the CPE and the other one is on an aggregation point in front of the Internet. It faces some unsolved issues that other solutions are also trying to solve. For example, how to let the traffic of certain service types bypass the bonding bandwidth? How to report the bypassing bandwidth from the CPE to the aggregation point?

The front page of BANANA list has done a nice harmonization. Let's discuss there.

Best regards,
Mingui

> -----Original Message-----
> From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of
> Dirk.von-Hugo@telekom.de
> Sent: Thursday, July 30, 2015 4:10 PM
> To: pierrick.seite@orange.com; sarikaya@ieee.org;
> Olivier.Bonaventure@uclouvain.be
> Cc: behcet.sarikaya@gmail.com; hiaps@ietf.org; N.Leymann@telekom.de;
> Roland.Schott@telekom.de
> Subject: Re: [hiaps] Hybrid access bar bof
> 
> Hi all,
> And BTW I just realized that the announced mailing list has already been set up
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg14401.html
> with info at https://www.ietf.org/mailman/listinfo/banana Banana --
> Bandwidth Aggregation for interNet Access: Discussion of bandwidth
> aggregation solutions based on IETF technologies
> 
> However no postings are to be found there yet ...
> 
> Best Regards
> 
> Dirk
> 
> -----Original Message-----
> From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of von Hugo, Dirk
> Sent: Donnerstag, 30. Juli 2015 09:44
> To: pierrick.seite@orange.com; sarikaya@ieee.org;
> Olivier.Bonaventure@uclouvain.be
> Cc: behcet.sarikaya@gmail.com; hiaps@ietf.org; Leymann, Nicolai; Schott,
> Roland
> Subject: Re: [hiaps] Hybrid access bar bof
> 
> Hi Pierrick,
> That's IMO one of the goals of the breakfast BoF on HA ... I assume that
> Margaret will send round some notes.
> Though MPTCP and LISP people were not present AFAICR Best Regards Dirk
> -----Original Message-----
> From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com]
> Sent: Donnerstag, 30. Juli 2015 09:30
> To: sarikaya@ieee.org; Olivier.Bonaventure@uclouvain.be
> Cc: behcet.sarikaya@gmail.com; hiaps@ietf.org; Schott, Roland; Leymann,
> Nicolai; von Hugo, Dirk
> Subject: RE: [hiaps] Hybrid access bar bof
> 
> Hi Behcet,
> 
> With MPTCP proxy at the CPE side, MPTCP can be a bundling technique.
> Actually, the IETF already has a bunch of techniques that can be used for hybrid
> access; the challenge here would be to not reinvent the wheel.
> 
> Pierrick
> 
> > -----Message d'origine-----
> > De : hiaps [mailto:hiaps-bounces@ietf.org] De la part de Behcet
> > Sarikaya Envoyé : mercredi 29 juillet 2015 17:53 À :
> > Olivier.Bonaventure@uclouvain.be Cc : behcet.sarikaya@gmail.com;
> > hiaps@ietf.org; roland.schott@telekom.de; N.Leymann@telekom.de;
> > Dirk.von-Hugo@telekom.de Objet : Re: [hiaps] Hybrid access bar bof
> >
> > Hi Olivier,
> >
> > On Wed, Jul 29, 2015 at 9:21 AM, Olivier Bonaventure
> > <Olivier.Bonaventure@uclouvain.be> wrote:
> > > Dirk,
> > >
> > >> at IET93 in Prague we had a small informal meeting on hiaps issues
> > >> discussing the NAT@RG use case with hybrid access (e.g. DSL+LTE)
> > >> where for different access links and multiple devices (e.g. at
> > >> home) behind the NAT a consistent and customer-configurable policy
> > >> enforcement
> > should be enabled.
> > >> Some vendors say (e.g. A10 during bits'n'bytes) that in an
> > >> SDN-based
> > >> (vCPE) deployment this would be solved but I still like to see it working.
> > >> Also  at the 'hybrid aggregation bundling' barbof mentioned below
> > >> we shortly presented our issues ...
> > >> I hope there will be more activity on that in future - also on more
> > >> generic approaches towards FMC-related heterogeneous link bundling
> > >> - perhaps also stimulating our discussions ;-)
> > >
> > >
> > >
> > > Concerning FMC, you might be interested by the presentation given by
> > > KT during the MPTCP working group. KT uses Multipath TCP to enable
> > > smartphones to combine LTE and WiFi and reach higher bandwidth.
> > >
> > > See
> > > http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF
> > > 93
> > > _MPTCP&chapter=chapter_1
> > > starts at around minute 34
> > >
> > > This service is commercially deployed and was launched in mid June.
> > > Although it only runs on Samsung Galaxy S6, they already had 5500
> > > active users on the day of the presentation
> >
> > I think this is an application of Lollipop or Android 5.0 which
> > enables the use of multiple network interfaces.
> >
> > It is end user or host oriented. Our interest is the wireline-wireless
> > convergence usually aimed at reaching higher bandwidth at the CPE
> > using bundling techniques with the wireless network.
> >
> > By the way, if anybody wants to be unsubscribed of this list, let us know.
> >
> > Regards,
> >
> > Behcet
> > >
> > > Olivier
> > >
> > > _______________________________________________
> > > hiaps mailing list
> > > hiaps@ietf.org
> > > https://www.ietf.org/mailman/listinfo/hiaps
> >
> > _______________________________________________
> > hiaps mailing list
> > hiaps@ietf.org
> > https://www.ietf.org/mailman/listinfo/hiaps
> 
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> hiaps mailing list
> hiaps@ietf.org
> https://www.ietf.org/mailman/listinfo/hiaps
> 
> _______________________________________________
> hiaps mailing list
> hiaps@ietf.org
> https://www.ietf.org/mailman/listinfo/hiaps