Hi, Just a minor comment inline...
> -----Mensaje original----- > De: Dino Farinacci [mailto:[email protected]] > Enviado el: martes, 05 de julio de 2016 19:57 > Para: AshwoodsmithPeter <[email protected]> > CC: Jose Saldana <[email protected]>; [email protected]; José Ruiz Mas > <[email protected]>; LISP mailing list list <[email protected]>; Anton Smirnov > <[email protected]> > Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP > > > 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. > > So you are saying large packets would have the same disadvanage. Therefore, > small headers on small payloads is the most optimal design space? > > > Not much point optimizing all the relatively cheap wired links if the tax > > then goes > up on the incredibly expensive wireless links. > > Right. Well, optimization can also benefit the spectrum usage. We have run some tests sending small packets in a Wi-Fi link: https://www.ietf.org/proceedings/93/slides/slides-93-gaia-2.pdf, slide 11. If you first aggregate and then send them, you save bandwidth, but also air time, as you reduce the number of channel contention periods. In fact, 802.11 also has two different aggregation mechanisms working at layer 2. The advantage of aggregating at layer 3 is that you can send packets together during more than a single hop (see some scenarios in slide 12). Best regards, Jose > > > 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
