Hey Dino, Queuing also happens when a UE is has been idle for a while and is being paged.
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. Not much point optimizing all the relatively cheap wired links if the tax then goes up on the incredibly expensive wireless links. 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. Cheers Peter -----Original Message----- From: 5gangip [mailto:[email protected]] On Behalf Of Dino Farinacci Sent: Friday, July 01, 2016 1:06 PM To: Jose Saldana Cc: [email protected]; 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 <[email protected]> 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-multi > plexing-in-lisp > > BR and thanks, > > Jose > >> -----Mensaje original----- >> De: Anton Smirnov [mailto:[email protected]] Enviado el: jueves, 23 >> de junio de 2016 17:54 >> Para: Jose Saldana <[email protected]>; [email protected] >> CC: 'José Ruiz Mas' <[email protected]> >> 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-mul >>> ti >>> plexing-in-lisp >>> >>> Your feedback will be highly appreciated. >>> >>> Best regards, >>> >>> The authors >>> >>>> -----Mensaje original----- >>>> De: lisp [mailto:[email protected]] En nombre de Jose Saldana >>>> Enviado el: miércoles, 04 de mayo de 2016 18:41 >>>> Para: [email protected] >>>> CC: 'Jose Ruiz Mas' <[email protected]> >>>> 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: [email protected] [mailto:[email protected]] >>>>> Enviado >>>>> el: miércoles, 04 de mayo de 2016 18:20 >>>>> Para: Jose Ruiz Mas <[email protected]>; Jose Saldana >>>>> <[email protected]>; Julian Fernandez Navajas <[email protected]> >>>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >>> > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ 5gangip mailing list [email protected] https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
