Re: [hiaps] [Banana] Hybrid access bar bof

<pierrick.seite@orange.com> Thu, 06 August 2015 07:54 UTC

Return-Path: <pierrick.seite@orange.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 71D251ACF04; Thu, 6 Aug 2015 00:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
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 0eQcTRHyMlup; Thu, 6 Aug 2015 00:54:15 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129501ACF56; Thu, 6 Aug 2015 00:54:15 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6462618C7EC; Thu, 6 Aug 2015 09:54:13 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 38C9C238048; Thu, 6 Aug 2015 09:54:13 +0200 (CEST)
Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 09:54:12 +0200
From: pierrick.seite@orange.com
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, "zhangmingui@huawei.com" <zhangmingui@huawei.com>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [Banana] [hiaps] Hybrid access bar bof
Thread-Index: AQHQz7CECjiTfc0lnEugxqO79n3J5Z3+l/Gg
Date: Thu, 06 Aug 2015 07:54:11 +0000
Message-ID: <13549_1438847653_55C312A5_13549_3670_1_81C77F07008CA24F9783A98CFD706F71160EB5B0@OPEXCLILM22.corporate.adroot.infra.ftgroup>
References: <EE4CC009-EA24-464A-93B3-E9C7D08C52AB@alcatel-lucent.com>
In-Reply-To: <EE4CC009-EA24-464A-93B3-E9C7D08C52AB@alcatel-lucent.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.6.70616
Archived-At: <http://mailarchive.ietf.org/arch/msg/hiaps/hOTIZyGVkLAsM6Xv-pz-J-KTogc>
Cc: "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] [Banana] 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: Thu, 06 Aug 2015 07:54:18 -0000


> -----Message d'origine-----
> De : Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
> Envoyé : mercredi 5 août 2015 20:57
> À : Dirk.von-Hugo@telekom.de; SEITE Pierrick IMT/OLN;
> zhangmingui@huawei.com; sarikaya@ieee.org; Olivier.Bonaventure@uclouvain.be
> Cc : hiaps@ietf.org; N.Leymann@telekom.de; banana@ietf.org;
> Roland.Schott@telekom.de
> Objet : Re: [Banana] [hiaps] Hybrid access bar bof
> 
> Dirk, I just wanted to have people understand that with current standards a lot can
> be achieved. So I believe we should start with defining a set of requirements and
> see what is missing from standardisation to achieve the requirements.
> What i wanted to mention with the email is to indicate that with the current
> standards a lot can be done if you do the right implementation. 


I could'nt agree more ... It would be good to describe what can be done, with existing protocols, to meet BBF requirement

So the question
> will be what is missing/remaining to achieve interoperability.
> The implementation we did with current standards is interoperable already with
> many implementations and devices that I mentioned below and covers
> smartphones, residential GW and enterprise GW(s) market segments.
> 
> 
> 
> On 05/08/15 16:25, "Banana on behalf of Dirk.von-Hugo@telekom.de" <banana-
> bounces@ietf.org on behalf of Dirk.von-Hugo@telekom.de> wrote:
> 
> >Hi Wim,
> >Thanks for your mail.
> >I agree that different solutions today addressing different use cases have to be
> understood better.
> >Do you mean future adaptations towards a potential common standardized
> approach or proprietary adaptations from existing standards towards the existing
> solutions in the market?
> >Aim might be to achieve a common solution framework (perhaps modularly
> designed) based on existing protocols as much as possible.
> >With respect to hashing (for identifying flows/packets on different paths) I
> wonder whether standard routing can cope with it. Regarding IPv6 the address
> consumption should be not the big problem, right?
> >Or did I miss/misunderstand something here?
> >Thanks!
> >Best regards
> >Dirk
> >-----Original Message-----
> >From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
> >Sent: Freitag, 31. Juli 2015 10:25
> >To: pierrick.seite@orange.com; Mingui Zhang; von Hugo, Dirk;
> >sarikaya@ieee.org; Olivier.Bonaventure@uclouvain.be
> >Cc: behcet.sarikaya@gmail.com; hiaps@ietf.org; banana@ietf.org;
> >Leymann, Nicolai; Schott, Roland
> >Subject: Re: [hiaps] Hybrid access bar bof
> >
> >I believe there is several solutions today in the market and some require more
> adaptations than others.
> >E.g. If you give the same IP address and multiple links/Interfaces (ETH, xG, WIFI)
> and the IP stack accepts that, it can do packet or flow based hashing. Tested and
> working with openWRT, Android, IOS, Linux. Some stack prefer one interface over
> another and others have more extensive hashing/loadbalanicng mechanisms, but
> this is implementation specific.
> >The nice thing is that you don’t consume extra ip addresses and most stacks
> support this today. Works on smartphones, residential GW and enterprise GW(s).
> >
> >
> >
> >On 31/07/15 10:06, "hiaps on behalf of pierrick.seite@orange.com" <hiaps-
> bounces@ietf.org on behalf of pierrick.seite@orange.com> wrote:
> >
> >>Hi
> >>
> >>> -----Message d'origine-----
> >>> De : Mingui Zhang [mailto:zhangmingui@huawei.com] Envoyé : vendredi
> >>> 31 juillet 2015 07:55 À : Dirk.von-Hugo@telekom.de; SEITE Pierrick
> >>> IMT/OLN; sarikaya@ieee.org; Olivier.Bonaventure@uclouvain.be Cc :
> >>> behcet.sarikaya@gmail.com; hiaps@ietf.org; N.Leymann@telekom.de;
> >>> Roland.Schott@telekom.de; banana@ietf.org Objet : RE: [hiaps] Hybrid
> >>> access bar bof
> >>>
> >>> 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?
> >>
> >>Well... This is basic policy based routing as, implemented, for example, by
> Linux/IPtables.
> >>Actually, I do not see problems that can't be solved with existing
> protocols/mechanisms... but, I may be wrong....
> >>
> >>Pierrick
> >>
> >>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/msg1440
> >>> > 1.ht ml 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
> >>> > > >> DSL+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?recordin
> >>> > > > g=IE
> >>> > > > TF
> >>> > > > 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
> >>
> >>____________________________________________________________________
> __
> >>___________________________________________________
> >>
> >>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
> >_______________________________________________
> >Banana mailing list
> >Banana@ietf.org
> >https://www.ietf.org/mailman/listinfo/banana

_________________________________________________________________________________________________________________________

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.