Re: [5gangip] [lisp] Bandwidth savings with LISP
AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> Wed, 06 July 2016 17:42 UTC
Return-Path: <Peter.AshwoodSmith@huawei.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA412D129; Wed, 6 Jul 2016 10:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YHQNpCBKAlK6; Wed, 6 Jul 2016 10:42:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD14126B6D; Wed, 6 Jul 2016 10:42:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSD51547; Wed, 06 Jul 2016 17:41:59 +0000 (GMT)
Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jul 2016 18:41:58 +0100
Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.43]) by YYZEML703-CHM.china.huawei.com ([169.254.5.208]) with mapi id 14.03.0235.001; Wed, 6 Jul 2016 13:41:54 -0400
From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
To: Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [5gangip] [lisp] Bandwidth savings with LISP
Thread-Index: AQHR07rVXfzmaThsnkyAiJC5tHxhEaAIShBwgAIe5YCAAUlQUA==
Date: Wed, 06 Jul 2016 17:41:54 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E23096001A@YYZEML701-CHM.china.huawei.com>
References: <007601d1cd2f$3a8cad70$afa60850$@unizar.es> <576C060C.2070907@cisco.com> <00ab01d1d38d$17365060$45a2f120$@unizar.es> <6C1441C1-90C3-457B-8146-4869C9FE5929@gmail.com> <7AE6A4247B044C4ABE0A5B6BF427F8E230952CF1@YYZEML701-CHM.china.huawei.com> <00E46299-0548-4A69-A36C-7DE88BA3333C@gmail.com>
In-Reply-To: <00E46299-0548-4A69-A36C-7DE88BA3333C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.86]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.577D42E8.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.43, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 53bed70ace021666ba25ded75db6859d
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/X0A2wScn0h_RZ-_n0DMs2Wvb6ms>
Cc: "5gangip@ietf.org" <5gangip@ietf.org>, José Ruiz Mas <jruiz@unizar.es>, Anton Smirnov <asmirnov@cisco.com>, LISP mailing list list <lisp@ietf.org>, Jose Saldana <jsaldana@unizar.es>
Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 17:42:09 -0000
Hey Dino, >> On the header size issue, one of the complaints I've made about ICN/CCN etc. and 5G is the increased header sizes and the impact that this has on the most expensive resource (by a wide margin), the RF spectrum. >So you are saying large packets would have the same disadvanage. Therefore, small headers on small payloads is the most optimal design space? Not sure how that follows ;) I'm saying either compress or provide an advantage to the RF link too, or both, but doing neither would be a hard sell. Larger packet sizes of course reduce the relative header tax so bigger is actually better I suppose. Cheers, Peter >> Not much point optimizing all the relatively cheap wired links if the tax then goes up on the incredibly expensive wireless links. Right. > Finding a way to properly map multicast/broadcast to the natural RF multicast would seem like a smart thing to do to extend some of the bandwidth savings protocols like ICN/CCN give but there are challenges with this as each UE may have a different RF encoding (due to different channel conditions) and therefore require separate copies anyway. Right, another topic. But thanks for raising it. Dino > > Cheers > > Peter > > -----Original Message----- > From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Dino > Farinacci > Sent: Friday, July 01, 2016 1:06 PM > To: Jose Saldana > Cc: 5gangip@ietf.org; José Ruiz Mas; LISP mailing list list; Anton > Smirnov > Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP > > So I have been thinking about a compelling use-case for LISP header-compression and the super-framing feature (sorry for using my own term). > > I have been told that the Radio Access Network (RAN) tends to be sensitive to overlay solutions due to large headers. I have also heard that there seems to be queuing behavior for the base-stations that send to UEs (i.e. phones). The fact that queuing is happening while waiting for a handoffs to occur can be a good opportunity to pack IP packets into super-frames to send over the RAN. > > Using this solution means the eNodeB (base-station) and the UE (phone) would have to run LISP. I would like to hear comments from the WG. I have copied 5gangip to see if they have opinions. > > Dino > >> On Jul 1, 2016, at 4:38 AM, Jose Saldana <jsaldana@unizar.es> wrote: >> >> Hi again, Anton. >> >> I have just uploaded a new presentation including more ideas and also a section about backward compatibility: >> >> http://es.slideshare.net/josemariasaldana/header-compression-and-mult >> i >> plexing-in-lisp >> >> BR and thanks, >> >> Jose >> >>> -----Mensaje original----- >>> De: Anton Smirnov [mailto:asmirnov@cisco.com] Enviado el: jueves, 23 >>> de junio de 2016 17:54 >>> Para: Jose Saldana <jsaldana@unizar.es>; lisp@ietf.org >>> CC: 'José Ruiz Mas' <jruiz@unizar.es> >>> Asunto: Re: [lisp] Bandwidth savings with LISP >>> >>> Hi Jose, >>> there is a theoretical aspect of the work (it's curious) and then >>> there is a practical one. For the latter one - section "Backward >>> compatibility" is conspicuously missing from the document. On the >>> first glance, it looks like backward compatibility of the solution was not investigated. Is this correct? >>> >>> Anton >>> >>> >>> On 06/23/2016 11:11 AM, Jose Saldana wrote: >>>> Hi all, >>>> >>>> As you may know, we recently submitted a draft >>> (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/) >>> with a proposal allowing bandwidth and pps reductions. >>>> >>>> The idea is to send together a number of small packets, which are >>>> in the buffer of >>> an ITR and have the same ETR as destination, into a single packet. >>> Therefore, they will share a single LISP header. And this can be >>> combined with ROHC (header compression). >>>> >>>> We have a running implementation, based on LISPMob >>>> (https://github.com/Simplemux/lispmob-with-simplemux), which we >>>> have used to run some tests >>>> >>>> This is a summary of the results. >>>> >>>> - When small packets (100 bytes) are sent, up to 63% of throughput >>>> increase can >>> be observed (in our example, we pass from 550kbps to 910kbps). >>>> >>>> - In the case of securing the LISP tunnel with IPSec, the increase >>>> can be 935 >>> (from 470kbps to 870kbps). >>>> >>>> You can find more detailed information in this presentation: >>>> http://es.slideshare.net/josemariasaldana/header-compression-and-mu >>>> l >>>> ti >>>> plexing-in-lisp >>>> >>>> Your feedback will be highly appreciated. >>>> >>>> Best regards, >>>> >>>> The authors >>>> >>>>> -----Mensaje original----- >>>>> De: lisp [mailto:lisp-bounces@ietf.org] En nombre de Jose Saldana >>>>> Enviado el: miércoles, 04 de mayo de 2016 18:41 >>>>> Para: lisp@ietf.org >>>>> CC: 'Jose Ruiz Mas' <jruiz@unizar.es> >>>>> Asunto: [lisp] New draft posted: >>>>> draft-saldana-lisp-compress-mux-00.txt >>>>> >>>>> Hi all, >>>>> >>>>> We have just posted this draft >>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp- >>>>> compress-mux/. >>>>> >>>>> Header compression and multiplexing in LISP >>>>> draft-saldana-lisp-compress-mux-00 >>>>> >>>>> Abstract >>>>> >>>>> When small payloads are transmitted through a packet-switched >>>>> network, the resulting overhead may result significant. This is >>>>> stressed in the case of LISP, where a number of headers are prepended >>>>> to a packet, as new headers have to be added to each packet. >>>>> >>>>> This document proposes to send together a number of small packets, >>>>> which are in the buffer of a ITR, having the same ETR as destination, >>>>> into a single packet. Therefore, they will share a single LISP >>>>> header, and therefore bandwidth savings can be obtained, and a >>>>> reduction in the overall number of packets sent to the network can be >>>>> achieved. >>>>> >>>>> A running implementation can be found here: >>>>> https://github.com/Simplemux/lispmob-with-simplemux. I has been >>>>> built as a fork of lispmob. >>>>> >>>>> The idea is very similar to what was published in this paper: >>>>> http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc. >>>>> pd >>>>> f >>>>> >>>>> Your feedback about the draft will be appreciated. >>>>> >>>>> Thanks in advance, >>>>> >>>>> Jose Saldana >>>>> Julián Fernández Navajas >>>>> José Ruiz Mas >>>>> >>>>>> -----Mensaje original----- >>>>>> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Enviado >>>>>> el: miércoles, 04 de mayo de 2016 18:20 >>>>>> Para: Jose Ruiz Mas <jruiz@unizar.es>; Jose Saldana >>>>>> <jsaldana@unizar.es>; Julian Fernandez Navajas >>>>>> <navajas@unizar.es> >>>>>> Asunto: New Version Notification for >>>>>> draft-saldana-lisp-compress-mux-00.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-saldana-lisp-compress-mux-00.txt >>>>>> has been successfully submitted by Jose Saldana and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-saldana-lisp-compress-mux >>>>>> Revision: 00 >>>>>> Title: Header compression and multiplexing in LISP >>>>>> Document date: 2016-05-04 >>>>>> Group: Individual Submission >>>>>> Pages: 8 >>>>>> URL: >>>>>> https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress- >>>>>> m >>>>>> ux >>>>>> - >>>>>> 00.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-saldana-lisp-compress-mux-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> When small payloads are transmitted through a packet-switched >>>>>> network, the resulting overhead may result significant. This is >>>>>> stressed in the case of LISP, where a number of headers are prepended >>>>>> to a packet, as new headers have to be added to each packet. >>>>>> >>>>>> This document proposes to send together a number of small packets, >>>>>> which are in the buffer of a ITR, having the same ETR as destination, >>>>>> into a single packet. Therefore, they will share a single LISP >>>>>> header, and therefore bandwidth savings can be obtained, and a >>>>>> reduction in the overall number of packets sent to the network can be >>>>>> achieved. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org. >>>>>> >>>>>> The IETF Secretariat >>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip
- Re: [5gangip] [lisp] Bandwidth savings with LISP Rex Buddenberg
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Rex Buddenberg
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Behcet Sarikaya
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci
- Re: [5gangip] [lisp] Bandwidth savings with LISP Ca By
- Re: [5gangip] [lisp] Bandwidth savings with LISP AshwoodsmithPeter
- Re: [5gangip] [lisp] Bandwidth savings with LISP PEDRO ANDRES ARANDA GUTIERREZ
- Re: [5gangip] [lisp] Bandwidth savings with LISP Jose Saldana
- Re: [5gangip] [lisp] Bandwidth savings with LISP Dino Farinacci