Re: [hiaps] Hybrid access bar bof

[<[e-mail]>]

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:[e-mail]] 
Sent: Freitag, 31. Juli 2015 10:25
To: [e-mail]; Mingui Zhang; von Hugo, Dirk; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; 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 [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:

>Hi
>
>> -----Message d'origine-----
>> De : Mingui Zhang [mailto:[e-mail]]
>> Envoyé : vendredi 31 juillet 2015 07:55
>> À : [e-mail]; SEITE Pierrick IMT/OLN; [e-mail];
>> [e-mail]
>> Cc : [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> 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:[e-mail]] On Behalf Of
>> > [e-mail]
>> > Sent: Thursday, July 30, 2015 4:10 PM
>> > To: [e-mail]; [e-mail];
>> > [e-mail]
>> > Cc: [e-mail]; [e-mail]; [e-mail];
>> > [e-mail]
>> > 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.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:[e-mail]] On Behalf Of von Hugo,
>> > Dirk
>> > Sent: Donnerstag, 30. Juli 2015 09:44
>> > To: [e-mail]; [e-mail];
>> > [e-mail]
>> > Cc: [e-mail]; [e-mail]; 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: [e-mail] [mailto:[e-mail]]
>> > Sent: Donnerstag, 30. Juli 2015 09:30
>> > To: [e-mail]; [e-mail]
>> > Cc: [e-mail]; [e-mail]; 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:[e-mail]] De la part de Behcet
>> > > Sarikaya Envoyé : mercredi 29 juillet 2015 17:53 À :
>> > > [e-mail] Cc : [e-mail];
>> > > [e-mail]; [e-mail]; [e-mail];
>> > > [e-mail] Objet : Re: [hiaps] Hybrid access bar bof
>> > >
>> > > Hi Olivier,
>> > >
>> > > On Wed, Jul 29, 2015 at 9:21 AM, Olivier Bonaventure
>> > > <[e-mail]> 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=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
>> > > > [e-mail]
>> > > > https://www.ietf.org/mailman/listinfo/hiaps
>> > >
>> > > _______________________________________________
>> > > hiaps mailing list
>> > > [e-mail]
>> > > 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/hiaps
>> >
>> > _______________________________________________
>> > hiaps mailing list
>> > [e-mail]
>> > 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/hiaps