Re: [lisp] [5gangip] Bandwidth savings with LISP

[Dino Farinacci <[e-mail]>]

> 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.

> 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:[e-mail]] On Behalf Of Dino Farinacci
> Sent: Friday, July 01, 2016 1:06 PM
> To: Jose Saldana
> Cc: [e-mail]; 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 <[e-mail]> 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:[e-mail]] Enviado el: jueves, 23 
>>> de junio de 2016 17:54
>>> Para: Jose Saldana <[e-mail]>; [e-mail]
>>> CC: 'José Ruiz Mas' <[e-mail]>
>>> 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:[e-mail]] En nombre de Jose Saldana 
>>>>> Enviado el: miércoles, 04 de mayo de 2016 18:41
>>>>> Para: [e-mail]
>>>>> CC: 'Jose Ruiz Mas' <[e-mail]>
>>>>> 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: [e-mail] [mailto:[e-mail]] 
>>>>>> Enviado
>>>>>> el: miércoles, 04 de mayo de 2016 18:20
>>>>>> Para: Jose Ruiz Mas <[e-mail]>; Jose Saldana 
>>>>>> <[e-mail]>; Julian Fernandez Navajas <[e-mail]>
>>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> 
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip