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:[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-mult >> i >> 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-mu >>>> l >>>> 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
